Re: [virtio-comment] Re: [PATCH] Introduce virtio virtual device and transport vq

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

On 7/13/2022 2:04 PM, Jason Wang wrote:
> å 2022/7/12 18:39, Zhu, Lingshan wrote:
> > > > struct mgmt_dev_avail_res{}, if min_vdev_vqs == max_vdev_vqs, means 
> > > > the management device
> > > > only supports creating virtual devices with fixed capabilities, 
> > > > this kind of virtual devices
> > > > can be pre-created. Like the slab allocator, vendors can pre-create 
> > > > the device. Then when the management
> > > > device receiving the VDEV_CREATE command, it can just pick up a 
> > > > free virtual device, and return the
> > > > virtual device.
> > > So the question still remains, how could we discover those pre-created
> > > devices? (having something like initial_vfs?)
> > I think for the management devices, pre-creation could be pre-allocated
> > hw resource. The management device could pre-allocate a certain 
> > number of
> > "standard" managed devices, when receive a create command, the 
> > management
> > device can pick a free managed device, assign an UUID to it, then return
> > to the management driver. So the driver may not be aware of this 
> > pre-creation,
> > it just sees the device is created rapidly. Just like the slab 
> > system, or a threads pool.
>
>
> So for "pre-creating" I meant from the driver perspective. What you 
> describe here is invisible to driver. So we don't need a dedicate 
> feature in this case.
Yes, we should not describe "pre-create" here, I only talk about the 
managed devices with fixed num_queues. This is some kind of "pre-create" 
in the hw,
pooling the source, not visible to the driver.
> Btw, I think we need a command to support virtqueue reset in the next 
> version.
Do you mean reset vq and re-enable vq of virtio 1.2?
I think we don't need to reset the MSI entry for the queue upon a reset, 
right?
Because MSI entries are not queue configs and not meaningful to reset it.
But we need to drop all pending MSI, right?

Thanks,
Zhu Lingshan
> Thanks
>
>
> > > > The bit only makes sense for the case when some managed(virtual)
> > > > devices are pre-created like initial_vfs in SR-IOV. If we allow
> > > > pre-creation, we need commands to discover them.
> > > >
> > > > I think we need the feature bit VIRTIO_F_TRNSPT_VQ_VDEV, this 
> > > > feature bit indicates that the transport
> > > > virtqueue is the transport layer for the virtual devices, like PCI 
> > > > for a virtio PCI hardware.
> > > > So, not only create, we use the transport virtqueue to config the 
> > > > device as well.
> > > >
> > > > And if the virtual devices are pre-created, we can just send the 
> > > > create command, and the management device
> > > > can find a available device for us, this is also discovery.
> > > This seems to conflict with the semantics of pre-created devices.
> > same to the above