[Hypervisor Live Update] Notes from November 3, 2025

[Pasha Tatashin]

On Sat, Nov 8, 2025 at 6:48 PM David Rientjes <rientjes at google.com> wrote:
>
> 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.

Thank you David for running this meeting. The LUOv5 + memfd
preservation from Pratyush was posted yesterday:

https://lore.kernel.org/all/20251107210526.257742-1-pasha.tatashin@soleen.com

Pasha

> ----->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
>