From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jorge Moreira <jemoreira@google.com>,
Stefano Garzarella <sgarzare@redhat.com>,
hreitz@redhat.com, gmaglione@redhat.com,
Hanna Czenczek <xanclic@gmail.com>,
Pierrick Bouvier <pierrick.bouvier@linaro.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCH] vhost-user.rst: Explicitly allow front-end to write to kick FDs
Date: Wed, 29 Apr 2026 11:50:55 -0400 [thread overview]
Message-ID: <20260429155055.GA12211@fedora> (raw)
In-Reply-To: <20260428025111-mutt-send-email-mst@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4637 bytes --]
On Tue, Apr 28, 2026 at 02:59:58AM -0400, Michael S. Tsirkin wrote:
> On Mon, Apr 27, 2026 at 06:45:45PM -0400, Stefan Hajnoczi wrote:
> > On Wed, Apr 22, 2026 at 12:20:52PM -0700, Jorge Moreira wrote:
> > > On Wed, Apr 22, 2026 at 1:32 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
> > > >
> > > > On Wed, 22 Apr 2026 at 03:16, Jorge Moreira <jemoreira@google.com> wrote:
> > > > >
> > > > > On Tue, Apr 21, 2026 at 2:12 PM Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > > > > >
> > > > > > On Mon, Apr 20, 2026 at 05:48:13PM -0700, Jorge Moreira wrote:
> > > > > > > While starting the vrings on SET_VRING_KICK could solve the state
> > > > > > > machine issue, it still won't notify the back-end that buffers are
> > > > > > > ready (the driver won't do this). Non-polling back-ends depend on this
> > > > > > > kick, especially for queues where data flows only from the driver to
> > > > > > > the back-end. Most implementations likely attempt to read from the
> > > > > > > queue only after receiving the kick.
> > > > > >
> > > > > > This is an interesting question to clarify in the spec.
> > > >
> > > > Yep, which is in part related to what I wrote in the other reply:
> > > > "I think the main issue to clarify is what the device should do
> > > > when the vrings are configured, but the driver has already been
> > > > initialized (which is usually the case after migration)."
> > > >
> > > > > >
> > > > > > Stefan
> > > > >
> > > > > This is the question that interests me most, to be honest. I'd rather
> > > > > have the discussion about when to activate the vrings in a different
> > > > > thread and keep this one focused on whether the front-end should send
> > > > > the kick or if the back-end is expected to check if there are "new"
> > > > > buffers in the vring after restore.
> > > > >
> > > >
> > > > IMO we don't need anything from the VMM. When the device receives
> > > > SET_VRING_KICK, it can check if the vring already contains buffers
> > > > (and this is the part we might need to clarify) and wake-up the other
> > > > threads (or always wake-ups them, as crosvm does IIUC, and let them
> > > > perform this check).
> > > > After sending the SET_VRING_KICK message to the device, the VMM has
> > > > the exact same knowledge of the vring state as the device, therefore,
> > > > it's still unclear to me why we need to inject that kick.
> > > >
> > > > Stefano
> > > >
> > >
> > > Is it possible to activate a vring after it has been deactivated with
> > > VHOST_USER_GET_VRING_BASE? If yes, does the front-end need to send the
> > > kick file descriptor again with VHOST_USER_SET_VRING_KICK to
> > > reactivate it?
> >
> > Hi Jorge and Stefano,
> > Yes, VHOST_USER_GET_VRING_BASE -> VHOST_USER_SET_VRING_KICK occurs when
> > a VM is paused and then resumed.
> >
> > You can stress test this by driving I/O using iperf (virtio-net) or fio
> > (virtio-blk) inside the guest and sending 'stop'/'cont' commands to
> > QEMU's monitor.
> >
> > Here is QEMU's code for starting (including re-starting) rings:
> > https://gitlab.com/qemu-project/qemu/-/blob/master/hw/virtio/vhost.c?ref_type=heads#L1341
> >
> > QEMU does not inject a kick. The back-end must check the rings itself.
>
>
> I would worry that there could be buggy drivers that expect buffers not
> consumed until the 1st kick.
This describes the behavior today. I'm not sure whether you are
commenting on the paragraph I wrote below suggesting how to change
things or whether you are commenting on the current state?
> A safer thing to do would be for source to record the fact there
> was a kick after reset and for destination to then inject/check.
Can you rephrase that, it's unclear to me what "source" and
"destination" mean?
Thanks,
Stefan
> > I'm not sure that all vhost-user back-ends actually check the rings. I
> > think back-ends should do it, but we should also update the spec with an
> > front-end implementation note recommending injecting a kick after
> > VHOST_USER_SET_VRING_KICK completes in order to maximize compatibility
> > with implementations that follow the current spec wording. And at the
> > same time I think the spec should also be changed to say that
> > VHOST_USER_SET_VRING_KICK starts the ring and back-ends SHOULD check the
> > vring upon processing the message.
> >
> > That seems like it would clean up the issues without introducing
> > compatibility issues or making existing implementations non-compliant
> > with the updated spec.
> >
> > What do you think?
> >
> > Stefan
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2026-04-29 15:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-11 2:12 [PATCH] vhost-user.rst: Explicitly allow front-end to write to kick FDs Jorge E. Moreira
2026-04-20 14:49 ` Stefano Garzarella
2026-04-20 15:57 ` Stefano Garzarella
2026-04-21 20:51 ` Stefan Hajnoczi
2026-04-22 8:25 ` Stefano Garzarella
2026-04-20 18:18 ` Stefan Hajnoczi
2026-04-21 0:48 ` Jorge Moreira
2026-04-21 7:55 ` Stefano Garzarella
2026-04-21 16:06 ` Jorge Moreira
2026-04-21 16:49 ` Stefano Garzarella
2026-04-21 19:57 ` Stefan Hajnoczi
2026-04-21 21:12 ` Stefan Hajnoczi
2026-04-22 1:16 ` Jorge Moreira
2026-04-22 8:32 ` Stefano Garzarella
2026-04-22 19:20 ` Jorge Moreira
2026-04-27 22:45 ` Stefan Hajnoczi
2026-04-27 22:48 ` Jorge Moreira
2026-04-28 14:33 ` Stefano Garzarella
2026-04-28 17:19 ` Jorge Moreira
2026-04-29 14:26 ` Stefano Garzarella
2026-04-29 16:00 ` Stefan Hajnoczi
2026-04-29 15:55 ` Stefan Hajnoczi
2026-04-28 6:59 ` Michael S. Tsirkin
2026-04-29 15:50 ` Stefan Hajnoczi [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=20260429155055.GA12211@fedora \
--to=stefanha@redhat.com \
--cc=gmaglione@redhat.com \
--cc=hreitz@redhat.com \
--cc=jemoreira@google.com \
--cc=mst@redhat.com \
--cc=pierrick.bouvier@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.com \
--cc=xanclic@gmail.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.