On Tue, 30 Jul 2019 14:17:48 +0200
Andrea Bolognani <abolo...@redhat.com> wrote:
> On Tue, 2019-07-30 at 13:35 +0200, Cornelia Huck wrote:
> > On Tue, 30 Jul 2019 12:25:30 +0200
> > Andrea Bolognani <abolo...@redhat.com> wrote:
> > > Can you please make sure virtio-mmio uses the existing interface
> > > instead of introducing a new one?
> >
> > FWIW, I really hate virtio-pci's disable-modern/disable-legacy... for a
> > starter, what is 'modern'? Will we have 'ultra-modern' in the future?
>
> AIUI the modern/legacy terminology is part of the VirtIO spec, so
> while I agree that it's not necessarily the least prone to ambiguity
> at least it's well defined.
Legacy is, modern isn't :) Devices/drivers are conforming to the
standard, I don't think there's a special term for that.
>
> > It is also quite backwards with the 'disable' terminology.
>
> That's also true. I never claimed the way virtio-pci does it is
> perfect!
>
> > We also have a different mechanism for virtio-ccw ('max_revision',
> > which covers a bit more than virtio-1; it doesn't have a 'min_revision',
> > as negotiating the revision down is fine), so I don't see why
> > virtio-mmio should replicate the virtio-pci mechanism.
> >
> > Also, IIUC, virtio-mmio does not have transitional devices, but either
> > version 1 (legacy) or version 2 (virtio-1). It probably makes more
> > sense to expose the device version instead; either as an exact version
> > (especially if it isn't supposed to go up without incompatible
> > changes), or with some min/max concept (where version 1 would stand a
> > bit alone, so that would probably be a bit awkward.)
>
> I think that if reinventing the wheel is generally agreed not to be
> a good idea, then it stands to reason that reinventing it twice can
> only be described as absolute madness :)
>
> We should have a single way to control the VirtIO protocol version
> that works for all VirtIO devices, regardless of transport. We might
> even want to have virtio-*-{device,ccw}-non-transitional to mirror
> the existing virtio-*-pci-non-transitional.
>
> FWIW, libvirt already implements support for (non)-transitional
> virtio-pci devices using either the dedicated devices or the base
> virtio-pci plus the disable-{modern,legacy} attributes.
One problem (besides my dislike of the existing virtio-pci
interfaces :) is that pci, ccw, and mmio all have slightly different
semantics.
- pci: If we need to keep legacy support around, we cannot enable some
features (IIRC, pci-e, maybe others as well.) That means transitional
devices are in some ways inferior to virtio-1 only devices, so it
makes a lot of sense to be able to configure devices without legacy
support. The differences between legacy and virtio-1 are quite large.
- ccw: Has revisions negotiated between device and driver; virtio-1
requires revision 1 or higher. (Legacy drivers that don't know the
concept of revisions automatically get revision 0.) Differences
between legacy and virtio-1 are mostly virtqueue endianness and some
control structures.
- mmio: Has device versions offered by the device, the driver can take
it or leave it. No transitional devices. Differences don't look as
large as the ones for pci, either.
So, if we were to duplicate the same scheme as for pci for ccw and mmio
as well, we'd get
- ccw: devices that support revision 0 only (disable-modern), that act
as today, or that support at least revision 1 (disable-legacy). We
still need to keep max_revision around for backwards compatibility.
Legacy only makes sense for compat machines (although this is
equivalent to max_revision 0); I don't see a reason why you would
want virtio-1 only devices, unless you'd want to rip out legacy
support in QEMU completely.
- mmio: devices that support version 1 (disable-modern), or version 2
(disable-legacy). You cannot have both at the same time. Whether this
makes sense depends on whether there will be a version 3 in the
future.
So, this might make some sense for mmio; for ccw, I don't see any
advantages other than confusing people further...
