On Sun, Jun 07, 2026 at 12:06:01PM -0400, Pasha Tatashin wrote: > Hi everybody, > > Here are the notes from the Hypervisor Live Update call that happened on > Monday, June 1. 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----- > LPC 2026 Call for Proposals > > The Call for Proposals for the Live Update Microconference at LPC 2026 > is officially open. Please submit your topics and proposals before the > deadline on July 24th. > > https://lore.kernel.org/all/ahcc3Qyuy7Oy03Iq@plex > > ----->o----- > KHO Xarray Implementation & Core Data Structures > > Pratyush is collaborating with Mike on a KHO fallback allocation > strategy for memblock. Alongside this, Pratyush is designing a > serialized, sparse "KHO Xarray" data structure to lift current mapping > restrictions across all three memfd types (shared, hugeTLB, and > guest_memfd). By allowing runtime page faults and allocation tracking > post-preservation, this avoids flat vmalloc array scalability > limitations. > > Potential wider use cases for the KHO Xarray were discussed: > - MSHV sparse bitmap tracking. > - IOMMU page table tracking (Samiullah will evaluate domain/device tree > association fit). > - PCI/VFIO sparse tracking via Bus/Device/Function (BDF) key spaces. > > Slab/Cache Preservation vs. Linked Blocks: > David Matlack noted that using an Xarray page per PCI device would be > too expensive given their small struct sizes. Pratyush suggested > preserving slab caches via dedicated kmem_cache flags to manage small, > arbitrary allocations. As an immediate alternative, Pasha's ongoing LUO > limits refactor series introduces a highly compact block-linked list > structure optimized for runtime file/session tracking. David Matlack > will review if this fits the PCI core tracking requirements. > > ----->o----- > LUO Limit Removal & PCI Core Status > > LUO Refactor: Pasha is updating the LUO series to address Pratyush's > comments (primarily renaming iterator functions) and plans to send out > v2 shortly. Given that LUO is not yet in fleet production, the group > agreed to fast-track this into the upcoming merge window to align with > systemd's fdstore integration. > > PCI Core v6: David Matlack sent out v6 incorporating two critical fixes > spotted by Sachiko regarding get/put semantics and double-retrieval > failures. Review tags from the live update team are needed to help > secure Bjorn's Ack once he returns from vacation next week. > > ----->o----- > IOMMU Persistence & Process Memory > > IOMMU v3: Samiullah is addressing recent review feedback on the IOMMU > persistence series and intends to post v3 by the end of this week. The > associated development roadmap document has received positive > stakeholder attention. > > CRIU & vm_splice: Maximilian's investigation into optimizing vm_splice > for copy-less data preservation remains deferred but remains in the > pipeline, with potential future collaboration with Google's tmpfs splice > efforts.
I’ve also been researching a combination solution integrating CRIU and KHO. My approach stores all image data dumped by CRIU into memfd, then persists those memfd objects via KHO/LUO. I’ve reviewed the historical meeting notes and would like to clarify: does the CRIU solution discussed in the meetings aim to save the full set of a process’s metadata and data, or only the anonymous memory and shared memory allocated during the process runtime? Chenghao > > ----->o----- > guest_memfd Enlightenment & VMM Documentation > > Tarun debriefed the community on his upstream presentation regarding the > initial guest_memfd preservation patch series (currently covering fully > shared mappings with page-sized folios). > > Key design and architecture alignments include: > - VM File Association: guest_memfd requires an active 'struct kvm' > context to be retrieved. VMMs must preserve the parent VM file > alongside guest_memfd, using LUO tokens to re-link them on the > incoming kernel path. This sets the stage for future private > mapping/secure EPT table tracking. > - Relaxed Fault Logic: The group agreed to drop strict upfront pre-fault > checks. Instead, standard runtime page-fault semantics will apply. If > a guest page fault occurs post-preservation, it will bubble up via > standard KVM_RUN ioctl exits to the VMM, which can safely pause vCPUs > and retry the fault post-kexec. > - Centralized VMM Documentation: Pasha and David Matlack proposed > creating a centralized guide under live_update/vmm detailing the > overall live update flow, timing constraints, and subsystem > requirements to assist external QEMU and VMM developers. > > ----->o----- > Next meeting will be on Monday, June 15 at 8am PDT (UTC-7), everybody is > welcome: https://meet.google.com/rjn-dmzu-hgq > > Note: I am going to be traveling on June 15th, David Matlack is going to > be hosting it. > > Topics for the next meeting: > - Presentation of VFIO roadmap (Vipin and David Matlack) > - Status of KHO Xarray development and slab preservation feasibility > - Review of PCI core changes v7 and upstream merge coordination > - IOMMU persistence v3 review feedback > - Detailed review of guest_memfd v2 and VMM interaction documentation > - Review and coordination of LPC 2026 Microconference topic submissions > - later: KHO support for Confidential VMs including page table > preservation and pinning > - later: versioning support for luod to negotiate > - later: 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!
