> From: Jason Wang <jasow...@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.
