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

[Michael S. Tsirkin]

On Mon, Nov 19, 2018 at 07:32:38PM +0100, Cornelia Huck wrote:
> On Mon, 19 Nov 2018 13:07:59 -0500
> "Michael S. Tsirkin" <mst at redhat.com> wrote:
> 
> > 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:  
> 
> > > > > 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.
> 
> I don't really expect that to happen on a drop of a hat, though :) It's
> probably more likely when we either have some really major change (and
> we messed up if we can't handle that via the virtio compatibility
> mechanism), or we go up from 1.x because x is getting too large (won't
> happen in the near future.)
> 
> But yes, we should be able to handle further updates without any change
> like the ones complicating things now for virtio-pci, as that was
> mostly the transition to a proper standard while flushing out some
> design problems that you only become aware of later.
> 
> > 
> > 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.
> 
> I'd argue that it's problematic on platforms where you have different
> options for virtio transports. What does "model=virtio" mean? Always
> virtio-pci, if available? Or rather virtio-<transport>, with
> <transport> being the best option for the machine?

Most people don't care, for them it's "whatever works".

We have this assumption that if we force a choice then people will
choose the right thing but in practice they will do what we all do, play
with it until it kind of works and leave well alone afterwards.
That's at best - at worst give up and use an easier tool.

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