[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:47:40PM -0200, Eduardo Habkost wrote:
> On Mon, Nov 19, 2018 at 01:07:59PM -0500, Michael S. Tsirkin wrote:
> n
> > 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.
> 
> What still needs to be addressed?

I don't belive you answered Daniel's question.

>  Just keep the existing device
> types on migration.  We could make additional promises about
> compatibility with the disable-modern and disable-legacy
> properties, but I don't see why we need to do it unless we start
> deprecating the old device types.

Then the answer seems to be in the negative?

> 
> > 
> > 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?
> 
> I don't know what you mean here by "libvirt domain XML patch".
> 
> Do you mean solving the problems only on the libvirt side,
> keeping the existing device types?  Why would we do that?  It
> would be a hack making the situation even messier.
> 
> If libvirt needs us to provide better interfaces, let's cooperate
> with them.  I'd like us to avoid having yet another "the problem
> must be solved in the other layer first" deadlock here.

I mean IIUC libvirt is the solve user that will benefit from this patch.
Let's at least get an ack confirming it does make their lives easier.

> -- 
> Eduardo