On 11-06-24, 07:41, Parav Pandit wrote:
> Got it.
> I agree to Michael's suggestion "I feel a non-normative section is enough for this."
> So following his guidance, we should remove it from the requirements and have this as,
>
> "implementation guide" or appendix section and it also looks good without the key wards too.
>
> Otherwise, this requirement section becomes the example of how not to write normative in a normative section.
> (and we want to avoid future such examples).
I am okay with whatever Cornelia and Michael finalize on this.
> > I wonder if it will cause some confusion, i.e. about the state of the virtqueues
> > on device reset. I understand what you are saying, but is it a given that
> > virtqueues will be reset once device is ?
> >
> Yes, it is given.
> See the spec snippet:
> " A device MUST NOT send notifications or interact with the queues after indicating completion of the reset
> by reinitializing device status to 0, until the driver re-initializes the device."
I read this a bit differently TBH. It only says that the device
shouldn't interact with vqs between reset and reinitialize states. It
doesn't really talk about virtqueues getting reset with the device.
> > I looked at: "Basic Facilities of a Virtio Device" -> "Device Reset", and it doesn't
> > talk about vitqueue being reset with the device.
> >
> It is covered.
I am okay to remove it, since you are sure about it :)
> > Also there is a separate section about, "Virtqueue Reset" and it talks about the
> > possibility of a virtqueue getting reset alone.
> >
> > Maybe something like ?
> >
> > The driver asks the device to reset itself (and its virtqueues) if, for example, the
> > driver times out waiting for a notification from the device for a previously
> > queued request.
>
> A requirement should be,
> a transport should provide a mechanism to reset an individual virtqueue.
> (it is not must).
Right, I can add another requirement for separate resetting of
virtqueues.
--
viresh
On Tue, Jun 11, 2024 at 05:40:45PM +0000, Parav Pandit wrote:
>
>
> > From: Cornelia Huck <cohuck(a)redhat.com>
> > Sent: Tuesday, June 11, 2024 8:59 PM
> >
> > On Tue, Jun 11 2024, Parav Pandit <parav(a)nvidia.com> wrote:
> >
> > > Hi Viresh,
> > >
> > >> From: Viresh Kumar <viresh.kumar(a)linaro.org>
> > >> Sent: Tuesday, June 11, 2024 11:06 AM
> > >
> > > [..]
> > >> diff --git a/content.tex b/content.tex index
> > >> 0a62dce5f65f..e2a836327818 100644
> > >> --- a/content.tex
> > >> +++ b/content.tex
> > >> @@ -631,8 +631,86 @@ \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 contains sections describing the transport-agnostic
> > >> +parts of virtio, and sections describing how individual transports
> > >> +implement virtio.
> > >> +
> > >> +\section{Virtio Transport Requirements}\label{sec:Virtio Transport
> > >> +Options / Virtio Transport Requirements}
> > >> +
> > >> +There are some mechanisms that any transport is required to
> > >> +implement, and some requirements that devices and drivers are
> > required to follow.
> > >> +
> > >> +\subsection{Transport Requirements}\label{sec:Virtio Transport
> > >> +Options / Virtio Transport Requirements / Transport Requirements}
> > >> +
> > >> +A transport provides a mechanism for the driver to discover the device.
> > >> +
> > > I would like to add a normative.
> > >
> > > A transport MAY provide a mechanism to create and destroy virtio devices.
> > >
> > > (for example PCI transport provides this).
> > >
> >
> > I'm not a fan of that statement: the transport already allows for the driver to
> > discover a device, whether that happens statically or dynamically really is the
> > choice of the transport, and I don't think we should go into that much detail.
> >
> Discovery != life cycle management of the device.
> The whole purpose of this section to clarify the transport requirements scope and guidelines for new transport.
> And if its incomplete I don't see a point of having this section at all.
I see it as complementing the section about adding new devices. So we
give some hints on how to add a new transport, basically a transport
developer is documenting his/her journey for others to follow. Yes this
does add support overhead, it will get out of sync so we better make
this clear straight away. Not enough transports are going to be added
to spend too many cycles making this complete, I think.
> Anyways, not too critical for me either.
>
> > [I'll go offline now, so please don't expect further responses from me right
> > now...]
On Tue, Jun 11 2024, Parav Pandit <parav(a)nvidia.com> wrote:
> Hi Viresh,
>
>> From: Viresh Kumar <viresh.kumar(a)linaro.org>
>> Sent: Tuesday, June 11, 2024 11:06 AM
>
> [..]
>> diff --git a/content.tex b/content.tex
>> index 0a62dce5f65f..e2a836327818 100644
>> --- a/content.tex
>> +++ b/content.tex
>> @@ -631,8 +631,86 @@ \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 contains sections describing the transport-agnostic parts
>> +of virtio, and sections describing how individual transports implement
>> +virtio.
>> +
>> +\section{Virtio Transport Requirements}\label{sec:Virtio Transport
>> +Options / Virtio Transport Requirements}
>> +
>> +There are some mechanisms that any transport is required to implement,
>> +and some requirements that devices and drivers are required to follow.
>> +
>> +\subsection{Transport Requirements}\label{sec:Virtio Transport Options
>> +/ Virtio Transport Requirements / Transport Requirements}
>> +
>> +A transport provides a mechanism for the driver to discover the device.
>> +
> I would like to add a normative.
>
> A transport MAY provide a mechanism to create and destroy virtio devices.
>
> (for example PCI transport provides this).
>
I'm not a fan of that statement: the transport already allows for the
driver to discover a device, whether that happens statically or
dynamically really is the choice of the transport, and I don't think we
should go into that much detail.
[I'll go offline now, so please don't expect further responses from me
right now...]
Hi Parav,
On 11-06-24, 06:10, Parav Pandit wrote:
> > From: Viresh Kumar <viresh.kumar(a)linaro.org>
> > +\subsection{Transport Requirements}\label{sec:Virtio Transport Options
> > +/ Virtio Transport Requirements / Transport Requirements}
> > +
> > +A transport provides a mechanism for the driver to discover the device.
> > +
> I would like to add a normative.
Some background on why normative statements are removed for this
change:
https://lore.kernel.org/all/20240521073925-mutt-send-email-mst@kernel.org/
> A transport MAY provide a mechanism to create and destroy virtio devices.
>
> (for example PCI transport provides this).
>
> It isn’t blocker for this patch.
> In case if you spin v6, please add, else will send this change after yours is merged.
> > +The device doesn't access or modify buffers on a virtqueue after it has
> > +notified the driver about their availability.
> > +
> This needs to be corrected to only say "modify".
>
> A device may still access (read) what is already wrote, for example, used index of the split queue.
> Or packed queue flags.
Hmm, we are talking about "buffers on a virtqueue" here. I am not sure
if the device should access them anymore. Once the control is passed
to the driver, the buffers may get modified anytime and device
shouldn't access them. Used index or flags are configuration things,
accessing them is fine I guess.
> > +The device resets itself and the virtqueues if requested by the driver,
> > +in a transport defined way, if the transport provides such a method.
> > +
> > +\subsection{Driver Requirements}\label{sec:Virtio Transport Options /
> > +Virtio Transport Requirements / Driver Requirements}
> > +
> > +The driver acknowledges device notifications, as mandated by the
> > +transport.
> > +
> > +The driver doesn't access virtqueue contents before the device notifies
> > +about the readiness of the same.
> > +
> This also needs fix.
> A driver may access (poll) for the packed queue flags or used index of the split q without device notifying it.
Maybe this (in a similar way to the device specific sentence earlier)
?
The driver doesn't access buffers on the virtqueue before the device
notifies about the readiness of the same.
Configuration specific fields can of course be accessed anytime.
> > +The driver accesses queued buffers after the device has processed them
> > +and notified the driver of their availability. This mechanism is
> > +transport defined.
> > +
> > +The driver asks the device to reset itself and the virtqueues if, for
> > +example, the driver times out waiting for a notification from the
> > +device for a previously queued request.
> > +
> Please remove "virtqueue" from above. The "device to reset itself" is enough.
> "and the virtqueues" is confusing, it sort of implies the vqs are something separate from the device reset flow, which is not true.
> So device reset is good enough.
I wonder if it will cause some confusion, i.e. about the state of the
virtqueues on device reset. I understand what you are saying, but is
it a given that virtqueues will be reset once device is ?
I looked at: "Basic Facilities of a Virtio Device" -> "Device Reset",
and it doesn't talk about vitqueue being reset with the device.
Also there is a separate section about, "Virtqueue Reset" and it talks
about the possibility of a virtqueue getting reset alone.
Maybe something like ?
The driver asks the device to reset itself (and its virtqueues) if,
for example, the driver times out waiting for a notification from the
device for a previously queued request.
Thanks.
--
viresh
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 <alex.bennee(a)linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
V4->V5:
- s/The transport/A transport/
- s/MUST provide/provides/
- Added some text for transport requirements.
V3->V4:
- Remove the normative sections and use direct speech.
- Change wording at few places.
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.
content.tex | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 80 insertions(+), 2 deletions(-)
diff --git a/content.tex b/content.tex
index 0a62dce5f65f..e2a836327818 100644
--- a/content.tex
+++ b/content.tex
@@ -631,8 +631,86 @@ \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 contains sections describing the transport-agnostic parts
+of virtio, and sections describing how individual transports implement
+virtio.
+
+\section{Virtio Transport Requirements}\label{sec:Virtio Transport Options / Virtio Transport Requirements}
+
+There are some mechanisms that any transport is required to implement,
+and some requirements that devices and drivers are required to follow.
+
+\subsection{Transport Requirements}\label{sec:Virtio Transport Options / Virtio Transport Requirements / Transport Requirements}
+
+A transport provides a mechanism for the driver to discover the device.
+
+A transport provides a mechanism for the driver to identify the device
+type.
+
+A transport provides a mechanism for communicating virtqueue
+configurations between the device and the driver.
+
+A transport allows multiple virtqueues per device. The number of
+virtqueues for a pair of device-driver are governed by the individual
+device protocol.
+
+A transport provides a mechanism that the device and the driver use to
+access memory for implementing virtqueues.
+
+A transport provides 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.
+
+A transport provides a mechanism for the driver to initiate a reset of
+the virtqueues and device.
+
+A transport provides a mechanism for the driver to read the device
+status. A transport provides a mechanism for the driver to change the
+device status.
+
+A transport provides a mechanism to implement configuration space
+between the device and the driver.
+
+\subsection{Device Requirements}\label{sec:Virtio Transport Options / Virtio Transport Requirements / Device Requirements}
+
+The device keeps any data associated with a device-initiated transaction
+accessible to the driver until the driver acknowledges the transaction
+to be complete.
+
+The device doesn't 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 doesn't access or modify buffers on a virtqueue after it has
+notified the driver about their availability.
+
+The device resets itself and the virtqueues if requested by the driver,
+in a transport defined way, if the transport provides such a method.
+
+\subsection{Driver Requirements}\label{sec:Virtio Transport Options / Virtio Transport Requirements / Driver Requirements}
+
+The driver acknowledges device notifications, as mandated by the
+transport.
+
+The driver doesn't access virtqueue contents before the device notifies
+about the readiness of the same.
+
+The driver accesses queued buffers after the device has processed them
+and notified the driver of their availability. This mechanism is
+transport defined.
+
+The driver asks the device to reset itself and 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
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 <alex.bennee(a)linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
V3->V4:
- Remove the normative sections and use direct speech.
- Change wording at few places.
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.
content.tex | 80 +++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/content.tex b/content.tex
index 0a62dce5f65f..23eea890d9b7 100644
--- a/content.tex
+++ b/content.tex
@@ -631,8 +631,84 @@ \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 contains sections describing the transport-agnostic parts
+of virtio, and sections describing how individual transports implement
+virtio.
+
+\section{Virtio Transport Requirements}\label{sec:Virtio Transport Options / Virtio Transport Requirements}
+
+\subsection{Transport Requirements}\label{sec:Virtio Transport Options / Virtio Transport Requirements / Transport Requirements}
+
+The transport provides a mechanism for the driver to discover the
+device.
+
+The transport provides a mechanism for the driver to identify the device
+type.
+
+The transport provides a mechanism for communicating virtqueue
+configurations between the device and the driver.
+
+The transport allows multiple virtqueues per device. The number of
+virtqueues for a pair of device-driver are governed by the individual
+device protocol.
+
+The transport provides a mechanism that the device and the driver use to
+access memory for implementing virtqueues.
+
+The transport provides 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 provides a mechanism for the driver to initiate a reset
+of the virtqueues and device.
+
+The transport provides 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 provides a mechanism to implement configuration space
+between the device and the driver.
+
+\subsection{Device Requirements}\label{sec:Virtio Transport Options / Virtio Transport Requirements / Device Requirements}
+
+The device keeps any data associated with a device-initiated transaction
+accessible to the driver until the driver acknowledges the transaction
+to be complete.
+
+The device doesn't 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 doesn't access or modify buffers on a virtqueue after it has
+notified the driver about their availability.
+
+The device resets itself and the virtqueues if requested by the driver, in a
+transport defined way, if the transport provides such a method.
+
+\subsection{Driver Requirements}\label{sec:Virtio Transport Options / Virtio Transport Requirements / Driver Requirements}
+
+The driver acknowledges device notifications, as mandated by the
+transport.
+
+The driver doesn't access virtqueue contents before the device notifies
+about the readiness of the same.
+
+The driver accesses queued buffers after the device has processed them
+and notified the driver of their availability. This mechanism is
+transport defined.
+
+The driver asks the device to reset itself and 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
On 29-05-24, 12:42, Stefano Garzarella wrote:
> mmm, I had interpreted this statement as if we could:
>
> The transport MAY provide a mechanism for the driver to initiate a
> reset of the virtqueues and device.
>
> IIUC device reset is always supported (see `\section{Device Reset}` in
> content.txt) and it's transport specific. While single virtqueue reset
> depends on VIRTIO_F_RING_RESET.
Done, thanks.
--
viresh
On 29-05-24, 13:12, Matias Ezequiel Vara Larsen wrote:
> > +The driver doesn't 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.
> > +
>
> I think last sentence could be rewritten as:
> - The driver accesses queued buffers after the device has processed them
> and notified the driver of their availability. This mechanism is
> transport defined.
>
>
> > +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.
> >
>
> I would rewrite last sentence as:
> - The driver asks 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.
>
>
> With that, LGTM!
Done. Thanks.
--
viresh
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 <alex.bennee(a)linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org>
---
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.
+
+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 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
+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
Dropped virtio-dev list.
On 20-05-24, 12:20, Stefano Garzarella wrote:
> I haven't followed v1 and v2, so apologies in advance if my comments have
> already been discussed.
No issues.
> On Mon, May 20, 2024 at 02:59:40PM GMT, Viresh Kumar wrote:
> > +\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.
Right. Is converting this to SHOULD okay or do you suggest some other
change ?
> > +The transport MUST provide a mechanism to implement config space
>
> "configuration space"
Sure.
> > 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?
Do we support that today ? Maybe we can if the maintainers agree.
--
viresh
