From: Will Deacon <will@kernel.org>
To: Xie Bo <xb@ultrarisc.com>
Cc: kvm@vger.kernel.org,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Anup Patel <anup@brainfault.org>
Subject: Re: [PATCH kvmtool] virtio: 9p: Order used ring updates before notifications
Date: Fri, 31 Jul 2026 18:08:36 +0100 [thread overview]
Message-ID: <amzWlInb1rgkRy_4@google.com> (raw)
In-Reply-To: <20260724091046.1868685-1-xb@ultrarisc.com>
On Fri, Jul 24, 2026 at 05:10:41PM +0800, Xie Bo wrote:
> virtio_p9_do_io() signals the guest immediately after adding each
> request to the used ring. Unlike the block and net backends, it bypasses
> virtio_queue__should_signal(), which provides the full memory barrier
> needed between publishing used->idx and injecting the interrupt.
>
> On weakly ordered architectures, the guest can therefore handle the
> interrupt before the updated used->idx becomes visible. If it observes
> the old index and goes back to sleep, the completed request can remain
> stuck indefinitely because no further interrupt is generated.
>
> This was observed on RISC-V with two 9p RPCs blocked while the host
> used->idx was two entries ahead of the guest's last_used_idx.
>
> Process all available requests first, then use
> virtio_queue__should_signal() before notifying the guest. Besides
> providing the required ordering, this also honors the driver's
> notification suppression request.
>
> Fixes: 1c7850f95903 ("kvm tools: Add virtio-9p")
> Signed-off-by: Xie Bo <xb@ultrarisc.com>
> ---
> virtio/9p.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/virtio/9p.c b/virtio/9p.c
> index cf3e547..d2680e9 100644
> --- a/virtio/9p.c
> +++ b/virtio/9p.c
> @@ -1372,11 +1372,15 @@ static void virtio_p9_do_io(struct kvm *kvm, void *param)
> struct p9_dev_job *job = (struct p9_dev_job *)param;
> struct p9_dev *p9dev = job->p9dev;
> struct virt_queue *vq = job->vq;
> + bool completed = false;
>
> while (virt_queue__available(vq)) {
> virtio_p9_do_io_request(kvm, job);
> - p9dev->vdev.ops->signal_vq(kvm, &p9dev->vdev, vq - p9dev->vqs);
> + completed = true;
> }
> +
> + if (completed && virtio_queue__should_signal(vq))
> + p9dev->vdev.ops->signal_vq(kvm, &p9dev->vdev, vq - p9dev->vqs);
Why do you need the 'completed' bool here? Can't we just rely on
virtio_queue__should_signal() instead?
Will
prev parent reply other threads:[~2026-07-31 17:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 9:10 [PATCH kvmtool] virtio: 9p: Order used ring updates before notifications Xie Bo
2026-07-31 17:08 ` Will Deacon [this message]
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=amzWlInb1rgkRy_4@google.com \
--to=will@kernel.org \
--cc=anup@brainfault.org \
--cc=julien.thierry.kdev@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=xb@ultrarisc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.