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