Re: [virtio-comment] Re: [virtio-dev] Re: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ

[Jason Wang <jasowang@redhat.com>]

On Fri, Jun 9, 2023 at 11:26âAM Parav Pandit <parav@nvidia.com> wrote:
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Thursday, June 8, 2023 11:03 PM
>
> > When legacy drivers are doing feature negotiation, the hypervisor must trap and
> > negotiate those two features.
> Device reset to be trapped as well towards 1.x.

It needs to be trapped even with admin virtqueue.

>
> And this messes the 1.x flow with FEATURES_OK.

How can it mess? The new status was hidden from the legacy driver.
This kind of trick has been used by Qemu for a while.

> More citations from the spec:
>
> "Legacy driver implementations often used the device before setting the DRIVER_OK bit, and sometimes
> even before writing the feature bits to the device."
>
> It may even set before setting the feature bits.

How does adminq differ/help in this case? Note that the legacy
interface is fully mediated/emulated, the control patch is fully
trapped so it can choose to do anything it can.

What's more important, the above example is exactly what we should do
with modern devices since it's too late to precisely define the
behaviour of the legacy device. Admin virtqueue is not the cure for
this since the legacy device's behaviour is defined by the existing
hypervisor codes, not the spec.

So again, we have:

1) well defined (if it's not we can fix the spec) device behaviour
(modern device plus well defined legacy features like mac/header)
2) device with legacy behaviours that can't be defined or documented
(approach used in this series)

1) is far more simple for both hypervisor and hardware and 2) may end
up with subtle undocumented behaviour differences among vendors.

> It is ugly to use the 1.x state machine.

This is the methodology used by mediation which is very common in
virtualization.

> I would like to keep the stateful interactions of 1.x device outside of 0.9.5.

I don't think this is a real problem, but let's see the drawbacks of
this proposal:

1) non-trivial changes of full new transport alike ABI
2) can't work for nesting
3) require vendor to implement legacy behaviour which can't be
documented precisely
4) require admin virtqueue to work

We won't have the above issues if we use modern + legacy header/mac.

Thanks


>
> > When modern drivers are doing the feature negotiation, the hypervisor is not
> > involved at all. So modern drivers can choose to negotiate (e.g try to mediate
> > legacy for L2) or not.
>