From: David Rientjes <rientjes@google.com>
To: Alexander Graf <graf@amazon.com>,
"Andersen, Tycho" <Tycho.Andersen@amd.com>,
Anthony Yznaga <anthony.yznaga@oracle.com>,
Baolu Lu <baolu.lu@linux.intel.com>,
David Hildenbrand <david@kernel.org>,
David Matlack <dmatlack@google.com>,
James Gowans <jgowans@amazon.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Mike Rapoport <rppt@kernel.org>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
Pasha Tatashin <tatashin@google.com>,
Pratyush Yadav <pratyush@kernel.org>,
Praveen Kumar <kpraveen.lkml@gmail.com>,
Vipin Sharma <vipinsh@google.com>,
Vishal Annapurve <vannapurve@google.com>,
"Woodhouse, David" <dwmw@amazon.co.uk>
Cc: linux-mm@kvack.org, kexec@lists.infradead.org
Subject: [Hypervisor Live Update] Notes from February 23, 2026
Date: Sat, 28 Feb 2026 17:44:18 -0800 (PST) [thread overview]
Message-ID: <8dff046d-a819-ac8e-c1fa-8b5a35740cbb@google.com> (raw)
Hi everybody,
Here are the notes from the last Hypervisor Live Update call that happened
on Monday, February 23. Thanks to everybody who was involved!
These notes are intended to bring people up to speed who could not attend
the call as well as keep the conversation going in between meetings.
----->o-----
We briefly mentioned the luod design doc[1] and asked people for review,
Pratyush noted that he would be taking a look at it.
----->o-----
Jork Loeser noted that he was looking at HyperV partition survival. They
donate pages to HyperV which is a concept that doesn't exist in KVM.
These pages are removed from Linux entirely and cannot be accessed. He
was playing with stateless KHO and extended some features but is not ready
to send the patches out for review. He was wondering if there was a
possibility of landing changes in 7.1.
Pratyush noted that stateless KHO should go into the tree independently.
Any consumers of the radix tree can be independent and build on top of
those patches. He noted that he would be happy to review the patches when
they come out.
----->o-----
Pratyush noted that there were no updates for versioning support. There
is a clear plan forward for it but it hasn't been implemented yet.
He said he updated the HugeTLB preservation support with the requested
changes from the mailing list but doesn't have selftests done yet. In two
weeks, he was hoping that these would be posted to the list.
----->o-----
David Matlack noted for interrupt ordering that discussions are still
ongoing with NV on the topic. Right now the simple approach is being used
for disabling interrupts on the device and then reenabling them after live
update.
For VFIO, there hasn't been a lot of feedback yet. He was going to ask
Bjorn and Alex to take a look.
----->o-----
Sami sent out phase 1 of the IOMMU preservation series and is looking
forward to the next phase. He was asking people for review upstream.
Sami is using the VFIO patch series as a dependency.
----->o-----
Ackerley Tng went through guest_memfd HugeTLB support; the link to the
slides are included in the cover letter for participants. He briefly
touched on an introduction to guest_memfd as a guest-first memory provider
to KVM. He then discussed how guest_memfd simply wraps existing sources
of memory like pages from the buddy allocator or HugeTLB pages. The
folios are put into the filemap.
Every page is individually tracked to be either shared or private.
Confidential guests can request a private page to be shared with the host
and vice versa. For shared-to-private conversion, the userspace VMM makes
sure that devices stop using the memory requested by checking refcounts
and then sends the SET_MEMORY_ATTRIBUTES ioctl to guest_memfd; that unmaps
the range from the userspace page tables and records the page as private
before returning to the guest.
Refcounting for a HugeTLB page is taken for the entire hugepage so we
cannot identify which page within the hugepage the refcount was taken for.
For all private-to-shared conversions this requires splitting hugepages
into pages. Split folios have to be merged back together but may also
out-live the guest_memfd; for example if the fd is closed the memory may
finally be unpinned. This requires tracking outside of KVM such as the
original size of the folio and which memcg was charged for it. This is
also required for memory error handling.
For KHO preservation, for guest_memfd pages (not HugeTLB pages) we need to
preserve the filemap and associated folios, mempolicy, and memory
attributes from the Maple Tree. For HugeTLB pages we must preserve the
restructuring metadata. It was noted that there is no memory failure
tracking today, it could be a future extension.
Pratyush asked if we can disallow any conversions after prepare. Ackerley
said if this period is very short than this should be fine. Pratyush also
asked if we should associate the guest_memfd with the host VM which,
today, we rely on the VMM to do.
For timelines, Ackerley suggested that we would be able to merge
conversion support with private/shared tracking in March and then HugeTLB
support without restructuring in June. He was hoping to have
restructuring support later this year.
----->o-----
NOTE!! Daylight Savings Time starts on Sunday, March 8 so the time of the
meeting may have changed for some participants.
Next meeting will be on Monday, March 9 at 8am PDT (UTC-7), everybody is
welcome: https://meet.google.com/rjn-dmzu-hgq
Topics for the next meeting:
- stateless KHO patch status in Andrew's tree
- determine if luod would become part of systemd and discussions with
Luca; implementation and next steps
- versioning support for luod to negotiate
- HugeTLB preservation support
- ordering issues when disabling interrupts based on feedback from NV
- VFIO patch series review from the list
- phase 1 of IOMMU persistence patch series, then phase 2 status and
updates
- hitless replacement for iommu domains
- guest_memfd HugeTLB enlightenment: conversion support, HugeTLB support
without restructuring, and HugeTLB support with restructuring
- live update related topics to propose for LSF/MM/BPF 2026
- KHO enlightenment for ASI
- later: update on PCI preservation series and next steps
- later: testing methodology to allow downstream consumers to qualify
that live update works from one version to another
- later: reducing blackout window during live update, including deferred
struct page initialization
Please let me know if you'd like to propose additional topics for
discussion, thank you!
[1] https://tinyurl.com/luoddesign
reply other threads:[~2026-03-01 1:44 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8dff046d-a819-ac8e-c1fa-8b5a35740cbb@google.com \
--to=rientjes@google.com \
--cc=Tycho.Andersen@amd.com \
--cc=anthony.yznaga@oracle.com \
--cc=baolu.lu@linux.intel.com \
--cc=david@kernel.org \
--cc=dmatlack@google.com \
--cc=dwmw@amazon.co.uk \
--cc=graf@amazon.com \
--cc=jgg@nvidia.com \
--cc=jgowans@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=kpraveen.lkml@gmail.com \
--cc=linux-mm@kvack.org \
--cc=pankaj.gupta.linux@gmail.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=tatashin@google.com \
--cc=vannapurve@google.com \
--cc=vipinsh@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox