Re: [PATCH V3 Resend] virtio-transport: Clarify requirements

Stefano Garzarella <[email protected]> Mon, 20 May 2024 12:20:13 +0200
Newsgroups dev.linux.lists.virtio-dev,dev.linux.lists.virtio-comment
Message-ID <a752usapxpmlwpm5ywvccrrkmumi5aosbzvsxjghsotn4kmgyq@hlmjdhedeqbz>
Hi Viresh,
I haven't followed v1 and v2, so apologies in advance if my comments 
have already been discussed.

On Mon, May 20, 2024 at 02:59:40PM GMT, Viresh Kumar wrote:
>The virtio documentation currently doesn't define any generic
>requirements that are applicable to all transports. They can be useful
>while adding support for a new transport.
>
>This commit tries to define the same.
>
>Reviewed-by: Alex Bennée <[email protected]>
>Signed-off-by: Viresh Kumar <[email protected]>
>---
>V2->V3:
>- Minor fixes.
>- Added Reviewed by from Alex.
>
>V1->V2:
>- Lot of changes after discussions with Alex and Cornelia.
>- Almost a rewrite of the first commit.
>- Add Transport normative sections.
>
> commands.tex    |  3 +-
> conformance.tex | 14 +++++++++
> content.tex     | 78 +++++++++++++++++++++++++++++++++++++++++++++++--
> 3 files changed, 92 insertions(+), 3 deletions(-)
>
>diff --git a/commands.tex b/commands.tex
>index 25ea8ee3bc78..b64b14424bd2 100644
>--- a/commands.tex
>+++ b/commands.tex
>@@ -7,7 +7,8 @@
> % How we format a field name
> \newcommand{\field}[1]{\emph{#1}}
>
>-% Mark a normative section (driver or device)
>+% Mark a normative section (driver or device, or transport)
>+\newcommand{\transportnormative}[3]{#1{Transport Requirements: #2}\label{transportnormative:#3}}
> \newcommand{\drivernormative}[3]{#1{Driver Requirements: #2}\label{drivernormative:#3}}
> \newcommand{\devicenormative}[3]{#1{Device Requirements: #2}\label{devicenormative:#3}}
> \newcounter{clausecounter}
>diff --git a/conformance.tex b/conformance.tex
>index dc00e84e75ae..4a873169ce63 100644
>--- a/conformance.tex
>+++ b/conformance.tex
>@@ -11,6 +11,10 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>
> Conformance targets:
> \begin{description}
>+\item[Transport] A transport MUST conform to one conformance clauses:
>+  \begin{itemize}
>+    \item Clause \ref{sec:Conformance / Transport Conformance}.
>+  \end{itemize}
> \item[Driver] A driver MUST conform to four conformance clauses:
>   \begin{itemize}
>     \item Clause \ref{sec:Conformance / Driver Conformance}.
>@@ -66,6 +70,14 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
>   \end{itemize}
> \end{description}
>
>+\conformance{\section}{Transport Conformance}\label{sec:Conformance / Transport Conformance}
>+
>+A transport MUST conform to the following normative statements:
>+
>+\begin{itemize}
>+\item \ref{transportnormative:Virtio Transport Options / Virtio Transport Requirements}
>+\end{itemize}
>+
> \conformance{\section}{Driver Conformance}\label{sec:Conformance / 
> Driver Conformance}
>
> A driver MUST conform to the following normative statements:
>@@ -93,6 +105,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{drivernormative:Basic Facilities of a Virtio Device / Packed Virtqueues / Supplying Buffers to The Device / Sending Available Buffer Notifications}
> \item \ref{drivernormative:General Initialization And Device Operation / Device Initialization}
> \item \ref{drivernormative:General Initialization And Device Operation / Device Cleanup}
>+\item \ref{drivernormative:Virtio Transport Options / Virtio Transport Requirements}
> \item \ref{drivernormative:Reserved Feature Bits}
> \end{itemize}
>
>@@ -172,6 +185,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \item \ref{devicenormative:Basic Facilities of a Virtio Device / Packed Virtqueues / The Virtqueue Descriptor Table}
> \item \ref{devicenormative:Basic Facilities of a Virtio Device / Packed Virtqueues / Scatter-Gather Support}
> \item \ref{devicenormative:Basic Facilities of a Virtio Device / Shared Memory Regions}
>+\item \ref{devicenormative:Virtio Transport Options / Virtio Transport Requirements}
> \item \ref{devicenormative:Reserved Feature Bits}
> \end{itemize}
>
>diff --git a/content.tex b/content.tex
>index 0a62dce5f65f..a79993b5ed69 100644
>--- a/content.tex
>+++ b/content.tex
>@@ -631,8 +631,82 @@ \section{Device Cleanup}\label{sec:General Initialization And Device Operation /
>
> \chapter{Virtio Transport Options}\label{sec:Virtio Transport Options}
>
>-Virtio can use various different buses, thus the standard is split
>-into virtio general and bus-specific sections.
>+Devices and drivers can use different transport methods to enable
>+interaction, for example PCI, MMIO, or Channel I/O. The transport
>+methods define various aspects of the communication between the device
>+and the driver, like device discovery, exchanging capabilities,
>+interrupt handling, data transfer, etc. For example, in a host/guest
>+architecture, the host might expose a device to the guest on a PCI bus,
>+and the guest will use a PCI-specific driver to interact with it.
>+
>+The standard is split into sections describing general virtio
>+implementation and transport-specific sections.
>+
>+\section{Virtio Transport Requirements}\label{sec:Virtio Transport Options / Virtio Transport Requirements}
>+
>+\transportnormative{\subsection}{Virtio Transport Requirements}{Virtio Transport Options / Virtio Transport Requirements}
>+The transport MUST provide a mechanism for the driver to discover the
>+device.

This seems a little too stringent. For example, does MMIO offer a 
discovery mechanism? IIRC we have to pass the address via device tree or 
kernel command line.

>+
>+The transport MUST provide a mechanism for the driver to identify the
>+device type.
>+
>+The transport MUST provide a mechanism for communicating virtqueue
>+configurations between the device and the driver.
>+
>+The transport MUST allow multiple virtqueues per device. The number of
>+virtqueues for a pair of device-driver are governed by the individual
>+device protocol.
>+
>+The transport MUST provide a mechanism that the device and the driver
>+use to access memory for implementing virtqueues.
>+
>+The transport MUST provide a mechanism for the device to notify the
>+driver and a mechanism for the driver to notify the device, for example
>+regarding availability of a buffer on the virtqueue.
>+
>+The transport MAY provide a mechanism for the driver to initiate a
>+reset of the virtqueues and device.
>+
>+The transport SHOULD provide a mechanism for the driver to read the
>+device status. The transport MUST provide a mechanism for the driver to
>+change the device status.
>+
>+The transport MUST provide a mechanism to implement config space 

"configuration space"

>between
>+the device and the driver.
>+
>+\devicenormative{\subsection}{Virtio Transport Requirements}{Virtio Transport Options / Virtio Transport Requirements}
>+
>+The device MUST keep any data associated with a device-initiated
>+transaction accessible to the driver until the driver acknowledges the
>+transaction to be complete.
>+
>+The device MUST NOT access the contents of a virtqueue before the
>+driver notifies, in a transport defined way, the device that the
>+virtqueue is ready to be accessed.
>+
>+The device MUST NOT access or modify buffers on a virtqueue after it has
>+notified the driver about their availability.
>+
>+The device MUST reset the virtqueues if requested by the driver, in a

Should we also talk about the possibility of resetting the entire 
device?

Thanks,
Stefano

>+transport defined way, if the transport provides such a method.
>+
>+\drivernormative{\subsection}{Virtio Transport Requirements}{Virtio Transport Options / Virtio Transport Requirements}
>+
>+The driver MUST acknowledge device notifications, as mandated by the
>+transport.
>+
>+The driver MUST NOT access virtqueue contents before the device notifies
>+about the readiness of the same.
>+
>+The driver MUST NOT access buffers, after it has added them to the
>+virtqueue and notified the device about their availability. The driver
>+MAY access them after the device has processed them and notified the
>+driver of their availability, in a transport defined way.
>+
>+The driver MAY ask the device to reset the virtqueues if, for example,
>+the driver times out waiting for a notification from the device for a
>+previously queued request.
>
> \input{transport-pci.tex}
> \input{transport-mmio.tex}
>-- 
>2.31.1.272.g89b43f80a514
>
>