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

[Jason Wang <jasowang@redhat.com>]

å 2023/5/11 21:15, Parav Pandit åé:
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Thursday, May 11, 2023 3:05 AM
> > If we decide to use the admin vq, is there any good reason to tie it to PCI if we
> > don't want to tunneling PCI over adminq?
> To truly tunnel PCI over adminq, please tunnel _all_ pci things over AQ, not just below 1 to 11.


Just to clarify, below 1 to 11 is not tunnel PCI over adminq, it's the 
idea of transport virtqueue which is not specific to PCI.

If we want to tunnel PCI over adminq, it needs be accessed via your BAR 
access commands.


> Doorbells, capabilities and more. Then it is qualifying as a transport.
> Otherwise, it is not a "virtio pci transport over aq".


Yes, it's basically just have some extension on your proposal, adding a 
config space access method that should be fine.


> I neither see why one would tunnel whole PCI over some queue, which was not your intention either from the patches I see.
> VQ over fabrics is much cleaner design to transport VQ over non-PCI.


That's a different topic, and we don't need to think of the legacy 
support there.


> People have tried to tunnel pci over some other transports and it only fine for non-production toys.


I've replied this in another thread.


> > Why not simply invent individual commands to access legacy facilities like
> > commands to access like what transport virtqueue did for modern
> > device?:
> I donât see how this is being any different than register-offset interface.
> It bisects more things at hypervisor level that makes things hard to add #12th entry.
>
> > 1) device features
> > 2) driver features
> > 3) queue address
> > 4) queue size
> > 5) queue select
> > 6) queue notify
> > 7) device status
> > 8) ISR status
> > 9) config msix
> > 10) queue msix
> > 11) device configuration space
> >
> > It focuses on the facilities instead of transport specific details like registers (we
> > don't even need legacy registers in this case), I gives more deterministic
> > behavior so we don't need to care about the cross registers read/write.
> 1.x has these registers at raw level and that seems fine.


Note that 1.x has more, the above is dumped from the section of "Legacy 
Interfaces: A Note on PCI Device Layout".

Thanks


> Anything new will come on the cfgq and hence no bisection or registers needed.