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

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

On Wed, Jun 21, 2023 at 03:50:00PM +0000, Parav Pandit wrote:
> 
> 
> > From: Parav Pandit
> > Sent: Tuesday, June 20, 2023 10:12 AM
> > 
> > Michael,
> > 
> > > From: Parav Pandit <parav@nvidia.com>
> > > Sent: Monday, June 19, 2023 2:07 PM
> > > We don't need to do it now.
> > >
> > > > Current VF capability is kind of ok I guess ...
> > > >
> > > Already proposed one?
> > >
> > > > If you want admin command to query then it would need to map in PF
> > > memory.
> > > No need.
> > > It is similar to rest of the configuration access commands.
> > >
> > > > I understand two concerns with this:
> > > > - you worry that this forces ordering requirements - it's true and I
> > > >   don't know of a good fix. So if possible use VF BAR by preference?
> > > > - you worry about wasting physical memory space
> > > >   this we can fix by sticking VF# in the kick.
> > > >
> > > > As an alternative, if we can make the new command able to
> > > > communicate offset in PCI BAR or in VF BAR or both then I think
> > > > that's also an acceptable
> > >
> > > A new command proposed was for VF BAR that member driver can ask to
> > > its group owner driver (like rest of the config commands).
> > >
> > 
> > Are you ok with the admin command to query the notification address of the
> > member device bar?
> > 
> > I presented both the proposals.
> > We need to conclude this now without keep flipping between two from version
> > to version.
> > 
> > a. v3 with admin command
> > pros:
> > 1. self-contained via AQ for rest of the control path operations.
> > 2. Can work with future siov device who may want to support legacy 3. Doesn't
> > bake things in low level pci capabilities which is hard to get rid of 4. Able to add
> > new command or new response if some device wants to support this on PF
> > (very unlikely)
> > 
> Given that this has more pros and no objection to it, 
> I will revise v7 today with query admin command like v3.

Not like v3 please. If you want to re-open this:


First I think we need multiple offsets just like notification
capaiblity, sorted by priority. Second I think we need ability to report
offset within owner not member.

So please add ability to report multiple offsets, and add e.g.
a flags field, with bits for owner, member.


> > b. and v6 with capability extension.
> > Cons:
> > 1. Does not have above advantages
> > 
> > Pros:
> > 1. Uses existing PCI capability for the extension
> > 
> > 
> > > A future command can tell for the PF BAR if needed and some device
> > > wants to do such extra implementation.
> > >
> > > > compromize:
> > > > drivers that have trouble mapping VF BAR after querying PF can just
> > > > map PF BAR. WDYT?
> > >
> > > PF BAR for notification can be done later when there is some device
> > > who really have the limitation and wants to do that.
> > > We don't see that additional need as driver notifications are present
> > > on the VF already as listed in the alternative.