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

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

On Mon, Jun 19, 2023 at 05:45:17PM +0000, Parav Pandit wrote:
> 
> 
> > 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 worry about systems where there's value in having VF driver
map memory without talking to PF driver.
Current VF capability is kind of ok I guess ...

If you want admin command to query then it would need
to map in PF memory.
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 compromize:
drivers that have trouble mapping VF BAR after querying
PF can just map PF BAR. WDYT?


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


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/