Re: [Qemu-devel] [RFC] virtio-mmio: implement modern (v2) personality (virtio-1)

[Michael S. Tsirkin]

On Tue, Jul 30, 2019 at 03:14:00PM +0200, Cornelia Huck wrote:
> On Tue, 30 Jul 2019 14:17:48 +0200
> Andrea Bolognani <address@hidden> wrote:
> 
> > On Tue, 2019-07-30 at 13:35 +0200, Cornelia Huck wrote:
> > > On Tue, 30 Jul 2019 12:25:30 +0200
> > > Andrea Bolognani <address@hidden> 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.

Right, the best we have is "non-transitional":

        Devices or drivers with no legacy compatibility are referred to as 
non-transitional devices and drivers, re-
        spectively.

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

That's not coming from the spec though. You can put a transitional
device on pci-e, in some configurations legacy guests will fail to boot
but modern ones will always work.

QEMU made modern a requirement for pcie to simplify things, such
that you can always be sure transitional supports a legacy guest.
We can relax that if we like.

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

Told you so ;) When the TC approved the decision not to
have transitional support I tried to complain but
enough people felt there will be more devices/drivers in the
future than in the past, so we should not worry too much.

Here we are, lots of time passed and now MMIO is held
back from even offering virtio 1 by default because
people want to run legacy guests and no one has the
energy to upgrade legacy drivers.

I don't think we'll repeat the mistake again though,
so I don't really expect another incompatible upgrade.

> So, this might make some sense for mmio; for ccw, I don't see any
> advantages other than confusing people further...