[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]