[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access
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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]