RE: [virtio-comment] Re: virtio member device provisioning get/set and virtio child device life cycle mixing not needed

[Parav Pandit <parav@nvidia.com>]

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Zhu, Lingshan
> Sent: Wednesday, June 28, 2023 3:31 AM
> 
> On 6/28/2023 8:22 AM, Parav Pandit wrote:
> > Hi Lingshan Zhu,
> >
> > I have reviewed v4 version transport VQ a while back that consist of two main
> pieces.
> >
> > 1. some virtio device creation/destroy commands 2. virtio device
> > feature and config space provisioning commands.
> >
> > Many of us are seeing the value of device provisioning commands
> with/without live migration.
> >
> > New virtio devices do not need to follow any existing of config space etc per
> say for real hw.
> > There is some value in reusing software but it may not be the prime driving
> factor for brand new devices.
> > This needs more discussion and not as_is done in the v4.
> >
> > So, if you are planning to revise your transport vq patches as admin
> commands, please split the series into two.
> >
> > a. device and config space provisioning SET/GET part.
> Hi Parav
> 
> I agree it is good to unify the interface for SRIOV and SIOV. However more
> discussion is required, e.g., for a VF, will config its MSIX by admin vq(owned by
> host) conflict with the MSIX cap.
> 
No, it doesn't conflict.
SR-PCIM interface is outside the scope of PCIe spec.
I completed the work in PCI spec to clarify this already, its coming in the 6.1 errata spec.

Non virtio device and Linux kernel both already has similar implementation in place and in use for more than a year. 
So msix provisioning via AQ is fine. VF can expose new MSIX capability post reconfiguration via AQ.

We will be able to unify them across SRIOV and SIOV.
SIOV anyway has to wait as its undergoing significant changes currently.