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-dmatl...@google.com/
