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

[Parav Pandit <parav@nvidia.com>]

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Jason Wang
> Sent: Monday, June 26, 2023 12:00 AM

> >   This way we just say "make legacy guests work" and
> >   this is the problem of the hardware vendor not ours.
> 
> Probably, but we need to try our best to simplify the vendor's life.
>
> >
> > - limit the impact. We don't get to maintain the set of hacks
> >   needed for legacy in the hypervisor
> 
> This is only true if the vendor fully understands the behaviour of the legacy and
> implements it correctly which would be very hard. We would end up with quirks
> in the hypervisor soon or later.
> 
You can help vendor understand the legacy so that hypervisor donât have the quirks. :)

> > - when some weird legacy
> >   support requirement surfaces, it will be up to the vendor
> >   to fix. HW vendors are also more agressive in deprecating
> >   old hardware - they will just stop shipping new
> >   hardware when there are no new customers and we can
> >   stop adding new hacks.
> 
> But the hacks would be there forever if there's users.
> 
> >
> > - test out admin command interface. This use-case is smaller
> >   than full transport vq but similar enough that
> >   we will learn valuable lessons from it.
> 
> Another issue is that the interface is designed to be PCI specific (at least from its
> name) which may result in a strange mediation for MMIO legacy guests.
> 
It is no different than AQ being only for the PCI today.
So far no user of MMIO legacy, may be in future it can be extended if required.

We donât want legacy to be that grand either.

I am moving most things to generic section (instead of PCI) based on Michael's inputs.


> >   For example, it already helped us find and correct
> >   a design mistake where admin commands had 8 byte aligned length.
> >   As another example, I am working on ability to report events to admin
> command
> >   infrastructure which is currently missing.
> 
> If we want a MMIO interface for admin commands, it requires more extensions
> for such kind of notification.
> 
> >   With that in place we will be able to add INT#x emulation for very old
> >   guests.
> >
> >
> >
> > In short, this interface as you correctly point out is not the normal
> > way we build interfaces since it is not modular and less flexible than
> > individual feature bits.  However, for the legacy interface this might
> > be a good thing.
> 
> Ok, I think I would not object to this proposal, but we should not exclude the
> possibility of having things like LEGACY_HEADER in the future.

Thanks.