RE: [virtio-comment] RE: [PATCH v5 2/7] Introduce admin command set

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Wednesday, June 22, 2022 10:42 PM

[..]
> > Are you suggesting only feature bits through register-based transport or all
> commands via register-based transport?
> 
> For feature bits, if we don't have admin virtqueue as transport, 
Right.
Management tasks (features) done via AQ are negotiated via the AQ (regardless of device type being management dev or managed dev).
It is not replacing usual feature bits negotiation that has strong relationships with device initialization sequence.

> I suggest it
> be negotiated with existing transport: we don't need any extension of the
> existing transport facility to make it work. If we have admin virtqueue as a
> transport, we must allow the features of the managed device to be
> negotiated through the admin virtqueue.
>
Regarding above _managed_device_:

In current version the AQ is on the management device (not managed device).
But AQ as stated is generic to be present on any device that wants to implement AQ.

> For other commands, we probably need to analyze it case by case. But if the
> command is for management only, it should be done via admin virtqueue.
> (Note that for the MSIX allocation, I do see some vendors allocating it via
> registers). 
Where do you see it? In the spec draft?

> If the command is used for basic facilities like the virtqueue reset,
> it should be allowed to be implemented by any transport (admin virtqueue
> as well as others like PCI registers).