在 2022/1/26 下午9:29, Parav Pandit 写道:
From: Michael S. Tsirkin <m...@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?
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
