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

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Thursday, May 11, 2023 3:17 AM

> > a configq/cmdq discussion is for new features for PF, VF, and SF/SIOV
> > devices to work in _non_ backward compatible way, because for new
> > features there is no such thing as backward compatibility between
> > guest driver and the device.
> 
> Ok, so what command did configq/cmdq have? 

> I thought it was similar to transport virtqueue, but it looks more like a control virtqueue here.
Yes, it is more like a cvq to do device attributes discovery and configuration.
Just that its generic enough.
For example 
creating VQ that spans multiple physical addresses.
Discovery and enabling new device attributes which are rarely accessed or accessed during device init/cleanup time.

The fundamental difference between cfgvq to tvq is:
Cfgvq is between the member virtio device and its driver.
Tvq=aq is on group owner of the virtio device.

> 
> >
> > >
> > >> Compatibility is coming at a cost which is not scaling.
> > >> If you attempt to scale, it breaks the future path forward to go without
> mediation.
> > >>
> > >>>>
> > >>>> So eve growing these fields and optionally placement on configq
> > >>>> doesn't really help and device builder to build it efficiently
> > >>>> (without much predictability).
> > >>>
> > >>> Config queue is not the only choice, we have a lot of other
> > >>> choices (for example PASID may help to reduce the on-chip resources).
> > >>>
> > >> PASID is for process isolation security construct, it is not for transportation.
> > >
> > > I meant with PASID you don't even need a BAR.
> > >
> > Not sure I fully understand, but my guess is, this is coming from
> > mediation thought process.
> 
> Not actually. I meant, for example without PASID, for modern devices, the
> common cfg structure must be placed on a BAR through MMIO.
> 
> But with the help of PASID, it could stay in the memory and the device can fetch
> it via DMA. The help to reduce the resources for registers.
> 
Yes, it can stay in memory and device can fetch via DMA using a VQ using its own q from guest driver.
Why does it need PASID?

> >
> > >> Same, SIOV and VFs do not prefer mediation going forward in the use
> cases we come across.
> > >
> > > Unless you don't want to provide VF compatibility for SIOV.
> > I do not understand what compatibility is this between which two elements?
> > VF has its identify currently and SIOV will have its own identity in future.
> 
> Ok, so it really depends on how to implement the transport for SIOV. I guess it
> won't use registers/BAR any more. If this is true, if we want to run a virtio-pci
> driver, it needs some mediation.
> 
> It works like what you proposed here. Someday, SR-IOV or BAR transport will
> become "legacy", but we need a way to make the "legacy virtio-pci driver"
> work.

> >
> > Live migration at VF level for the passthrough device can be just fine
> > without any mediation as long as all the parameters on src and dst
> > side match.
> > We already discussed in v0, so I prefer to avoid this again and focus
> > on the patch in discussion.
> 
> I agree we are far from the topic of legacy support. But my point stands still.
> We can discuss when live migration patches were posted by somebody.
> 
Ok.

> > Yet we are repeating and diverging from the discussion, that we should
> > not intermix:
> > 1. How to access legacy registers of the VF
> 
> With what you proposed, we don't even need legacy registers for VF. We just
> need to keep its semantic via the admin virtqueue commands.
Yes, we donât have IOBAR registers for the PCI VF. It is the 1.x VF so there are no legacy registers on it.
As proposed it is accessed are via aq commands of PF.