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

[Jason Wang <jasowang@redhat.com>]

On Wed, Jun 7, 2023 at 11:06âAM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Tuesday, June 6, 2023 10:27 PM
> >
> > I can't say I like this. I prefer to do meditation on top of a modern device with
> > some lightweight features like _F_LEAGCY_HEADER. I don't see any advantages
> > of a new legacy ABI over _F_LEGACY_HEADER. I don't want to repeat but I don't
> > get any response here
> >
> It is net only and not generic. Not a big blocker.
> It doesnt stop at _F_LEAGCY_HEADER.
>
> > Anything that prevents you from adding things like VIRTIO_NET_F_LEGACY_HEADER?
> It requires hypervisor to mediate 1.x config region and intercept feature negotiation including q config and more.

For config region, do you mean device configuration space or common
config space?

I don't see why we need to do mediation on neiter of the above.
Hypervisor just need to prepare

1) legacy BAR with legacy config and device configuration space and
2) modern BAR with modern capabilities (common cfg and device cfg)

For 2) it could be mapped directly to the modern capabilities. For 1)
hypervisor needs to mediate

>
> Additionally, 1.x device says the mac address is read only, while legacy is RW.
> And that requires yet another feature bit negotiation.

Hypervisor can trap the legacy device configuration space write and
convert it to cvq commands.

Thanks

>
> The main design goal is to not mediate 1.x specific region and not modify 1.x region definitions.
> Which is why we step forward with the AQ.
>
> > https://lore.kernel.org/virtio-
> > dev/CACGkMEuixsBibSq_pEQvcKOH0WBQWnta4Q2c28SV8qTS8gaVcA@mail.g
> > mail.com/#t