[Hypervisor Live Update] Notes from November 3, 2025

[David Rientjes]

Hi everybody,

Here are the notes from the last Hypervisor Live Update call that happened 
on Monday, November 3.  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 chatted briefly about the status of the stateless KHO RFC patch series 
intended to simply LUO support.

Pasha started us off by updating that Jason Miu will be updating his patch 
series and is expected to send those patches to the mailing list after 
some more internal code review.  That would be expected to be posted 
either this week or next week.

Pasha also updated that is plan is to remove subsystems to simply the 
state machine and the UAPI; this would be replaced by the file lifecycle 
bound global data created and destroyed automatically based on reserved 
file state.  He was also simplifying the state machine to keep the minimum 
needed support in the initial version, but with extensibility for the 
future.  No exact timeline although it is currently ~90% ready.

----->o-----
Pratyush discussed the global file based state and how it may circumvent 
the LUO state machine; it's an implicit preserve of the subsystem 
completely independent of global state.  Pasha said the state is now bound 
to the state of the preserved files only based on sessions.  We're getting 
rid of global state for now.

Pratyush suggested to tie subsystems with the file handler but this would 
not be possible if subsystems are going away.  Pasha said the new global 
state is flexible and can share multiple file handlers; one global state 
can be bound to multiple file handlers.

----->o-----
Jork Loeser as if there is a design/API link for the memfd and whether 
this is something a driver could use to persistently holding data.  He was 
asking if a driver could associate arbitrary pages with a preserved memfd.

Pratyush said the memfd preservation was part of the LUO patch series at 
the end.  A driver can pass a memfd to LUO after creating an fd.  Pratyush 
suggested using KHO to preserve data; the data may moved at runtime but 
would need to be unmovable during preservation across kexec.

Jason Gunthorpe suggested using APIs to get a page from a memfd at a 
specific offset.

----->o-----
Vipin Sharma had posted a recent patch series for VFIO[1], David Matlack 
will be working on v2 of this will Vipin is on leave.  Feedback was 
received about not moving the PCI save state and making them public, so 
that's work in progress.  More feedback said there was missing bits and we 
need more PCI core changes that would be updated in v2 to be more complete 
(but also include more PCI changes).  No specific timeline yet on v2, but 
it will be based on LUO v5.

David said the VFIO patches are using an anonymous inode to recreate the 
file after live update and asked if we care about associating recreated 
fds for userspace after live update with a particular inode.  Jason said 
that VFIO would care because it uses the inode to get an address space 
which it uses with an unmapped mapping range and this must work correctly.

----->o-----
Sami summarized the discussion on IOMMU persistence.  He was working on 
updating the patch series to v2 based on the feedback from v1.  He talked 
about restoration of the HWPTs on the restore side.  Jason thought that we 
wouldn't have an IOAS for the restored domains and suggested it could be 
null instead.  Sami thought this may be slightly invasive including where 
we are taking locks; Jason suggested against a dummy IOAS.

----->o-----
We discussed briefly about deferred struct page initialization support 
with KHO.  Pasha said KHO isn't compatible with deferred struct pages 
although when using KHO we definitely want fast reboot performance.  We 
decided to discuss this more later after LPC where there will be some 
discussion about reboot performance.

----->o-----
Pratyush noted that he is working on the 1GB preservation but will take 
some more time to clean up and have it working properly.  He said 
guest_memfd would use hugetlb for 1GB pages so he's working on hugetlb 
preservation.  Pratyush was focusing on generic hugetlb support that could 
be ported for use with guest_memfd when it supports hugetlb.  He's aiming 
for an RFC to be ready by the time of LPC.

Ackerley updated that the hugetlb support for guest_memfd is currently in 
RFC patches posted upstream.

----->o-----
Next meeting will be on Monday, November 17 at 8am PST (UTC-8), everybody
is welcome: https://meet.google.com/rjn-dmzu-hgq

Topics for the next meeting:

 - update on the status of stateless KHO RFC patches that should simplify
   LUO support
 - update on the status of LUO v5 overall
 - follow up on the status of iommu persistence and its v2 patches based
   on v1 feedback
 - update on the v2 of the VFIO patch series based on LUO v5 and expected
   timelines
 - discuss status of hugetlb preservation, specifically 1GB support, with
   regular memfd, aiming for an RFC by the time of LPC
 - update on status of guest_memfd support for 1GB hugetlb pages
 - discuss any use cases for Confidential Computing where folios may need
   to be split after being marked as preserved during brown out
 - 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://marc.info/?l=linux-kernel&m=176074589311102&w=2