From: sashiko-bot@kernel.org
To: "Thanos Makatos" <thanos.makatos@nutanix.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH v2] KVM: optionally post write on ioeventfd write
Date: Tue, 27 Oct 2026 18:34:11 +0000 [thread overview]
Message-ID: <sashiko-outbox-187032@kernel.org> (raw)
In-Reply-To: <20261027180903.1008-1-thanos.makatos@nutanix.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] KVM: eventfd: require natural alignment for post_addr in kvm_assign_ioeventfd_idx()
--
commit c6cd7519e7f3bd3af324596a345f4b346eac3929
Author: Thanos Makatos <thanos.makatos@nutanix.com>
KVM: optionally post write on ioeventfd write
This commit introduces KVM_IOEVENTFD_FLAG_POST_WRITE to copy the value
written by a guest on an ioeventfd MMIO or PIO access to a user-provided
address before signaling the eventfd, along with documentation and x86
selftests.
> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
> index f43b8b25bc854..b0f2a6b43e354 100644
> --- a/virt/kvm/eventfd.c
> +++ b/virt/kvm/eventfd.c
[ ... ]
> @@ -811,8 +819,36 @@ ioeventfd_write(struct kvm_vcpu *vcpu, struct kvm_io_device *this, gpa_t addr,
> 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;
> + }
> +
> eventfd_signal(p->eventfd);
> return 0;
> +unsupported_len:
> + return -EOPNOTSUPP;
> }
>
> /*
> @@ -872,6 +908,18 @@ static int kvm_assign_ioeventfd_idx(struct kvm *kvm,
> if (IS_ERR(eventfd))
> return PTR_ERR(eventfd);
>
> + /*
> + * Disallow posting to virtual address 0 so that KVM can treat
> + * a NULL user pointer as "no posted write".
> + */
> + if ((args->flags & KVM_IOEVENTFD_FLAG_POST_WRITE) &&
> + (!args->len || !u64_to_user_ptr(args->post_addr) ||
> + args->post_addr != untagged_addr(args->post_addr) ||
> + !access_ok(u64_to_user_ptr(args->post_addr), args->len))) {
> + ret = -EINVAL;
> + goto fail;
> + }
[Severity: Medium]
Should kvm_assign_ioeventfd_idx() in virt/kvm/eventfd.c also require
args->post_addr to be naturally aligned to args->len via
IS_ALIGNED(args->post_addr, args->len)?
In Documentation/virt/kvm/api.rst, KVM_IOEVENTFD_FLAG_POST_WRITE documents
that when multiple vCPUs write to the same ioeventfd concurrently, the value
at post_addr reflects one of the writes, and that if the copy to post_addr
fails, the eventfd is not signaled and the write is reported to userspace as
a regular MMIO/PIO exit.
When userspace registers an ioeventfd with KVM_IOEVENTFD_FLAG_POST_WRITE,
args->len in {2, 4, 8}, and an unaligned args->post_addr, subsequent guest
writes invoke ioeventfd_write() -> put_user() on p->post_addr:
1. On x86 and arm64, an unaligned 2-, 4-, or 8-byte put_user() store that
crosses a cache-line (or 16-byte on arm64) or page boundary is split into
multiple memory transactions and is not single-copy atomic, so concurrent
vCPU writes can tear.
2. On RISC-V without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS,
__put_user_nocheck() in arch/riscv/include/asm/uaccess.h checks
!IS_ALIGNED((uintptr_t)__gu_ptr, sizeof(*__gu_ptr)) and falls back to
__asm_copy_to_user_sum_enabled(), which copies byte-by-byte in
arch/riscv/lib/uaccess.S and tears on any unaligned post_addr.
3. If an unaligned post_addr straddles a mapped page and an unmapped page,
put_user() partially overwrites the first page before faulting on the
second page and returning -EFAULT.
4. On architectures such as MIPS (do_ade() in arch/mips/kernel/unaligned.c
when unaligned_action == UNALIGNED_ACTION_SIGNAL) and LoongArch (do_ale()
in arch/loongarch/kernel/traps.c when unaligned emulation is disabled or
absent), an unaligned put_user() traps in kernel mode and calls
die_if_kernel() without running fixup_exception().
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261027180903.1008-1-thanos.makatos@nutanix.com?part=1
next prev parent reply other threads:[~2026-10-27 18:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 12:56 [PATCH] KVM: optionally post write on ioeventfd write Thanos Makatos
2026-03-12 15:02 ` David Woodhouse
2026-03-12 16:12 ` Thanos Makatos
2026-04-21 14:44 ` Sean Christopherson
2026-09-19 15:59 ` David Woodhouse
2026-03-23 15:01 ` Thanos Makatos
2026-04-10 19:11 ` Thanos Makatos
2026-04-21 14:45 ` Sean Christopherson
2026-06-10 7:31 ` John Levon
2026-09-22 13:51 ` Stefan Hajnoczi
2026-09-22 15:28 ` David Woodhouse
2026-09-22 16:47 ` Sean Christopherson
2026-10-04 16:16 ` David Woodhouse
2026-10-05 5:11 ` Sean Christopherson
2026-10-15 8:44 ` David Woodhouse
2026-10-15 18:23 ` Stefan Hajnoczi
2026-10-15 18:43 ` David Woodhouse
2026-10-19 19:48 ` Stefan Hajnoczi
2026-10-26 19:29 ` Thanos Makatos
2026-09-22 17:03 ` Sean Christopherson
2026-10-27 17:50 ` Thanos Makatos
2026-10-27 18:09 ` [PATCH v2] " Thanos Makatos
2026-10-27 18:34 ` sashiko-bot [this message]
2026-10-28 8:32 ` Thanos Makatos
2026-10-28 13:09 ` Stefan Hajnoczi
2026-10-28 16:22 ` Thanos Makatos
2026-10-28 16:47 ` [PATCH v3] " Thanos Makatos
2026-10-28 18:39 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-187032@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=thanos.makatos@nutanix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox