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

[Max Gurtovoy <mgurtovoy@nvidia.com>]

On 1/29/2022 5:53 AM, Jason Wang wrote:
> On Fri, Jan 28, 2022 at 11:52 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>> On Fri, Jan 28, 2022 at 04:49:34PM +0100, Cornelia Huck wrote:
>>> 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.
>> Well that only works once. The next thing we'll need we won't be able to
>> make the last one ;) So I am inclined to add a per-transport field that
>> gives the admin queue number.
> Technically, there's no need to use the same namespace for admin
> virtqueue if it has a dedicated notification area. If we go this way,
> we can simply use 0 as queue index for admin virtqueue.

Or we can use index 0xFFFF for admin virtqueue for compatibility.


> Thanks
>
>> Another advantage to this approach is that
>> we can make sure admin queue gets a page by itself (which can be good if
>> we want to allow access to regular vqs but not to the admin queue to
>> guest) even if regular vqs share a page. Will help devices use less
>> memory space.
>>
>> --
>> MST
>>