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

[Parav Pandit <parav@nvidia.com>]

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