virtio — archive

[Parav Pandit <parav@nvidia.com>]

On 4/3/2023 11:03 AM, Michael S. Tsirkin wrote: > The admin virtqueues will be the first interface used to issue admin commands. > The admin virtqueue > Currently the virtio specification defines control virtqueue to manipulate > features and configuration of the device it operates on: > virtio-net, virtio-scsi, etc all have existing control virtqueues. However, > control virtqueue commands are device type specific, which makes it very > difficult to extend for device agnostic commands. > > Keeping the device-specific virtqueue separate from the admin virtqueue > is simpler and has fewer potential problems. > I don't think creating > common infrastructure for device-specific control virtqueues across > device types worthwhile or within the scope of this patch series. > > To support this requirement in a more generic way, this patch introduces > a new admin virtqueue interface. > The admin virtqueue can be seen as the virtqueue analog to a transport. > The admin queue thus does nothing device type-specific (net, scsi, etc) > and instead focuses on transporting the admin commands. > > We also support more than one admin virtqueue, for QoS and > scalability requirements. > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > > --- > explain ordering of commands as suggested by Stefan > dropped Max's S.O.B > reword commit log as suggested by David > minor wording fixes suggested by David > --- > admin.tex | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++ > content.tex | 7 +++-- > 2 files changed, 80 insertions(+), 2 deletions(-) > > diff --git a/admin.tex b/admin.tex > index c869a1a..f201bcd 100644 > --- a/admin.tex > +++ b/admin.tex > @@ -182,3 +182,78 @@ \subsection{Group administration commands}\label{sec:Basic Facilities of a Virti > \field{command_specific_data} and \field{command_specific_result} > depends on these structures and is described separately or is > implicit in the structure description. > + > +\section{Administration Virtqueues}\label{sec:Basic Facilities of a Virtio Device / Administration Virtqueues} > + > +An administration virtqueue of an owner device is used to submit > +group administration commands. An owner device can have more > +than one administration virtqueue. > + > +If VIRTIO_F_ADMIN_VQ has been negotiated, an owner device exposes one > +or more adminstration virtqueues. The number and locations of the > +administration virtqueues are exposed by the owner device in a transport > +specific manner. > + > +The driver queues requests to an arbitrary administration The driver enqueues > +virtqueue, and they are used by the device on that same > +virtqueue. It is the responsibility of the driver to ensure > +strict request ordering for commands, because they will be > +consumed with no order constraints. For example, if consistency > +is required then the driver can wait for the processing of a > +first command by the device to be completed before submitting > +another command depending on the first one. > + > +Administration virtqueues are used as follows: > +\begin{itemize} > +\item The driver submits the command using the \field{struct virtio_admin_cmd} > +structure using a buffer consisting of two parts: a device-readable one followed by a > +device-writable one. > +\item the device-readable part includes fields from \field{opcode} > +through \field{command_specific_data}. > +\item the device-writeable buffer includes fields from \field{status} > +through \field{command_specific_result} inclusive. > +\end{itemize} > + > +For each command, this specification describes a distinct > +format structure used for \field{command_specific_data} and > +\field{command_specific_result}, the length of these fields > +depends on the command. > + > +However, to ensure forward compatibility > +\begin{itemize} > +\item drivers are allowed to submit buffers that are longer > +than the device expects > +(that is, longer than the length of > +\field{opcode} through \field{command_specific_data}). > +This allows the driver to maintain > +a single format structure even if some structure fields are > +unused by the device. > +\item drivers are allowed to submit buffers that are shorter > +than what the device expects > +(that is, shorter than the length of \field{status} through > +\field{command_specific_result}). This allows the device to maintain > +a single format structure even if some structure fields are > +unused by the driver. > +\end{itemize} > + > +The device compares the length of each part (device-readable and > +device-writeable) of the buffer as submitted by driver to what it > +expects and then silently truncates the structures to either the > +length submitted by the driver, or the length described in this > +specification, whichever is shorter. The device silently ignores > +any data falling outside the shorter of the two lengths. Any > +missing fields are interpreted as set to zero. > + > +Similarly, the driver compares the used buffer length > +of the buffer to what it expects and then silently > +truncates the structure to the used buffer length. > +The driver silently ignores any data falling outside > +the used buffer length reported by the device. Any missing > +fields are interpreted as set to zero. > + > +This simplifies driver and device implementations since the > +driver/device can simply maintain a single large structure (such > +as a C structure) for a command and its result. As new versions > +of the specification are designed, new fields can be added to the > +tail of a structure, with the driver/device using the full > +structure without concern for versioning. > diff --git a/content.tex b/content.tex > index 04592fb..2eb15fa 100644 > --- a/content.tex > +++ b/content.tex > @@ -99,10 +99,10 @@ \section{Feature Bits}\label{sec:Basic Facilities of a Virtio Device / Feature B > \begin{description} > \item[0 to 23, and 50 to 127] Feature bits for the specific device type > > -\item[24 to 40] Feature bits reserved for extensions to the queue and > +\item[24 to 41] Feature bits reserved for extensions to the queue and > feature negotiation mechanisms > > -\item[41 to 49, and 128 and above] Feature bits reserved for future extensions. > +\item[42 to 49, and 128 and above] Feature bits reserved for future extensions. > \end{description} > > \begin{note} > @@ -7684,6 +7684,9 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits} > that the driver can reset a queue individually. > See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Reset}. > > + \item[VIRTIO_F_ADMIN_VQ(41)] This feature indicates that the device exposes one or more > + administration virtqueues. > + > \end{description} > > \drivernormative{\section}{Reserved Feature Bits}{Reserved Feature Bits} Reviewed-by: Parav Pandit <parav@nvidia.com>