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: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.
Doorbells, capabilities and more. Then it is qualifying as a transport.
Otherwise, it is not a "virtio pci transport over aq".

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.
People have tried to tunnel pci over some other transports and it only fine for non-production toys.

> 
> 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.
Anything new will come on the cfgq and hence no bisection or registers needed.