Re: [Hypervisor Live Update] Notes from July 27, 2026

Chenghao Duan <[email protected]> Mon, 3 Aug 2026 16:30:56 +0800
Newsgroups org.infradead.lists.kexec,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <20260803082957.GA861524@chenghao-pc>
On Sat, Aug 01, 2026 at 08:32:07AM -0400, Pasha Tatashin wrote:
> Hi everybody,
> 
> Here are the notes from our Hypervisor Live Update call held on July 27.
> These notes are intended to bring those who could not attend up to speed
> and to keep the momentum going between meetings.
> 
> ----->o-----
> LPC 2026 Call for Proposals & Registration
> 
> * Deadline Extension: The Call for Proposals deadline for all LPC 2026
>   microconferences in Prague has been extended to August 7th.
> 
>   https://lore.kernel.org/all/ahcc3Qyuy7Oy03Iq@plex
> 
> * KVM Track Load Balancing: Due to a strong number of proposals for the
>   Live Update Microconference, the team discussed moving select topics
>   to the KVM track to balance the schedule. Orphaned VM topics (proposed
>   by Pasha and Pratyush) and potentially guest_memfd preservation will
>   be submitted to both tracks. Pratyush will coordinate with organizers
>   of both tracks to ensure talks are accepted in one track rather than
>   duplicated.
> 
> ----->o-----
> PCIe Persistence
> 
> * PCI v8 Status: David Matlack is preparing the v8 PCI series, targeting
>   submission by Tuesday/Wednesday before leaving for vacation.
> 
> * Versioning in Structure: Versioning is being moved out of the compatibility
>   string (which will remain a constant string like "pci") and into the first
>   field of the pci_ser structure. Because retrieve failures in the PCI core
>   are fatal and require a kernel panic to prevent memory corruption in
>   dependent subsystems (such as IOMMU), embedding the version in the struct
>   allows the kernel to reliably distinguish between missing FLB data and an
>   incompatible version.
> 
> * Reviews & Landing Strategy: Bjorn Helgaas provided review comments and
>   Reviewed-by tags on several patches, including feedback on structuring
>   and naming for the bus number preservation patch. David will reply to the
>   v7 cover letter to propose merging the initial series through the Live
>   Update tree due to dependencies in liveupdate/next.
> 
> ----->o-----
> VFIO Persistence
> 
> * VFIO v5/v6 Status: Vipin Sharma sent out VFIO v5 on July 14th and is
>   working on v6 to address review comments, targeting submission in 2-3
>   weeks.
> 
> * Lockdep Investigation: A lockdep warning reported during testing was
>   investigated and determined to be unrelated to Live Update (involving CPU
>   hotplug locks during boot group operations and ATS). Vipin will start a
>   separate mailing list thread with a reproducer to discuss the lockdep
>   issue independently so it does not block the VFIO series.
> 
> * Landing Strategy: Vipin requested guidance on the base tree for landing
>   initial VFIO patches. Pasha will reply on the cover letter thread to
>   initiate discussion with Alex Williamson and maintainers.
> 
> ----->o-----
> IOMMU Persistence
> 
> * IOMMU v4 Status: Samiullah Khawaja plans to post v4 this week. Changes
>   include lifecycle edge-case fixes identified by Sashiko, refactoring to
>   separate non-live-update functions, and adopting the constant compatibility
>   string with private struct versioning (matching PCI v8).
> 
> * Recoverable Error Retry Logic: Samiullah noted that retry logic for
>   recoverable errors is not required for Phase 1 and will be deferred until
>   needed by subsequent patch series.
> 
> * Dependency Ordering Documentation: In response to Pratyush's question
>   regarding file preservation ordering, Pasha and Samiullah reaffirmed that
>   LUO does not enforce a hardcoded preservation sequence. Any ordering
>   restrictions imposed by file handlers (e.g., preserving during preserve
>   rather than freeze) are strictly for optimization or immutability reasons.
>   Samiullah will explicitly document these guidelines in-tree. Future
>   evolution may only relax ordering requirements, never make them stricter.
> 
> ----->o-----
> KHO & LUO
> 
> * KHO Scratch Extension v4: Pratyush Yadav posted v4 of the KHO scratch
>   extension series on Friday. Feedback from Sashiko was primarily on
>   pre-existing issues; Pratyush aims to land the series in the current
>   merge window.
> 
> * LoongArch KHO Support: Pratyush followed up with the LoongArch developer
>   regarding boot protocol preferences and maintainer feedback; awaiting
>   further updates.
> 
> ----->o-----
> Guest Memory (guest_memfd) & HugeTLB
> 
> * guest_memfd v4 Status: Tarun Sahu is ready with v4 and plans to post it
>   this week. The update integrates negative tests, including verifying
>   allocation failures when guest_memfd is frozen during preservation and
>   ensuring guest_memfd without required flags is not preserved.
> 
> * IOMMU Interaction & Freezing: The group discussed how IOMMU DMA pinning
>   interacts with shared guest_memfd preservation. Unlike regular shmem/mmfd
>   where sealing prevents hole-punching (fallocate), guest_memfd currently
>   relies on freezing during preservation. The team agreed on a phased
>   approach:
>   1. Proceed with the current guest_memfd v4 series as-is (using freezing),
>      with a cover letter note clarifying that IOMMU support for guest_memfd
>      will be addressed in a later phase.
>   2. Pratyush will explore removing the freezing requirement for mmfd and
>      guest_memfd in favor of dynamic updates to serialization structures.
>   3. Implement IOMMU support for guest_memfd once the freezing/updating
>      model is finalized.
> 
> * HugeTLB: On hold pending landing of the extended scratch memory series
>   and removal of freezing.
> 
> ----->o-----
> Orphaned VMs & Development Environment
> 
> * Prototype & Repository: Pasha presented an update and demo on Orphaned VMs
>   (allowing VMs to survive host kexec/reboot without stopping vCPUs). He
>   published an open-source development environment repository:

