Re: proposal: use admin command (and aq) of the device to query config space

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Aug 02, 2023 at 11:51:21AM +0000, Parav Pandit wrote:
> 
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Wednesday, August 2, 2023 5:05 PM
> 
> > > I said the opposite above, get and set is INBAND from guest driver to device
> > for PF, VF and SIOV through its own delegated resource.
> > > There is no AQ mediation from host.
> > > Hence, there is no risk.
> > 
> > I think there are different requirements from different people.  
> Yes.
> There are two requirements.
> 1. Build SIOV device that can live in hypervisor for having 1.x based PCI device in guest
> 
> 2. Build SIOV device ground up that does not need to have existing limitations of 1.x.
> 
> The transport VQ proposal 4 patches had heavy inclination for #1 without mentioning the real objective in the cover letter.
> I was proposing that when virtio builds SIOV device it should start with #2.
> Because #1 is sort of handled with sr-iov or vdpa already.
> 
> #2 is more critical to get it right, after SIOV R2 spec is defined.


Can't we address both? E.g. use a different group type.


> 
> > For example,
> > consider compatibility. I know it looks like super important right now, and we
> > should make it possible, but it's just like with legacy interface - looked very far
> > away when we introduced non-transitional, to the point where an option in
> > linux to disable legacy talks about "flying cars", but the flying cars are nowhere
> > to be seen and, while we are not where everyone can just drop pre-1.0 bits, a
> > bunch of people are using e.g. vdpa without any legacy, express devices in
> > qemu also disabled legacy, and so on.
> > 
> > 
> > --
> > MST
>