> From: Michael S. Tsirkin <m...@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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
