[PATCH v11 00/10] Introduce device group and device management

From
Michael S. Tsirkin <>
Date
2023-04-10T13:23:00+00:00
ID
Thread
[PATCH v11 00/10] Introduce device group and device management
On Thu, Apr 06, 2023 at 12:08:03AM -0400, Parav Pandit wrote:
>
>
> 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 <>
> >
> > ---
>
> 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

Not sure why - these are synonims - and this variant is more popular:

[mst@tuck virtio]$ git grep 'The driver queues'
admin.tex:The driver queues requests to an arbitrary administration
content.tex:The driver queues requests to the virtqueues, and they are used by
content.tex:The driver queues requests to an arbitrary request queue, and
virtio-gpio.tex:\item The driver queues \field{struct virtio_gpio_request} and
virtio-i2c.tex:The driver queues requests to the virtqueue, and they are used by the
virtio-vsock.tex:The driver queues outgoing packets on the tx virtqueue and incoming packet
[mst@tuck virtio]$ git grep 'The driver enqueues'
virtio-fs.tex:The driver enqueues normal requests on an arbitrary request queue. High