RE: [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Monday, June 19, 2023 1:38 PM

> > > If we can't just make it come for free then maybe
> > > VIRTIO_PCI_CAP_LEGACY_NOTIFY_CFG is better, we can just list the
> > > number in the common section and then link to the description in the new
> section.
> > >
> > How is it better? It requires burning more bytes.
> > Is it better because it is self contained?
> 
> Mostly yes. But it also adds a bit more flexibility, right?
> I thought avoiding touching transport-pci is worth less flexibility but if we can't
> avoid that...
>
That flexibility is better gained via AQ instead of introducing new extended capability on the VF.
 
> 
> > > I also feel we want ability to have such a capability in the owner too.
> > > Would prefer including it now though I guess we can add it as an extension.
> >
> > Re-opening the past discussion.. amazing. :)
> 
> OK fair enough.. I guess both of us are not 100% happy but it's a compromize
> for now. And maybe we'll add one of AQ and / or PF cap down the road.
> 
> > Why? How is it different and better than querying over AQ?
> 
> Wait a second let me clarify. I am talking about notification in the PCI BAR of the
> PF. *Not* offset in PF capability but in the VF BAR.
> 
Ok. question remains the same, why not discover such notification capability it over the AQ command?
AQ command on the PF is self-contained and extendible without baking things in very low level hw centric pci capabilities, which are hard to get rid of it.

> 
> > I see the AQ is better than group owner and group member specific cap.
>