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

Parav Pandit
2023-05-15T15:59:50Z

> 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.