Re: [PATCH 2/5] Introduce VIRTIO_F_ADMIN_VQ_INDIRECT_DESC/VIRTIO_F_ADMIN_VQ_IN_ORDER

[Jason Wang <jasowang@redhat.com>]

å 2022/1/26 äå9:29, Parav Pandit åé:
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, January 25, 2022 5:39 PM
> > > So you do agree that managing a managed (create/destroy/setup/etc...)
> > > will be done using the AQ of the managing device ?
> > I think Jason asked that the management commands are split from the queue
> > itself, such that they can be implemented in more ways down the road.
> Admin commands involved DMA. And also multiple commands can be enqueued to the device.
> I don't see any other construct in the spec other than vq that enables driver and device to achieve both.
> Hence split the queue from command is very weird for spec to do.


I'd say it really depends on the transport. Not all transport uses 
registers. There could be transport that:

1) use DMA (e.g CCW)

2) use transport specific queue

3) doesn't need DMA at all (e.g using shared memory like virtio-rproc)

Having another VQ seems redundant.

Thanks


> A recent addition like virtio_fs_req didnât adopt this suggestion.
>
> If we just want to split so that admin commands can be transported via non admin queue, we should remove below line from spec:
>
> "The Admin command set defines the commands that may be issued only to the admin virtqueue"
>
> And reword it as below,
>
> The Admin command set defines the commands to manipulate various features/attributes of another device within the same group...
> When VIRTIO_F_ADMIN_VQ feature is negotiated, admin commands must be transported through the admin queue.
>
> Looks ok?