Re: [PATCH v1 1/2] eventfd: luo: luo support for preserving eventfd

[David Matlack <dmatlack@google.com>]

On Mon, Jun 29, 2026 at 3:06 AM Chenghao Duan <duanchenghao@kylinos.cn> 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.

>
> 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?
> 2. What will the final deliverables look like once fully implemented?
> 3. Will any new kernel internal interfaces or dedicated userspace tools
> be introduced?
> 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/aiWW6ZwwalqQmVcB@google.com/. The next
one is on July 13th.