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 3:15âPM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> 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?

Fortunately, we only have a few types of legacy devices.

> Could be nasty surprises there too.

Yes, but this needs to be addressed no matter what kind of device ABI is chosen.

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

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

>   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

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