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

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Jun 09, 2023 at 10:06:43AM +0800, Jason Wang wrote:
> On Thu, Jun 8, 2023 at 10:38âPM Parav Pandit <parav@nvidia.com> wrote:
> >
> >
> > > From: Jason Wang <jasowang@redhat.com>
> > > Sent: Wednesday, June 7, 2023 2:54 AM
> >
> > > Hypervisor can trap the legacy device configuration space write and convert it
> > > to cvq commands.
> > Michael already answered that cvq is not trapped; this is the main design goal we talked several times that it is passthrough device.
> 
> Is this really a blocker? Wouldn't a new feature(_F_LEFACY_MAC) or cap
> resolve this?

Of course we can create a set of feature bits emulating legacy.

> >
> > So no point discussing this again.
> >
> > If you have any comments on v4, please let me know.
> >
> > Both the design points are addressed in v4.
> > 1. To split to two commands for device and config area
> > 2. Use pci cap to learn about notification region
> >
> > Since this ABI reflects what we agree on,
> 
> I think not since you fail to explain why this approach is better than
> simply adding new features like _F_LEGACY_HEADER and _F_LEGACY_MAC.
> 
> Thanks

I can explain, I think it's better for these reasons:

- limit the scope. We started out with _F_LEGACY_HEADER
  but now there's _F_LEGACY_MAC too. What about other
  device types? Could be nasty surprises there too.
  This way we just say "make legacy guests work" and
  this is the problem of the hardware vendor not ours.

- limit the impact. We don't get to maintain the set of hacks
  needed for legacy in the hypervisor - 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.

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


> > I would want to raise for vote in coming days to be part of 1.3 in few days as we have more than 3 weeks to sort out non-ABI language part.