On Tue, Jun 30 2026, David Matlack wrote: > On Mon, Jun 29, 2026 at 3:06 AM Chenghao Duan <[email protected]> wrote: >> >> On Thu, Jun 25, 2026 at 11:06:04AM +0200, Pratyush Yadav wrote: >> > On Thu, Jun 25 2026, Chenghao Duan wrote: >> > >> > > This patch adds support for preserving eventfd file descriptors across >> > > kexec live updates using the Live Update Orchestrator (LUO) framework. >> > > Userspace applications using eventfd for event notification can now >> > > maintain their state across kernel updates. >> > > >> > > Preserved State: >> > > The following properties of the eventfd are preserved across kexec: >> > > - Counter Value: The current 64-bit counter value, including any pending >> > > events that have been signaled but not yet consumed by readers. >> > > - File Flags: The creation flags (EFD_SEMAPHORE, EFD_CLOEXEC, >> > > EFD_NONBLOCK) >> > > are preserved. >> > > >> > > Non-Preserved State: >> > > - File Descriptor Number: The eventfd will be assigned a new fd number >> > > in the target process after restore. >> > > - Wait Queue State: Any processes blocked on read() operations will be >> > > woken up and need to re-establish their blocking state. >> > > - All other internal state is reset to default. >> > > >> > > Changes: >> > > - fs/eventfd.c: Add eventfd_luo_get_state() to safely read eventfd state >> > > (count and flags), and eventfd_create() helper function. >> > > - fs/eventfd_luo.c: New file implementing LUO file operations: >> > > preserve, freeze, unpreserve, retrieve, and finish callbacks. >> > > - include/linux/eventfd.h: Export new functions. >> > > - include/linux/kho/abi/eventfd.h: Define the ABI contract with >> > > eventfd_luo_ser structure for serialization. >> > >> > Why do you need to preserve this? Why don't you create a fresh one after >> > kexec? You just preserve the counter, which looks pretty much useless. >> > You can just as well open a new eventfd after kexec and set the counter >> > value if you care about it. >> >> Thank you very much for your review and suggestions. >> >> My original plan was to integrate KVM with eventfd. Eventfd serves as a >> critical notification mechanism between guest and host, and it is widely >> adopted in various scenarios such as networking, file systems, and >> interrupt handling. >> >> At present, however, I have only implemented the preserve and retrieve >> logic for eventfd, and the integration with KVM has not yet been >> completed. >> >> I have a question and would greatly appreciate your help with it. >> I have been closely following upstream developments for the liveupdate >> feature. As I understand it, liveupdate is primarily targeted at cloud >> virtual machine scenarios. The upstream community has completed the >> core framework for liveupdate and memfd, and ongoing discussions are >> focused on state preservation and restoration for VFIO and IOMMU. > > Yes that's correct, but that work is to solve some very specific > problems for virtual machine scenarios: > > 1. memfd preservation allows preserving guest memory and userspace > (e.g. VMM) state in-place across Live Update. > 2. VFIO/IOMMU preservation allows PCIe devices assigned to virtual > machines to keep running uninterrupted across Live Update. > > I think this series is missing a description of the problem solved by > preserving eventfds. We don't want to preserve all types of fds just > for the sake of it. That will bloat the ABI (which will make > maintaining version compaitibility harder) without any gain.
Yep. I'm not an expert on eventfd/KVM, but from my reading it looks like it is only a signaling mechanism, and you can set it up fresh after a live update, before you resume your VMs. There is no state here that needs to be preserved. Without a good reason on _why_ the eventfd state needs to be preserved, I don't think this series should go forward. > >> >> I would like to clarify the following points regarding upstream’s >> overall roadmap for the liveupdate feature: >> 1. What is the complete upstream plan for liveupdate? I don't think there is a single "upstream plan" anywhere. But I reckon the next few things I have seen people work on are adding support for VFIO, PCI, IOMMU, guest_memfd, HugeTLB. Maybe TDX or other confidential compute at some point, though I haven't seen anything concrete about them. >> 2. What will the final deliverables look like once fully implemented? >> 3. Will any new kernel internal interfaces or dedicated userspace tools >> be introduced? Who knows, we add kernel interfaces when we see a need for it. Systemd has recently gained support for live update. >> 4. Does the upstream community maintain an official TODO list tracking >> outstanding work items for liveupdate? > > I don't think we have anything comprehensive but there is a ton of > work to be done if you are looking to help. > > A good first step would be to attend the bi-weekly Hypervisor Live > Update meeting. See > https://lore.kernel.org/kexec/[email protected]/. The next > one is on July 13th. +1 -- Regards, Pratyush Yadav
