RE: [virtio-comment] RE: [PATCH v2 1/2] transport-pci: Introduce legacy registers access commands

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Sunday, May 21, 2023 8:55 PM
> 
> Think in a different way, if we don't care about the speed of those slow
> registers. For the method that accesses the configuration structure, could we
> simply extend VIRTIO_PCI_CAP_PCI_CFG capability?

I am familiar with this method which is what we had in v0.
It was a register interface as MMIO area which was just fine.
It has problem with the reset, which also can work if we make the reset register to behave in sane way in this MMIO region.
(slight different than what 0.9.5 had).
Sane way = device must tell that reset is complete (rather than driver assuming)

This was burdensome for the device, specially when the AQ exist to access these slow registers.
This is light weight mechanism for device to implement compared to MMIO or config cap registers.

So we need to decide and agree one way or other, to progress.
This has been lingering for a while now. Let's close on it.

1. legacy register access via AQ (v1)
Pros:
a. Light weight for hypervisor and devices (mainly PCI) to implement.
b. Enables sw to coalesce some device specific registers. 
Cons:
a. Not self-contained, requires PF's AQ which is anyway designed for such purpose.

2. Legacy registers access via new MMIO region (v0 + sane reset)
Pros:
a. smaller code in slow register access than AQ
b. Sw cannot coalesce some device specific registers.
c. Self-contained in the VF, 

Cons:
a. Relatively burdensome for the device as it requires more RW registers at scale.

3. legacy registers tunneling with additional indirection via PCI capability
Cons:
a. transport specific (but not big concern to me)
b. Twice the slow as it requires RW cap.
c. Inferior than #2, still requires sane reset as #2