[Hypervisor Live Update] Notes from June 16, 2025

[David Rientjes]

Hi everybody,

Here are the notes from the last Hypervisor Live Update call that happened 
on Monday, June 16.  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-----
There are no curent blockers fro LUO, Pasha noted that he was doing more
changes and added session support and the ability to track which fd's get
registered while the device is open and then get removed when they are
closed.  He also cleaned up the UAPI.

Pratyush said the memfd preservation code was almost ready to go, just
needing to update documentation.  This was being integrated with the
latest LUO series.  He also noted some changes for libluo and updates for
the test suite.  Once the tests and documentation are completed, there
shouldn't be any work left before the next series.  Pratyush noted this
should be ready by the end of this week.

----->o-----
Pasha started a discussion on liveupdated, a userspace daemon, to keep the
sessions alive so everybody can register and unregister the fds.  It may
even take strings from the callers so that the callers can associate
themselves with the specific fds after restore.  Pratyush was
experimenting with something similar and said it may make sense to add
this to libluo.

For systemd, we weren't sure if it was possible to prevent systemd from
killing one specific process during a graceful shutdown.  We'd want
liveupdated to survive the userspace shutdown.  We could theoretically
have a live update target that never kills everything, but would be
useful to discuss this with systemd folks.  liveupdated could even become
part of systemd itself.  Jason said that the way the systemd dependency
engine works that reboot isn't anything special so if the process is out
of reboot then this should work fine.

Pratyush noted liveupdated would be a critical component for using LUO.
He had been poking around and thought traditional sockets would be
sufficient for passing around the policies and determining which process
gets which fd.  Pasha said it should be self sustaining and not requiring
external storage.

----->o-----
Ben Chaney asked if the current support for memfd preservation supports
memory overcommit, i.e. swapped pages.  Pratyush said the current approach
does not support overcommit although it could be added (although it would
be complex).

I asked about the use cases for supporting overcommit for memfd
preservation.  Pratyush noted there are some databases that swap out part
of user memory and for these processes to come back up after kexec
quickly, they may want preservation even though it is outside the scope
of hypervisor live update.  Ben said they'd also likely use it if it were
available for live update.

----->o-----
We discussed token numbers and agreed that liveupdated would need to know
its own token number, perhaps a specific token number that specifies that
the process is liveupdated.  Pratyush noted in fdbox work that he allowed
userspace to specify the string rather than the kernel choosing the fd.

Pasha suggested letting the kernel control the token primarily so there
are no conflicts they can be controlled through liveupdated.  Pratyush
asked if liveupdated could always control the token numbers itself and
Pasha believed this to be reasonable.

Mike mentioned upstream feedback during code review of fdbox for fdstore.
He suggested there may be something in terms of approach that could be
leveraged there.  Pratyush noted that fdstore may allow the callers to
name the fds.  liveupdated can control the token itself and that seemed
aligned with the group; Pasha said this can be done in LUO v3.

Praveen Kumar asked about the fallback mechanism if liveupdated fails.
Since it is critical process, then live update would not be possible.  If
liveupdated is re-forked, then anybody who registered fds with it would
have to do this again.

----->o-----
I started talking about selftesting frameworks under tools/.  Pratyush
noted that he had tests but they lack qemu wrappers so you need to reboot
manually.

David Matlack noted that sent out the RFC for VFIO selftests[1] and he was
planning on sending out the actual v1 this week.

----->o-----
Update: the physical pool allocator topic that was mentioned for June 30
will instead be delayed until the next instance on July 14.

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

Topics for the next meeting:

 - discuss potentially switching future meetings from 60 min -> 30 min
   now that a lot of development is underway
 - discuss current status of LUO and controlling the tokens, any blockers
   for upstream merge
 - discuss current status of memfd preservation, testing, and
   documentation
 - discuss liveupdated that is responsible for the fd's, the ioctls, and
   the state machine that interacts with LUO, and interaction with
   systemd
 - determine timelines for selftest framework for live updates and VFIO
   selftests
 - discuss status of LPC microconference acceptance
 - July 12: update on physical pool allocator that can be used to provide
   pages for hugetlb, guest_memfd, and memfds
 - 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!

[1] 
https://lore.kernel.org/kvm/20250523233018.1702151-1-dmatlack@google.com/