What are all the features mentioned above? Are user-space out-of-kernel
tools included in scope?

> 
>   https://github.com/soleen/orphanvm

I cannot access this URL, as it returns a 404 error.

BRs
Chenghao
> 
> * NanoVM & Simics: The repository includes a lightweight C-based VMM
>   (nanovm) that demonstrates end-to-end live update across kexec. Pasha is
>   running it under Simics, which provides full hardware emulation of Intel
>   VTX virtualization instructions (unlike QEMU full emulation), booting the
>   host VM in ~6 seconds and nested guest VM in ~5 seconds (real time). This
>   provides a clean, bare-metal-like environment to study vCPU state and VM
>   exits during reboot.
> 
> ----->o-----
> Action Items & Next Steps
> 
> Pasha:
> * Reply on the VFIO cover letter thread regarding the landing tree strategy
>   with maintainers.
> * Coordinate with LPC KVM and Live Update microconference organizers regarding
>   track placement for Orphaned VM and guest_memfd topics.
> 
> David M:
> * Post PCI v8 series.
> * Reply to the PCI v7 cover letter proposing merging the initial series
>   through the Live Update tree.
> 
> Vipin:
> * Start a separate mailing list thread with a reproducer for the lockdep
>   issue independent of the VFIO live update series.
> * Continue work on VFIO v6.
> 
> Samiullah:
> * Post IOMMU v4 series.
> * Document in-tree guidelines for file preservation ordering dependencies
>   and optimization/immutability requirements.
> 
> Pratyush:
> * Follow up with LoongArch maintainers regarding KHO boot protocol support.
> * Submit LPC talk proposal to the KVM track and coordinate with organizers.
> * Continue work on removing freezing requirements for shmem/guest_memfd.
> 
> Tarun:
> * Post guest_memfd preservation v4 (including cover letter note regarding
>   future IOMMU support).
> 
> ----->o-----
> 
> Next meeting will be on Monday, August 10 at 8am PDT (UTC-7), everybody is
> welcome!
> 
> Join Here: https://meet.google.com/rjn-dmzu-hgq
> 
> Please let me know if you'd like to propose additional topics for
> discussion, thank you!
> 
> Best regards,
> Pasha