Re: [PATCH] KVM: optionally post write on ioeventfd write

[Sean Christopherson <seanjc@google.com>]

On Thu, Mar 12, 2026, Thanos Makatos wrote:
> > From: David Woodhouse <dwmw2@infradead.org>
> > On Fri, 2026-03-06 at 12:56 +0000, Thanos Makatos wrote:
> > > Add a new flag, KVM_IOEVENTFD_FLAG_POST_WRITE, when assigning an
> > > ioeventfd that results in the value written by the guest to be copied
> > > to user-supplied memory instead of being discarded.
> > >
> > > The goal of this new mechanism is to speed up doorbell writes on NVMe
> > > controllers emulated outside of the VMM. Currently, a doorbell write to
> > > an NVMe SQ tail doorbell requires returning from ioctl(KVM_RUN) and the
> > > VMM communicating the event, along with the doorbell value, to the NVMe
> > > controller emulation task.  With POST_WRITE, the NVMe emulation task is
> > > directly notified of the doorbell write and can find the doorbell value
> > > in a known location, without involving VMM.

...

> > I'd love to see if this KVM_IOEVENTFD_FLAG_POST_WRITE works for the
> > i82559 emulation use case. I think back-to-back writes are discarded
> > with this model, while Ilias's patches would convey each one?

Do you happen to know the requirements for i82559 emulation?  I tried reading the
spec and QEMU's code, and that was just a waste of ~20 minutes :-)

> Yes, they're discarded, only the last write is visible, and this is by design
> to fit the NVMe doorbell use case.

I wouldn't say the design is specifically to fit the NVMe doorbell use case,
rather that KVM doesn't need to convey each write to support NVMe doorbells, and
forwarding only the most recent value is a massive "win" for complexity.

Which, for me, is also the argument for accepting KVM_IOEVENTFD_FLAG_POST_WRITE
even if there are a limited number of use cases: it's simple (and performant)
enough that it's probably worth supporting even if similar functionality can be
implemented via polling on coalesced I/O buffers.  I.e. maintaing both doesn't
seem too onerous, if that's where we wend up.

> ioregionfd,
> https://lore.kernel.org/all/88ca79d2e378dcbfb3988b562ad2c16c4f929ac7.camel@gmail.com,
> was a similar proposal for forwarding MMIO writes without discarding
> back-to-back writes.

And if you were curious what the code looked like:

https://lore.kernel.org/kvm/cover.1613828726.git.eafanasova@gmail.com