[libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices

[Michael S. Tsirkin]

On Mon, Nov 19, 2018 at 11:41:05AM +0100, Cornelia Huck wrote:
> On Fri, 16 Nov 2018 01:45:51 -0200
> Eduardo Habkost <ehabkost at redhat.com> wrote:
> 
> > On Thu, Nov 15, 2018 at 05:29:24PM +0100, Andrea Bolognani wrote:
> 
> > > One thing that I'm very much not convinced about is the naming,
> > > specifically leaving the virtio revision out: I get it that we
> > > Should Never Need™ another major version of the spec, but I'm
> > > afraid discounting the possibility outright might prove to be
> > > shortsighted and come back to bite us later, so I'd much rather
> > > keep it.

That's not the claim. In fact the reverse is true - a major revision can
come at any point. The claim is that virtio compatibility is not based
on version numbers.  And another claim is that you can trust the
virtio TC not to overload terminology that it put in the spec. So use
that and you should be fine.  Come up with your own and end up writing
another spec just to document it.

> > > 
> > > And once that's done, "non-transitional" (while matching the
> > > language of the spec) starts to look a bit unnecessary when you
> > > could simply have
> > > 
> > >   virtio-*-pci
> > >   virtio-*-pci-1
> > >   virtio-*-pci-1-transitional
> > > 
> > > instead. But I don't feel as strongly about this as I do about
> > > keeping the virtio revision in the device name :)  
> > 
> > I like that suggestion.  Makes the device names more explicit
> > _and_ shorter.  I'll do that in v3.
> 
> OTOH, that would mean we'd need to introduce new device types if we
> ever start to support a virtio 2.x standard. My understanding was that
> we'll want separate device types for transitional and non-transitional
> for two reasons: the bus which a device can be plugged into, and
> changing ids. Do we really expect huge changes in a possible 2.x
> standard that affect virtio-pci only, and not other virtio transports
> as well?

Yes I think adding a version there is a mistake.
transitional/legacy/non-transitional are spec terms so
they are unlikely to change abruptly. OTOH virtio TC can
just decide next version is 2.0 on a drop of a hat.

And I strongly believe command line users really really do not want all
this mess. Even adding "pci" is the name confuses people (what are the
other options?). For command line model=virtio is pretty much perfect.
So all these names are there primarily for libvirt's benefit.
And the only input from libvirt devs so far
has been that it's unclear how does cross version
migration work. That needs to be addressed in some way.

So can we maybe start with a libvirt domain xml patch, with an
implementation for existing QEMU, get that acked, and then just map it
back to qemu command line as directly as possible?

-- 
MST