Re: [virtio-comment] [PATCH v10 00/10] Introduce device group and device management

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

On 3/8/2023 3:31 AM, Parav Pandit wrote:
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, March 7, 2023 12:20 PM
> [..]
> > > > For SR-IOV, it is not unusual for PFs to excercise control over VFs.
> > > I understand the concepts of SR-IOV. Yet I fail to see the need of
> > > such concept in virtio world. SR-IOV is very specific solution for PCI
> > > functions instantiation, and I believe that it is already considered
> > > quite limiting in many aspects. Does not make sense to me to introduce
> > > it for virtio. But again, I may be missing something crucial, I just
> > > would like to see the motivation, needs, usecases for this crystal
> > > clear, which is opposite to the current cover letter I'm afraid :/
> > First people are asking for it because it's out there, however limiting it is. In
> > fact Nvidia is - why don't you talk to Parav here and tell him that SR-IOV is
> > legacy and there's no need to support.
> Jiri and I discussed offline today.
> SR-IOV is widely used today and in the coming future up to thousands of devices.
> Many vendors are building it or already built.
>
> SIOV as it stands today is still being crafted at various levels iommu, os, device, pci and more.
> Not there yet fully.
>
> Jiri and I built the Linux kernel interfaces for SFs which are equivalent to SIOVs that overcome some of the SR-IOV limitations.
> And Jiri's suggestion was to leverage some of the vision and practice from there.
>
> In other words, can AQ command be useful tomorrow for doing SIOV device add/remove, and provisioning from non-owning PF?
> The way AQ is crafted today is not there yet, but in the future, it can be extended.
I have submitted a series implementing "transport vq" which work for 
ADIs like SIOV devices, MST required a merge with admin q, so we are here.
> > > > There is interest in the community to include an interface to allow
> > > > this in the virtio spec, when the PF is a virtio device.  This is
> > > > what this patch does.
> > > Yeah, but why? As I asked before, what are the usecases? The fact
> > > there is interest in the community does not mean it makes sense to
> > > have it :)
> > If people want to build such hardware it will need some interface.
> > Far better to have it standard.
> >
> >
> > But generally e.g. intel already said they will reuse this same structure with a
> > different group type for SIOV support.
> > I'll mention this in the cover letter.
> We have the following already identified use cases of a device agnostic VQ.
>
> 1. SR-IOV VF device provisioning at virtio layer (features and config)
> 2. SR IOV (SR-PCIM interface of the PCI spec) for VF provisioning, for example, MSI-X vectors
>
> 3. SR-IOV VF Live migration
> 4. Above #1 to #3 for SIOV devices instead of SRIOV devices
>
> 5. cmd q interface for PF/VF/SF/SIOV to transport their own features, config command over queue interface without any parent device
>
> #1 to #3 are well described in past. So, It is worth covering them in the cover letter and things will be clear for new eyes.
> #4 is broad use case and like #1 to #3 that will eventually happen.
> #5 likely needs more discussion, we can differ to a later point because AQ needs to progress in spec 1.3.