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

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Wednesday, March 8, 2023 12:12 AM
> > 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's already a proposal to use the queue as a transport. Any device that
> can't use a transport specific configuration or provisioning can benefit from
> that. SIOV is only one of the users for that.
>
o.k. Better to include that link in the cover letter.
 
> > >
> > > >
> > > > >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
> >
> 
> The virtio layer device provisioning is transport independent. 
Yes. I listed known use cases above. If there are more that can use, sure.

> I don't see
> anything that is PCI specific there. Even the MSI-X could be reused by other
> transport.
>
Maybe yes.
I just donât know which other transport of virtio has defined MSI-X.
If there is, sure there are more users of AQ.
 
> > 3. SR-IOV VF Live migration
> 
> I think we don't want a partial solution for live migration that only works for PCI
> VF devices and L1. Instead, there needs to be a general device facility section
> and the admin virtqueue could be one of the interfaces for the driver to use the
> facility.
> 
May be there are more use cases of AQ than what I listed.

> > 4. Above #1 to #3 for SIOV devices instead of SRIOV devices
> 
> If we make the above as a general facility, it would not be hard to re-use them
> for transport virtqueue or SIOV.
>
Ok. thanks.