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

[Sean Christopherson <seanjc@google.com>]

On Tue, Sep 22, 2026, David Woodhouse wrote:
> On Tue, 2026-09-22 at 09:51 -0400, Stefan Hajnoczi wrote:
> > On Fri, Mar 06, 2026 at 12:56:54PM +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.
> > > 
> > > Add tests for this new functionality.
> > > 
> > > LLM (claude-4.6-opus-high) was used mainly for the tests and to a
> > > lesser extent for pre-reviewing this patch.
> > > 
> > > Signed-off-by: Thanos Makatos <thanos.makatos@nutanix.com>
> > > ---
> > >  Documentation/virt/kvm/api.rst               |  13 +-
> > >  include/uapi/linux/kvm.h                     |   6 +-
> > >  tools/testing/selftests/kvm/Makefile.kvm     |   1 +
> > >  tools/testing/selftests/kvm/ioeventfd_test.c | 624 +++++++++++++++++++
> > >  virt/kvm/eventfd.c                           |  23 +
> > >  virt/kvm/kvm_main.c                          |   1 +
> > >  6 files changed, 666 insertions(+), 2 deletions(-)
> > >  create mode 100644 tools/testing/selftests/kvm/ioeventfd_test.c
> > 
> > Sean, Paolo: Ping
> > 
> > I would like to enable ioeventfd support in QEMU's NVMe device emulation
> > and this requires POST_WRITE for Windows guests (they don't support
> > NVMe's Doorbell Buffer Config feature so it's necessary to capture the
> > latest value written to the doorbell somehow).
> > 
> > POST_WRITE applies to any device that has a doorbell register where the
> > latest value needs to be captured. This looks like a reasonable
> > extension to ioeventfd.
> > 
> > I also looked into alternatives, like using userfaultfd, and didn't find
> > anything better.
> > 
> > Please consider merging this. Thanks!
> 
> I said I was working on using this for i82559 emulation; I have that
> working now, and POST_WRITE is perfectly sufficient.
> 
> I think I'd prefer to see it use a WRITE_ONCE to the userspace address
> rather than a __copy_to_user() which could theoretically tear,

Hrm, I was going to say that's a "feature" of sorts, not a bug, as eventfd_signal()
provides ordering by way of its spinlock, but I'm guessing that the userspace side
wants to read the tail pointer multiple times per wakeup, i.e. wants to eagerly
process all transactions.

I don't see any explicit documentation with respect to put_user() providing
atomicity guarantees, but unsafe_atomic_store_release_user() uses unsafe_put_user(),
so presumably that's an undocumented requirement?  Ah, not a requirement so much as
a "this will work so long as userspace isn't being stupid".  E.g. a 64-bit write
on a 32-bit x86 host is doomed unless KVM goes to extreme lengths.

So, if we want a best effort approach something end up with something like the
(compile-tested-only) below?  As ugly as it is, I think it has my vote, because
it should Just Work for the majority of use cases.

#define ioeventfd_get_val(__ptr, __len, __unsupported_len)	\
({								\
	u64 __val;						\
								\
	switch (len) {						\
	case 1:							\
		__val = get_unaligned((u8 *)__ptr);		\
		break;						\
	case 2:							\
		__val = get_unaligned((u16 *)__ptr);		\
		break;						\
	case 4:							\
		__val = get_unaligned((u32 *)__ptr);		\
		break;						\
	case 8:							\
		__val = get_unaligned((u64 *)__ptr);		\
		break;						\
	default:						\
		goto __unsupported_len;				\
	}							\
	__val;							\
})

static bool
ioeventfd_in_range(struct _ioeventfd *p, gpa_t addr, int len, const void *val)
{
	if (addr != p->addr)
		/* address must be precise for a hit */
		return false;

	if (!p->length)
		/* length = 0 means only look at the address, so always a hit */
		return true;

	if (len != p->length)
		/* address-range must be precise for a hit */
		return false;

	if (p->wildcard)
		/* all else equal, wildcard is always a hit */
		return true;

	/* otherwise, we have to actually compare the data */
	return ioeventfd_get_val(val, len, unsupported_len) == p->datamatch;

unsupported_len:
	return false;
}

/* MMIO/PIO writes trigger an event if the addr/val match */
static int
ioeventfd_write(struct kvm_vcpu *vcpu, struct kvm_io_device *this, gpa_t addr,
		int len, const void *val)
{
	struct _ioeventfd *p = to_ioeventfd(this);

	if (!ioeventfd_in_range(p, addr, len, val))
		return -EOPNOTSUPP;

	if (p->post_addr) {
		u64 _val = ioeventfd_get_val(val, len, unsupported_len);
		int r;

		switch (len) {
		case 1:
			r = put_user(_val, (u8 __user *)p->post_addr);
			break;
		case 2:
			r = put_user(_val, (u16 __user *)p->post_addr);
			break;
		case 4:
			r = put_user(_val, (u32 __user *)p->post_addr);
			break;
		case 8:
			r = put_user(_val, (u64 __user *)p->post_addr);
			break;
		default:
			WARN_ON_ONCE(1);
			r = 0;
			break;
		}
		if (r)
			return r;

	}

unsupported_len:
	eventfd_signal(p->eventfd);
	return 0;
}