OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


On Wed, Jan 26, 2022 at 01:29:27PM +0000, Parav Pandit wrote:
> 
> > 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.

 VIRTIO_PCI_CAP_SHARED_MEMORY_CFG can do this.


> 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"

sure

> 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?

I see no problem with that.

-- 
MST



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]