Re: [RFC PATCH] KVM: optionally commit write on ioeventfd write

[Sean Christopherson <seanjc@google.com>]

On Tue, Dec 02, 2025, Thanos Makatos wrote:
> > -----Original Message-----
> > I think it's also worth hoisting the validity
> > checks into kvm_assign_ioeventfd_idx() so that this can use the slightly more
> > optimal __copy_to_user().
> > 
> > E.g.
> > 
> > 	if (args->flags & KVM_IOEVENTFD_FLAG_REDIRECT) {
> > 		if (!args->len || !args->post_addr ||
> > 		    != untagged_addr(args->post_addr) ||
> > 		    !access_ok((void __user *)(unsigned long)args->post_addr, args->len)) {
> > 			ret = -EINVAL;
> > 			goto fail;
> > 		}
> > 
> > 		p->post_addr = (void __user *)(unsigned long)args-
> > >post_addr;
> > 	}
> > 
> > And then the usage here can be
> > 
> > 	if (p->post_addr && __copy_to_user(p->post_addr, val, len))
> > 		return -EFAULT;
> > 
> 
> Did you mean to write __copy_to_user(p->redirect, val, len) here?

I don't think so?  Ah, it's KVM_IOEVENTFD_FLAG_REDIRECT that's stale.  That
should have been something like KVM_IOEVENTFD_FLAG_POST_WRITES.

> > I assume the spinlock in eventfd_signal() provides ordering even on weakly
> > ordered architectures, but we should double check that, i.e. that we don't
> > need an explicitly barrier of some kind.
> 
> Are you talking about the possibility of whoever polls the eventfd not
> observing the value being written?

Ya, KVM needs to ensure the write is visible before the wakeup occurs.

Side topic, Paolo had an off-the-cuff idea of adding uAPI to support notifications
on memslot ranges, as opposed to posting writes via ioeventfd.  E.g. add a memslot
flag, or maybe a memory attribute, that causes KVM to write-protect a region,
emulate in response to writes, and then notify an eventfd after emulating the
write.  It'd be a lot like KVM_MEM_READONLY, except that KVM would commit the
write to memory and notify, as opposed to exiting to userspace.