Re: [PATCH v2 1/4] Add virtio Admin Virtqueue

[Cornelia Huck <cohuck@redhat.com>]

On Fri, Jan 28 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Fri, Jan 28, 2022 at 01:14:14PM +0100, Cornelia Huck wrote:
>> On Mon, Jan 24 2022, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:
>> > +\section{Admin Virtqueues}\label{sec:Basic Facilities of a Virtio Device / Admin Virtqueues}
>> > +
>> > +Admin virtqueue is used to send administrative commands to manipulate
>> > +various features of the device and/or to manipulate various features,
>> > +if possible, of another device within the same group (e.g. PCI VFs of
>> > +a parent PCI PF device are grouped together. These devices can be
>> > +optionally managed by its parent PCI PF using its admin virtqueue.).
>> > +
>> > +Use of Admin virtqueue is negotiated by the VIRTIO_F_ADMIN_VQ
>> > +feature bit.
>> > +
>> > +Admin virtqueue index may vary among different device types.
>> 
>> So, my understanding is:
>> - any device type may or may not support the admin vq
>> - if the device type wants to be able to accommodate the admin vq, it
>>   also needs to specify where it shows up when the feature is negotiated
>> 
>> Do we expect that eventually all device types will need to support the
>> admin vq (if some use case comes along that will require all devices to
>> participate, for example?)
>
> I suspect yes. And that's one of the reasons why I'd rather we had a
> device independent way to locate the admin queue. There are less
> transports than device types.

So, do we want to bite the bullet now and simply say that every device
type has the admin vq as the last vq if the feature is negotiated?
Should be straightforward for the device types that have a fixed number
of vqs, and doable for those that have a variable amount (two device
types are covered by this series anyway.) I think we need to put it with
the device types, as otherwise the numbering of virtqueues could change
in unpredictable ways with the admin vq off/on.