On Sat, Nov 8, 2025 at 6:48 PM David Rientjes <[email protected]> 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/[email protected] 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 >
