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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Sunday, June 4, 2023 5:49 PM

> > Legacy can utilize the 1.x hw plumbing without building new hypothetical PF
> hardware.
> 
> Maybe.
> Whether 1.x BAR can be reused for legacy would depend on a bunch of factors.
> E.g. with 1.x using VIRTIO_F_NOTIF_CONFIG_DATA - probably not.
>
Not really because legacy doesn't have that feature.
Legacy notifications are subset of 1.x feature.
This was also discussed.

> Let's just say, we are not in the position where we dictate these things to OS
> vendors yet.  One of motivations of the spec is making writing drivers easier so
> let's add an option for that pls.
>
There is no need to add multiple options at this point when the hw vendors are not going to implement.
When we find another vendor to implement, we can always add the new method.
Marvell and Nvidia both are forwarding with AQ at present proposal.

> > VF has BAR for driver notifications. This BAR is used for 1.x and legacy.
> 
> But it's the same piece of silicon - be it in PF or in VF.
> I really don't see why it matters.
>
In same piece of silicon one needs to open yet another PCI steering entry to tell that treat this for VF.
This double size programming is useless.

Yet again we are discussing same point as before.

> > There is no need to ask vendors to build new HW to put driver notifications
> on the PF BAR for VFs, when it already exists on the VF.
> I'm talking about giving vendors an option not asking them.
>
Ok. Understood.
When a vendor prefers to implement such cross hw forwarding it can be done.
There isn't a desire to burn and program extra hw for functionality that already exists on the VF.
Hence, VF's doorbell on PF can be parked for the future option when one actually wants to implement it.