Re: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ

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

On Sun, Jun 04, 2023 at 01:41:54PM +0000, Parav Pandit wrote:
> 
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Sunday, June 4, 2023 9:34 AM
> > 
> > On Fri, Jun 02, 2023 at 11:36:01PM +0300, Parav Pandit wrote:
> > > This short series introduces legacy registers access commands for the
> > > owner group member PCI PF to access the legacy registers of the member VFs.
> > 
> > Note that some work will be needed here to fix up grammar and spelling
> > mistakes.
> >
> I already verified using codespell but I guess it missed few.
> If you have specific already identified, let me know.

I remember seeing something about a drier somewhere :)

> If not I will run a different checker.

Yea, pls check grammar too.

> > > If in future any SIOV devices to support legacy registers, they can be
> > > easily supported using same commands by using the group member
> > > identifiers of the future SIOV devices.
> > 
> > Yes, with the exception of
> > VIRTIO_ADMIN_CMD_LQ_NOTIFY_QUERY - currently refers to VF BAR,
> > subfunctions do not have it.
> A subfunction will also have its own BAR carved out from the PF BAR.
> A subfunction definition will be as contains as possible.
> 
> > Can we find a way to have it in the PF BAR instead?
> At subfution level also it will be a BAR number, which will map to the PF BAR.

exactly. why not support this for PF too?

> > E.g. the notification can include VF# + VQ#?
> > At least as an option?
> No. we discussed this before to have each device on its own BAR. Hence no VF# in the doorbell.

you said that you want it but without much in the way of
explanation. I'm still not convinced it's a workable interface. Will it help
if I get some feedback from windows driver team on the design?

> > If not can you add some info explaining why not?
> Yes, Good point.
> I will add the commit log explanation that every VF has its own BAR hence it does not use PF BAR.


-- 
MST