From: "Michael S. Tsirkin" <mst@redhat.com>
To: virtio-comment@lists.oasis-open.org,
virtio-dev@lists.oasis-open.org, jasowang@redhat.com,
mst@redhat.com, cohuck@redhat.com, sgarzare@redhat.com,
stefanha@redhat.com, nrupal.jani@intel.com,
Piotr.Uminski@intel.com, hang.yuan@intel.com
Cc: virtio@lists.oasis-open.org,
Zhu Lingshan <lingshan.zhu@intel.com>,
pasic@linux.ibm.com, Shahaf Shuler <shahafs@nvidia.com>,
Parav Pandit <parav@nvidia.com>,
Max Gurtovoy <mgurtovoy@nvidia.com>
Subject: [PATCH v9 01/10] virtio: document forward compatibility guarantees
Date: Wed, 23 Nov 2022 16:08:00 -0500 [thread overview]
Message-ID: <20221123210706.21476-2-mst@redhat.com> (raw)
In-Reply-To: <20221123210706.21476-1-mst@redhat.com>
Feature negotiation forms the basis of forward compatibility
guarantees of virtio but has never been properly documented.
Do it now.
Suggested-by: Halil Pasic <pasic@linux.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
content.tex | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/content.tex b/content.tex
index 3051399..e3203be 100644
--- a/content.tex
+++ b/content.tex
@@ -114,21 +114,63 @@ \section{Feature Bits}\label{sec:Basic Facilities of a Virtio Device / Feature B
In particular, new fields in the device configuration space are
indicated by offering a new feature bit.
+To keep te feature negotiation mechanism extensible, it is important
+that devices \em{do not} offer any feature bits that they would not be
+able to handle if the driver accepted them (even though drivers are not
+supposed to accept them in the first place even if offered, according to
+this version of the specification.) Likewise, it is important that
+drivers \em{do not} accept feature bits they do not know how to handle
+(even though devices are not supposed to offer them in the first place,
+according to this version of the specification.) The preferred way for
+handling reserved and unexpected features is that the driver ignores
+them.
+
+In particular, this is
+especially important for features limited to specific transports,
+as enabling these for more transports in future versions of the
+specification is highly likely to require changing the behaviour
+from drivers and devices. Drivers and devices supporting
+multiple transports need to carefully maintain per-transport
+lists of allowed features.
+
\drivernormative{\subsection}{Feature Bits}{Basic Facilities of a Virtio Device / Feature Bits}
The driver MUST NOT accept a feature which the device did not offer,
and MUST NOT accept a feature which requires another feature which was
not accepted.
+The driver MUST validate the feature bits offered by the device.
+The driver MUST ignore and MUST NOT accept any feature bit that is
+\begin{itemize}
+\item not described in this specification,
+\item marked as reserved,
+\item not supported for the specific transport,
+\item not defined for the device type.
+\end{itemize}
+
The driver SHOULD go into backwards compatibility mode
if the device does not offer a feature it understands, otherwise MUST
set the FAILED \field{device status} bit and cease initialization.
+By contrast, the driver MUST NOT fail solely because a feature
+it does not understand has been offered by the device.
+
\devicenormative{\subsection}{Feature Bits}{Basic Facilities of a Virtio Device / Feature Bits}
The device MUST NOT offer a feature which requires another feature
which was not offered. The device SHOULD accept any valid subset
of features the driver accepts, otherwise it MUST fail to set the
FEATURES_OK \field{device status} bit when the driver writes it.
+The device MUST NOT offer feature bits corresponding to features
+it would not support if accepted by the driver (even if the
+driver is prohibited from accepting the feature bits by the
+specification); for the sake of clarity, this refers to feature
+bits not described in this specification, reserved feature bits
+and feature bits reserved or not supported for the specific
+transport or the specific device type, but this does not preclude
+devices written to a future version of this specification from
+offering such feature bits should such a specification have a
+provision for devices to support the corresponding features.
+
If a device has successfully negotiated a set of features
at least once (by accepting the FEATURES_OK \field{device
status} bit during device initialization), then it SHOULD
--
MST
next prev parent reply other threads:[~2022-11-23 21:08 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 21:07 [PATCH v9 00/10] Introduce device group and device management Michael S. Tsirkin
2022-11-23 21:08 ` Michael S. Tsirkin [this message]
2022-11-24 4:33 ` [PATCH v9 01/10] virtio: document forward compatibility guarantees Jason Wang
2022-11-24 6:59 ` Michael S. Tsirkin
2022-11-24 7:34 ` Jason Wang
2022-11-24 8:15 ` Michael S. Tsirkin
2022-11-24 12:05 ` [virtio-dev] " Cornelia Huck
2022-11-25 3:17 ` Jason Wang
2022-11-25 10:37 ` [virtio-dev] " Cornelia Huck
2022-11-28 6:14 ` Jason Wang
2022-11-23 21:08 ` [PATCH v9 02/10] admin: introduce device group and related concepts Michael S. Tsirkin
2022-11-24 5:41 ` Jason Wang
2022-11-24 7:08 ` Michael S. Tsirkin
2022-11-24 7:37 ` [virtio-dev] " Jason Wang
2022-11-24 8:18 ` Michael S. Tsirkin
2022-11-24 12:12 ` Cornelia Huck
2022-11-25 3:23 ` Jason Wang
2022-11-25 10:58 ` [virtio] " Cornelia Huck
2022-11-25 12:08 ` Michael S. Tsirkin
2022-11-23 21:08 ` [PATCH v9 03/10] admin: introduce group administration commands Michael S. Tsirkin
2022-11-24 5:52 ` [virtio-dev] " Jason Wang
2022-11-24 7:12 ` Michael S. Tsirkin
2022-11-24 7:42 ` Jason Wang
2022-11-24 8:03 ` Michael S. Tsirkin
2022-11-25 3:24 ` [virtio-comment] " Jason Wang
2022-11-24 12:21 ` [virtio-dev] " Cornelia Huck
2022-11-25 3:54 ` Jason Wang
2022-11-28 13:14 ` [virtio-comment] " Zhu Lingshan
2022-11-23 21:08 ` [PATCH v9 04/10] admin: introduce virtio admin virtqueues Michael S. Tsirkin
2022-11-28 13:12 ` [virtio-comment] " Zhu Lingshan
2022-11-23 21:08 ` [PATCH v9 05/10] pci: add admin vq registers to virtio over pci Michael S. Tsirkin
2022-11-24 6:00 ` Jason Wang
2022-11-24 7:14 ` Michael S. Tsirkin
2022-11-24 7:46 ` Jason Wang
2022-11-24 8:09 ` Michael S. Tsirkin
2022-11-25 3:27 ` Jason Wang
2022-11-23 21:08 ` [PATCH v9 06/10] mmio: document ADMIN_VQ as reserved Michael S. Tsirkin
2022-11-24 6:03 ` Jason Wang
2022-11-24 7:45 ` Michael S. Tsirkin
2022-11-23 21:08 ` [PATCH v9 07/10] ccw: " Michael S. Tsirkin
2022-11-23 21:08 ` [PATCH v9 08/10] admin: command list discovery Michael S. Tsirkin
2022-11-24 6:40 ` Jason Wang
2022-11-24 8:30 ` Michael S. Tsirkin
2022-11-25 3:38 ` [virtio-comment] " Jason Wang
2022-11-25 11:43 ` Michael S. Tsirkin
2022-11-28 4:34 ` Jason Wang
2022-11-28 7:42 ` Michael S. Tsirkin
2022-11-23 21:08 ` [PATCH v9 09/10] admin: conformance clauses Michael S. Tsirkin
2022-11-24 6:51 ` Jason Wang
2022-11-24 8:36 ` Michael S. Tsirkin
2022-11-25 3:50 ` Jason Wang
2022-11-25 11:42 ` [virtio] " Cornelia Huck
2022-11-25 11:56 ` Michael S. Tsirkin
2022-11-25 12:10 ` [virtio] " Cornelia Huck
2022-11-25 11:47 ` Michael S. Tsirkin
2022-11-28 4:32 ` Jason Wang
2022-11-28 7:39 ` Michael S. Tsirkin
2022-11-24 12:28 ` [virtio] " Cornelia Huck
2022-11-25 3:38 ` Jason Wang
2022-11-23 21:08 ` [PATCH RFC v9 10/10] ccw: document more reserved features Michael S. Tsirkin
2022-11-24 6:53 ` Jason Wang
2022-11-24 8:31 ` Michael S. Tsirkin
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=20221123210706.21476-2-mst@redhat.com \
--to=mst@redhat.com \
--cc=Piotr.Uminski@intel.com \
--cc=cohuck@redhat.com \
--cc=hang.yuan@intel.com \
--cc=jasowang@redhat.com \
--cc=lingshan.zhu@intel.com \
--cc=mgurtovoy@nvidia.com \
--cc=nrupal.jani@intel.com \
--cc=parav@nvidia.com \
--cc=pasic@linux.ibm.com \
--cc=sgarzare@redhat.com \
--cc=shahafs@nvidia.com \
--cc=stefanha@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtio@lists.oasis-open.org \
/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.