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: Monday, May 15, 2023 3:31 AM

> > What do we gain from bisecting it?
> 
> 
> 1) No need to deal with the offset in the hardware
> 
In context of legacy is doesnât matter much given that its over AQ.

> 2) transport independent
> 
AQ commands are transport independent so, it is covered.

> 3) avoid duplication with the (legacy support of) transport virtqueue
> 
Modern interface does not need mediation; hence it is not duplication with legacy.

> 
> > Every new additional needs involvement of the hypervisor as Michael noted
> below on "effort" point.
> 
> 
> I'm not sure I get your point.
> 
> If additional effort is not wanted, we need a full PCI over adminq,
> that's what I suggested, then we don't need any extension for any new
> features probably.
> 
When there is already a PCI VF, I donât see why one would implement "PCI over adminq".
It is impractical.
And SF/SIOV is bit still far in future.

When "PCI over adminq" happen, it is really a very different set of commands that emulated the "PCI virtio" device.
I donât know when/why.

> If we choose to invent dedicated adminq commands:
> 
> For legacy, we don't need any new additional effort since the above 11
> maps to the legacy virtio-pci facilities.
> 
Only few commands are needed.
Modern interface config doesnât travel through mediation.

> For modern, if the feature is something related to the transport, we
> need new transport interface for sure.
> 
Everything is transport as it flows to/from driver to device covered in the respective transport chapter. ð

> 
> >
> > The register offset and read/write is far simpler interface for hypervisor.
> 
> 
> If this is true, why not go full PCI over adminq? Hypervisor in this
> case even don't need to deal with config space.
> 
I donât see a use case now and its extremely heavy to do so and it doesnât apply to PCI VFs at all.

> 
> >
> > Not to do cross register access is what we need to define in the spec for 1.x or
> future things.
> 
> 
> You can't assume the hypervisor behaviors, so the device or at least the
> spec should be ready for that.
>
My above comment is for the driver to device interface to access registers on its natural boundary.
Which part of the proposal assumes a hypervisor behavior?
Nothing to do with hypervisor.