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

[Chenghao Duan <duanchenghao@kylinos.cn>]

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.

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?

> 
> [...]
> 
> -- 
> Regards,
> Pratyush Yadav