From: Stefan Hajnoczi <stefanha@redhat.com>
To: Hanna Czenczek <hreitz@redhat.com>
Cc: qemu-devel@nongnu.org, virtio-fs@redhat.com,
"Michael S . Tsirkin" <mst@redhat.com>,
"German Maglione" <gmaglione@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Anton Kuchin" <antonkuchin@yandex-team.ru>
Subject: Re: [Virtio-fs] [PATCH v4 3/8] vhost-user.rst: Clarify enabling/disabling vrings
Date: Thu, 5 Oct 2023 13:43:33 -0400 [thread overview]
Message-ID: <20231005174333.GD1342722@fedora> (raw)
In-Reply-To: <20231004125904.110781-4-hreitz@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]
On Wed, Oct 04, 2023 at 02:58:59PM +0200, Hanna Czenczek wrote:
> Currently, the vhost-user documentation says that rings are to be
> initialized in a disabled state when VHOST_USER_F_PROTOCOL_FEATURES is
> negotiated. However, by the time of feature negotiation, all rings have
> already been initialized, so it is not entirely clear what this means.
>
> At least the vhost-user-backend Rust crate's implementation interpreted
> it to mean that whenever this feature is negotiated, all rings are to
> put into a disabled state, which means that every SET_FEATURES call
> would disable all rings, effectively halting the device. This is
> problematic because the VHOST_F_LOG_ALL feature is also set or cleared
> this way, which happens during migration. Doing so should not halt the
> device.
>
> Other implementations have interpreted this to mean that the device is
> to be initialized with all rings disabled, and a subsequent SET_FEATURES
> call that does not set VHOST_USER_F_PROTOCOL_FEATURES will enable all of
> them. Here, SET_FEATURES will never disable any ring.
>
> This interpretation does not suffer the problem of unintentionally
> halting the device whenever features are set or cleared, so it seems
> better and more reasonable.
>
> We can clarify this in the documentation by making it explicit that the
> enabled/disabled state is tracked even while the vring is stopped.
> Every vring is initialized in a disabled state, and SET_FEATURES without
> VHOST_USER_F_PROTOCOL_FEATURES simply becomes one way to enable all
> vrings.
>
> Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
> ---
> docs/interop/vhost-user.rst | 32 +++++++++++++++++---------------
> 1 file changed, 17 insertions(+), 15 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Hanna Czenczek <hreitz@redhat.com>
Cc: qemu-devel@nongnu.org, virtio-fs@redhat.com,
"Michael S . Tsirkin" <mst@redhat.com>,
"German Maglione" <gmaglione@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Anton Kuchin" <antonkuchin@yandex-team.ru>
Subject: Re: [PATCH v4 3/8] vhost-user.rst: Clarify enabling/disabling vrings
Date: Thu, 5 Oct 2023 13:43:33 -0400 [thread overview]
Message-ID: <20231005174333.GD1342722@fedora> (raw)
In-Reply-To: <20231004125904.110781-4-hreitz@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]
On Wed, Oct 04, 2023 at 02:58:59PM +0200, Hanna Czenczek wrote:
> Currently, the vhost-user documentation says that rings are to be
> initialized in a disabled state when VHOST_USER_F_PROTOCOL_FEATURES is
> negotiated. However, by the time of feature negotiation, all rings have
> already been initialized, so it is not entirely clear what this means.
>
> At least the vhost-user-backend Rust crate's implementation interpreted
> it to mean that whenever this feature is negotiated, all rings are to
> put into a disabled state, which means that every SET_FEATURES call
> would disable all rings, effectively halting the device. This is
> problematic because the VHOST_F_LOG_ALL feature is also set or cleared
> this way, which happens during migration. Doing so should not halt the
> device.
>
> Other implementations have interpreted this to mean that the device is
> to be initialized with all rings disabled, and a subsequent SET_FEATURES
> call that does not set VHOST_USER_F_PROTOCOL_FEATURES will enable all of
> them. Here, SET_FEATURES will never disable any ring.
>
> This interpretation does not suffer the problem of unintentionally
> halting the device whenever features are set or cleared, so it seems
> better and more reasonable.
>
> We can clarify this in the documentation by making it explicit that the
> enabled/disabled state is tracked even while the vring is stopped.
> Every vring is initialized in a disabled state, and SET_FEATURES without
> VHOST_USER_F_PROTOCOL_FEATURES simply becomes one way to enable all
> vrings.
>
> Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
> ---
> docs/interop/vhost-user.rst | 32 +++++++++++++++++---------------
> 1 file changed, 17 insertions(+), 15 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-10-05 17:43 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-04 12:58 [Virtio-fs] [PATCH v4 0/8] vhost-user: Back-end state migration Hanna Czenczek
2023-10-04 12:58 ` Hanna Czenczek
2023-10-04 12:58 ` [Virtio-fs] [PATCH v4 1/8] vhost-user.rst: Deprecate [GS]ET_STATUS Hanna Czenczek
2023-10-04 12:58 ` Hanna Czenczek
2023-10-05 17:08 ` [Virtio-fs] " Stefan Hajnoczi
2023-10-05 17:08 ` Stefan Hajnoczi
2023-10-05 17:15 ` [Virtio-fs] (no subject) Michael S. Tsirkin
2023-10-05 17:15 ` Michael S. Tsirkin
2023-10-06 7:48 ` [Virtio-fs] (no subject) Hanna Czenczek
2023-10-06 8:45 ` Michael S. Tsirkin
2023-10-06 9:15 ` Hanna Czenczek
2023-10-06 9:26 ` Michael S. Tsirkin
2023-10-06 9:47 ` Hanna Czenczek
2023-10-06 10:34 ` Michael S. Tsirkin
2023-10-06 11:42 ` Hanna Czenczek
2023-10-06 15:17 ` Alex Bennée
2023-10-06 15:47 ` Hanna Czenczek
2023-10-06 20:49 ` Alex Bennée
2023-10-09 8:07 ` Hanna Czenczek
2023-10-07 2:22 ` Yajun Wu
2023-10-09 8:21 ` Hanna Czenczek
2023-10-09 9:07 ` Hanna Czenczek
2023-10-09 9:13 ` Hanna Czenczek
2023-10-10 4:00 ` Yajun Wu
2023-10-10 8:18 ` Hanna Czenczek
2023-10-10 10:36 ` Alex Bennée
2023-10-10 13:18 ` Hanna Czenczek
2023-10-10 14:35 ` Alex Bennée
2023-10-13 18:02 ` Hanna Czenczek
2023-10-17 7:49 ` Viresh Kumar
2023-10-17 8:13 ` Hanna Czenczek
2023-10-09 10:28 ` German Maglione
2023-10-10 2:56 ` Yajun Wu
2023-10-10 10:04 ` German Maglione
2023-10-04 12:58 ` [Virtio-fs] [PATCH v4 2/8] vhost-user.rst: Improve [GS]ET_VRING_BASE doc Hanna Czenczek
2023-10-04 12:58 ` Hanna Czenczek
2023-10-05 17:38 ` [Virtio-fs] " Stefan Hajnoczi
2023-10-05 17:38 ` Stefan Hajnoczi
2023-10-06 7:53 ` [Virtio-fs] " Hanna Czenczek
2023-10-06 8:49 ` Michael S. Tsirkin
2023-10-06 13:55 ` Hanna Czenczek
2023-10-06 13:58 ` Hanna Czenczek
2023-10-07 21:29 ` Michael S. Tsirkin
2023-10-07 21:27 ` Michael S. Tsirkin
2023-10-04 12:58 ` [Virtio-fs] [PATCH v4 3/8] vhost-user.rst: Clarify enabling/disabling vrings Hanna Czenczek
2023-10-04 12:58 ` Hanna Czenczek
2023-10-05 17:43 ` Stefan Hajnoczi [this message]
2023-10-05 17:43 ` Stefan Hajnoczi
2023-10-18 12:14 ` [Virtio-fs] " Michael S. Tsirkin
2023-10-18 12:14 ` Michael S. Tsirkin
2023-10-18 16:17 ` [Virtio-fs] " Hanna Czenczek
2023-10-18 16:17 ` Hanna Czenczek
2023-10-04 12:59 ` [Virtio-fs] [PATCH v4 4/8] vhost-user.rst: Introduce suspended state Hanna Czenczek
2023-10-04 12:59 ` Hanna Czenczek
2023-10-05 17:44 ` [Virtio-fs] " Stefan Hajnoczi
2023-10-05 17:44 ` Stefan Hajnoczi
2023-10-04 12:59 ` [Virtio-fs] [PATCH v4 5/8] vhost-user.rst: Migrating back-end-internal state Hanna Czenczek
2023-10-04 12:59 ` Hanna Czenczek
2023-10-05 17:46 ` [Virtio-fs] " Stefan Hajnoczi
2023-10-05 17:46 ` Stefan Hajnoczi
2023-10-04 12:59 ` [Virtio-fs] [PATCH v4 6/8] vhost-user: Interface for migration state transfer Hanna Czenczek
2023-10-04 12:59 ` Hanna Czenczek
2023-10-05 17:46 ` [Virtio-fs] " Stefan Hajnoczi
2023-10-05 17:46 ` Stefan Hajnoczi
2023-10-04 12:59 ` [Virtio-fs] [PATCH v4 7/8] vhost: Add high-level state save/load functions Hanna Czenczek
2023-10-04 12:59 ` Hanna Czenczek
2023-10-05 17:46 ` [Virtio-fs] " Stefan Hajnoczi
2023-10-05 17:46 ` Stefan Hajnoczi
2023-10-04 12:59 ` [Virtio-fs] [PATCH v4 8/8] vhost-user-fs: Implement internal migration Hanna Czenczek
2023-10-04 12:59 ` Hanna Czenczek
2023-10-05 17:46 ` [Virtio-fs] " Stefan Hajnoczi
2023-10-05 17:46 ` Stefan Hajnoczi
2023-10-05 17:48 ` [Virtio-fs] [PATCH v4 0/8] vhost-user: Back-end state migration Stefan Hajnoczi
2023-10-05 17:48 ` 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=20231005174333.GD1342722@fedora \
--to=stefanha@redhat.com \
--cc=antonkuchin@yandex-team.ru \
--cc=eperezma@redhat.com \
--cc=gmaglione@redhat.com \
--cc=hreitz@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=virtio-fs@redhat.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.