From: Hanna Czenczek <hreitz@redhat.com>
To: qemu-devel@nongnu.org, virtio-fs@redhat.com
Cc: "Hanna Czenczek" <hreitz@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"German Maglione" <gmaglione@redhat.com>,
"Eugenio Pérez" <eperezma@redhat.com>,
"Anton Kuchin" <antonkuchin@yandex-team.ru>
Subject: [Virtio-fs] [PATCH v4 1/8] vhost-user.rst: Deprecate [GS]ET_STATUS
Date: Wed, 4 Oct 2023 14:58:57 +0200 [thread overview]
Message-ID: <20231004125904.110781-2-hreitz@redhat.com> (raw)
In-Reply-To: <20231004125904.110781-1-hreitz@redhat.com>
There is no clearly defined purpose for the virtio status byte in
vhost-user: For resetting, we already have RESET_DEVICE; and for virtio
feature negotiation, we have [GS]ET_FEATURES. With the REPLY_ACK
protocol extension, it is possible for SET_FEATURES to return errors
(SET_PROTOCOL_FEATURES may be called before SET_FEATURES).
As for implementations, SET_STATUS is not widely implemented. dpdk does
implement it, but only uses it to signal feature negotiation failure.
While it does log reset requests (SET_STATUS 0) as such, it effectively
ignores them, in contrast to RESET_OWNER (which is deprecated, and today
means the same thing as RESET_DEVICE).
While qemu superficially has support for [GS]ET_STATUS, it does not
forward the guest-set status byte, but instead just makes it up
internally, and actually completely ignores what the back-end returns,
only using it as the template for a subsequent SET_STATUS to add single
bits to it. Notably, after setting FEATURES_OK, it never reads it back
to see whether the flag is still set, which is the only way in which
dpdk uses the status byte.
As-is, no front-end or back-end can rely on the other side handling this
field in a useful manner, and it also provides no practical use over
other mechanisms the vhost-user protocol has, which are more clearly
defined. Deprecate it.
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
---
docs/interop/vhost-user.rst | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index 5a070adbc1..2f68e67a1a 100644
--- a/docs/interop/vhost-user.rst
+++ b/docs/interop/vhost-user.rst
@@ -1424,21 +1424,35 @@ Front-end message types
:request payload: ``u64``
:reply payload: N/A
- When the ``VHOST_USER_PROTOCOL_F_STATUS`` protocol feature has been
- successfully negotiated, this message is submitted by the front-end to
- notify the back-end with updated device status as defined in the Virtio
+.. admonition:: Deprecated
+
+ This is no longer used. Used to be sent by the front-end to notify the
+ back-end with updated device status as defined in the Virtio
specification.
+ However, its purpose in vhost-user was never well-defined; for
+ example, how or if it would replace VHOST_USER_RESET_DEVICE, or how it
+ integrates with the feature negotiation phase. Therefore,
+ implementations in practice were less than strict in how the status
+ value was handled, which means there was actually no protocol between
+ front-end and back-end on the use of the status value.
+
+ For resetting, use VHOST_USER_RESET_DEVICE instead. For feature
+ negotiation with acknowledgment from the device, use
+ VHOST_USER_SET_FEATURES with the :ref:`REPLY_ACK <reply_ack>` feature
+ instead.
+
``VHOST_USER_GET_STATUS``
:id: 40
:equivalent ioctl: VHOST_VDPA_GET_STATUS
:request payload: N/A
:reply payload: ``u64``
- When the ``VHOST_USER_PROTOCOL_F_STATUS`` protocol feature has been
- successfully negotiated, this message is submitted by the front-end to
- query the back-end for its device status as defined in the Virtio
- specification.
+.. admonition:: Deprecated
+
+ This is no longer used. Used to be sent by the front-end to query the
+ back-end for its device status as defined in the Virtio specification.
+ Deprecated together with VHOST_USER_SET_STATUS.
Back-end message types
--
2.41.0
next prev parent reply other threads:[~2023-10-04 12:58 UTC|newest]
Thread overview: 53+ 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 [this message]
2023-10-05 17:08 ` [Virtio-fs] [PATCH v4 1/8] vhost-user.rst: Deprecate [GS]ET_STATUS Stefan Hajnoczi
2023-10-05 17:15 ` [Virtio-fs] (no subject) Michael S. Tsirkin
2023-10-06 7:48 ` 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-05 17:38 ` Stefan Hajnoczi
2023-10-06 7:53 ` 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-05 17:43 ` Stefan Hajnoczi
2023-10-18 12:14 ` Michael S. Tsirkin
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-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-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-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-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-05 17:46 ` Stefan Hajnoczi
2023-10-05 17:48 ` [Virtio-fs] [PATCH v4 0/8] vhost-user: Back-end state migration 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=20231004125904.110781-2-hreitz@redhat.com \
--to=hreitz@redhat.com \
--cc=antonkuchin@yandex-team.ru \
--cc=eperezma@redhat.com \
--cc=gmaglione@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).