Re: [Qemu-devel] [PATCH] virtio: Provide version-specific variants of virtio PCI devices

[Daniel P . Berrangé]

On Mon, Oct 15, 2018 at 03:14:04PM -0300, Eduardo Habkost wrote:
> On Sun, Oct 14, 2018 at 05:35:12PM -0400, Michael S. Tsirkin wrote:
> > On Fri, Oct 12, 2018 at 11:54:35PM -0300, Eduardo Habkost wrote:
> > > The current virtio-*-pci device types actually represent 3
> > > different types of devices:
> > > * virtio 1.0 non-transitional devices
> > > * virtio 1.0 transitional devices
> > > * virtio 0.9 ("legacy device" in virtio 1.0 terminology)
> > > 
> > > That would be just an annoyance if it didn't break our device/bus
> > > compatibility QMP interfaces.  With this multi-purpose device
> > > type, there's no way to tell management software that
> > > transitional devices and legacy devices require a Conventional
> > > PCI bus.
> > > 
> > > The multi-purpose device types would also prevent us from telling
> > > management software what's the PCI vendor/device ID for them,
> > > because their PCI IDs change at runtime depending on the bus
> > > where they were is plugged.
> > > 
> > > This patch adds separate device types for each of those virtio
> > > device flavors:
> > > 
> > > - virtio-*-pci: the existing multi-purpose device types
> > >   - Configurable using `disable-legacy` and `disable-modern`
> > >     properties
> > >   - Legacy driver support is automatically enabled/disabled
> > >     depending on the bus where it is plugged
> > >   - Supports Conventional PCI and PCI Express buses
> > >     (but Conventional PCI is incompatible with
> > >     disable-legacy=off)
> > >   - Changes PCI vendor/device IDs at runtime
> > > - virtio-*-pci-0.9: legacy virtio device
> > >   - Supports Conventional PCI buses only, because
> > >     it has a PIO BAR
> > > - virtio-*-pci-1.0-transitional: virtio-1.0 device supporting legacy 
> > > drivers
> > >   - Supports Conventional PCI buses only, because
> > >     it has a PIO BAR
> > > - virtio-*-pci-1.0: modern-only
> > >   - Supports both Conventional PCI and PCI Express buses
> > 
> > I would prefer a "modern" suffix since it will likely cover future
> > revisions as well.
> 
> That's on purpose. The new device types don't cover future
> revisions, otherwise we'll have exactly the same ambiguity
> problems in the future.
> 
> The moment we have a new virtio specification released, a device
> type called "modern" will automatically become ambiguous.

Agreed, I don't want to see us back in the same mess, if a
virtio-2.0 ever gets released with non-backcompatible
changes.

How about using only the major digit in the device names eg

  'virtio-blk-0.x'
  'virtio-blk-1.x'

to make it clearer that we cover 1.0 and 1.1 (and 1.2, etc
by the same device.

This assumes that virtio authors are indeed using semantic
versioning where minor digit indicates backcompat changes
and major digit indicates breaking  compat changes. 


> > Besides, I don't have a problem with this but I'd like an
> > ack from someone on the management side, confirming
> > these new interfaces are actually going to be used.
> > 
> > Could you copy some relevant people as well pls?
> 
> CCing Andrea, Daniel, and Laine from the libvirt side.

I don't have a objection from libvirt side.

Last time, I suggested/discussed this I was not convinced that the benefit
was compelling enough to justify the  work across all levels in the stack.

Apps using the new device model names would either make themselves
incompatible with older libvirt/QEMU, or they would increase their
code complexity & testing matrix by having to support both old & new
names. The usage would also harm migration to older hosts.

This just to be able to switch from i440fx to q35 for OS which don't
support virtio-1.0, but for such old OS, q35 isn't offering any
compelling features, so they might as well stick with the thing that
is known to work well.

If QEMU supports this, we'd support it in libvirt, but my recommendation
to apps would still likely be to not use it and simply stick with i440fx
for such older OS.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|