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 03:07:27PM +0000, Parav Pandit wrote:
> 
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Sunday, June 4, 2023 10:54 AM
> 
> > > Each VF has its own available buffer notification in hardware like 1.x.
> > > We do not want to duplicate (and add) such functionality on the PF BAR
> > hardware when it already exists on the VF.
> > 
> > yes but here we are talking about legacy notifications, not 1.x
> >
> 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.

> > > > We are talking about an interface that will be used tens of years
> > > > from now. If the interface is awkward to use on some platforms let's
> > > > make it easier not hide behind excuses of no demand to fix it as of last
> > Friday.
> > > It is not hiding.
> > > The fact that virtio drivers are not inbox. I don't see an actual user by the OS
> > vendor for the decade passed.
> > 
> > But why does it matter? There are a bunch of users of virtio, I know that.
> > 
> > > And, I do not anticipate use of legacy for tens of years from now.
> > >
> > > It is not even a conclusion that it is awkward to use.
> > > You are concluding that one OS may never want to evolve their kernel APIs.
> > 
> > They might. That takes many years too.
> >
> By that time legacy may not be even a use case for them.
> If an OS vendor evolves slowly compare to other two OS, such OS may have to change their process, not the virtio-spec.

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.

> > > So, when a 2nd OS vendor cannot use IPR scheme that they have, and they
> > MUST have everything through ONLY VF, to support them, a HW vendor will
> > build PCI device with VF legacy access registers stay in the VF.
> > > And spec update will be done.
> > >
> > > We really don't see this happening. So better to build a practical spec.
> > >
> > > And if this was important, I am still puzzled why you say "Just AQ is fine" in v2
> > and why you wait for next 2 weeks for v3 to show up to raise the concern now
> > contradicting your ACK.
> > 
> > Because this is just AQ. All I am asking is that the BAR refers to PF, same AQ
> > command.
> 
> 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.

> 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.

-- 
MST