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 02:48:59PM +0000, Parav Pandit wrote:
> 
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Sunday, June 4, 2023 10:23 AM
> 
> > > > > > 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.
> > 
> > doorbell == available notification? yes in fact it's not strictly needed since PF can
> > use a different address for each VF.
> > 
> Sorry for doorbell terminology.
> Yes, available buffer notification.
> 
> > 
> > I am talking about the idea of exposing legacy VQ notifications in the PF BAR. To
> > me it looks nicely symmetrical, all legacy emulation goes through PF, and I think
> > it simplifies a bunch of driver code moving some complexity into hardware
> > which is what you seem to be intent on?
> > 
> Symmetrical only looks fine in emails.
> In real device, it doesn't. We also discussed this before.
> I will capture this in alternatives section of v4.
> 
> 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

> > > > Will it help if I get some feedback from windows driver team on the
> > > > design?
> > > >
> > > May be. I am not sure, given that these drivers are not inbox, they are not in
> > purview of the OS vendor.
> > 
> > Exactly a reason we might not see new APIs?
> > 
> I don't know.

Exactly.

> > > And OS vendor improves the OS APIs in the future for new use cases.
> > >
> > > Even the SR-IOV model in Windows is not elaborate as Linux AFAIK.
> > > So I am not sure how much value add we will have.
> > > But sure, better to have their view.
> > > Will you please add them to the discussion here or I should check?
> > 
> > I don't think they are subscribed to the list, so I can't.
> > Will talk to them.
> > 
> Ok.
> 
> > > Did anyone use vdpa acceleration on Windows?
> > > Do you have data points that someone wants VF acceleration on Windows
> > hypervisor?
> > > If you bring the use case, I would like to see there commitment to develop the
> > code also and it will be great to have virtio there.
> > 
> > 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.

> I don't see it that way.
> We have seen with two hypervisors evolving their kernel APIs and both have large deployments.
> 
> I am not pessimistic that 3rd OS vendor will not evolve.
> 
> > Device vendors can choose not to support some platforms, that is their
> > decision. As a compromise, consider device exposing this both in a PF and in a
> > VF and let's allow driver to use what's most convenient?
> >
> I also said yes, for this and you said "lets do one way".
> 
> 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.

-- 
MST