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

[Pratyush Yadav]

On Tue, Jun 30 2026, David Matlack wrote:

> On Mon, Jun 29, 2026 at 3:06 AM Chenghao Duan <duanchenghao@xxxxxxxxxx> 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/aiWW6ZwwalqQmVcB@xxxxxxxxxx/. The next
> one is on July 13th.

+1

-- 
Regards,
Pratyush Yadav