[Hypervisor Live Update] Notes from August 25, 2025

David Rientjes rientjes at google.com
Sat Sep 6 18:08:19 PDT 2025


Hi everybody,

Here are the notes from the last Hypervisor Live Update call that happened 
on Monday, August 25.  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 discussed the feasibility of sharing the videos from this series of 
meetings as unlisted videos on YouTube.  All of the previous videos and 
summaries are available on our shared drive, which requires being added 
with your corporate or personal email.  After discussion, there did not 
seem to be interest either way in this so we decided to proceed with the 
shared drive as normal.

----->o-----
We got an update on the latest of LUO, Pasha was working on v4 that akpm 
requested based on upstream feedback and for rebase.  There were no 
additional updates for luod, but feedback continues to be received on the 
externally available design doc.

For KHO, there was discussion on making this entirely stateless and the 
format to be used as a result of that.  Idea was to use page tables and a 
bitmap at the bottom to specify the preserved pages.  Pratyush noted that 
he sent a similar proposal as this earlier so some ideas may be grabbed 
from there.  Jason Miu is working on this and noted that the proposal is 
similar to what Pratyush sent before, he said a draft implementation would 
be sent out by the end of next week.

Jason Gunthorpe asked about the staged approach to avoid retaining the 
page table information.  He was concerned about the circular notion of 
preserving page tables and then their page tables.  Pasha said that we'd 
preserve ~4MB or higher order for the buffers where the page tables would 
be allocated (shallow page tables); to preserve a 4MB page, we use pages 
from itself to create the high-order page table.  Jason Gunthorpe was 
concerned about being able to allocate such high-order pages.

----->o-----
Pratyush noted that there was some feedback on the memfd preservation 
patches and he planned on sending out a new series shortly.  Pasha said 
there was the 1GB limitation with the current series and he implemented an 
extension for that so he was planning to send that support to Pratyush 
offline.

----->o-----
We discussed luod and its implementation language, which turned out to be 
interesting.  Feedback from Mike Rapoport and Pratyush were to implement 
it in C.  There was general concern about some developers not knowing Rust 
well enough to implement in that language.  If implementation was going to 
start in the next couple weeks, we would want to settle on the 
implementation language.  As a result of the discussion, it was decided 
that the initial implementation would occur in C.

----->o-----
We shifted to discussing PCI preservation.  Chris Li noted that v2 would 
be scoped to only preserving the bus master bit and not doing any DMAs.  
He was looking to send out the next series of patches end of this week.  
Praveen Kumar asked if the hand over was part of this code, Chris 
clarified that it is not.  Jason asked how this would be tested, Chris 
said that he was going to be checking with a printk on the other side of 
the kexec.  Chris said his next step was likely to extend for a networking 
card that would allow the packet to keep being sent.

Jason suggested the next step might be to make VFIO work with noiommu and 
idx testing.  He suggested doing the IOMMU side last.

Vipin Sharma subsequently noted that he followed up internally and wanted 
to discuss interrupts being disabled and then blindly inserted into the 
guest after host kexec.  He said the PCI specification allows for masking 
the interrupt and there's a pending bit array that can optimize for what 
interrupts we are installing in the guest.  Jason suggested this might be 
done as a follow up but will be more complicated.

----->o-----
We moved on to a discussion from Chris Li about what he referred to as 
KSerial and this solicited a lot of feedback.  KSerial was a serialization 
protocol between two kernels, specifically structs between the old and new 
kernel.  He proposed depositing members of the struct into a wire format 
so that it's not tied to the kernel implementation that the new kernel 
would read from.

Jason provided some feedback that we will never want to serialize IOMMU 
groups, they should be discovered independently.  Same situation for a PCI 
structure pointing to a bus, which Jason also said we should not be 
serializing.  Pasha said the focus should be on the generic format for 
preserving anything, not specific to just PCI without using FDT (which 
should be read only).  Jason expressed a concern about very complex 
support that is not yet proven to be needed; Jason strongly suggested 
against preserving native C structs.

Pratyush asked about FDT and suggested there was a lot of boiler plate 
that you have to write to even get simple things validated.  Chris said 
this would indeed by additional developer burden.

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

Topics for the next meeting:

 - update on latest status of LUO after v4 and next steps for merge into
   akpm's tree
 - any updates on luod based on internal and external feedbcck
 - update on making KHO stateless and preserving page tables, dependencies
   on high-order page allocations, any next steps
 - update on memfd preservation and status of 1GB limitation before
   integration into akpm's tree
 - update on the latest status of PCI preservation, registration, and
   initialization
 - any updates on VFIO with noiommu as a next step for preservation after
   Chris's v2
 - 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

Please let me know if you'd like to propose additional topics for
discussion, thank you!



More information about the kexec mailing list