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

[Eduardo Habkost]

On Wed, Oct 17, 2018 at 12:43:02PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-10-16 at 15:12 -0400, Laine Stump wrote:
> > On 10/16/2018 01:02 PM, Daniel P. Berrangé wrote:
> > > On Mon, Oct 15, 2018 at 03:14:04PM -0300, Eduardo Habkost wrote:
> > > 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.
> > 
> > +1 from me on either "-1" or "-1.x", and a -1 on "-1.0" or "-modern".
> 
> Agreed on using the major version number rather than a non-specific
> string, and since the number refers to the virtio protocol version
> I would expect the result to be
> 
>   virtio-0-blk-pci
>   virtio-1-blk-pci
> 
> and so on.
> 
> The proposal doesn't directly address the interaction between virtio
> protocol version and slot type. [...]

It does.  See the interface names added to each device type.


>                           [...] Admittedly, I don't recall all the
> details myself, but the point is that I would like to see the slot
> type mentioned explicitly in the device name to avoid confusion, so
> the above might end up looking more like
> 
>   virtio-0-blk-pci
>   virtio-1-blk-pci
>   virtio-1-blk-pcie
> 
> details myself, but the point is that I would like to see the slot
> type mentioned explicitly in the device name to avoid confusion, so
> the above might end up looking more like
> 
>   virtio-0-blk-pci
>   virtio-1-blk-pci
>   virtio-1-blk-pcie
> 
> with the last one very clearly not being usable on i440fx. I might
> have gotten some details wrong in the example, but you get the idea.

The difference between the devices is not just the bus type: it
is a different type of device with different behavior.  Using the
bus type to differentiate them would be misleading.

e.g. both modern and transitional virtio devices can be plugged
to Conventional PCI buses, but they have different PCI IDs.

I'm considering doing this in v2:

* Remove the -0.9 device type, because nobody seems to need it
* Add two device types:
  * virtio-1-blk-pci-non-transitional
  * virtio-1-blk-pci-transitional

This way, we:
* Include only the major version of the spec (so
  we don't require new device types for virtio 1.1, 1.2, etc),
* Use terms that come from the Virtio spec itself, to avoid
  ambiguity.

> 
> [...]
> > > 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.
> > 
> > The *current* compelling reason is to permit management apps to use Q35
> > for "old" OSes that don't have a driver for virtio-1.0, (and especially
> > *new* management apps that want to support only Q35 from the start), but
> > there are other future advantages that will make us appreciate that this
> > was done. For example, libosinfo currently reports separately that an
> > supports virtio-0.9 devices and/or virtio-1.0 devices, but a management
> > app would need to have extra logic to take account of the fact that the
> > only way to get a virtio-0.9 device would be to place it on a
> > conventional PCI bus; if qemu offers the two as separate devices then
> > all the management app has to do is use the device that libosinfo tells
> > it to use, and it will automatically be placed on the right kind of bus.
> > (and I've heard from Eduardo that eventually we'll be able to learn the
> > PCI ID of the devices from qmp introspection, so the management app will
> > be able to just look for a device ID that is on both the qemu and the OS
> > list, and use that).
> > 
> > Obviously using these devices will make it impossible to migrate a guest
> > that uses them to an older host that doesn't have "new" qemu + libvirt,
> > but if that's important to a management app, then they can just do
> > things in the more complicated manner needed by the "combined" virtio
> > device variants. (Again, if a management app is just being
> > designed/written now, it can assume these new devices from the start and
> > ignore the older combined device).
> > 
> > In the end, having a device that changed PCI ID depending on what kind
> > of slot it was plugged into was an idea "too clever for its own good",
> > should be avoided when new devices are added in the future, and we
> > should at least provide an alternative that doesn't do that for existing
> > devices.
> 
> Agreed, the current situation is kind of a mess and taking steps
> towards solving it will pay off in the long term.
> 
> At the same time, we should not fool ourselves into thinking it will
> take less than *years* before applications such as virt-manager can
> actually take advantage of the new devices without compromising their
> support for old libvirt and QEMU versions too much.
> 
> So if we're doing this to rectify some questionable design choices
> with the goal of having a better situation in the long run, then by
> all means we should go ahead; but if we think this will allow us to
> run RHEL 6 on q35 in the short term, then our efforts are probably
> misguided.

Good point.  You might be right about oVirt and OpenStack, but
I'm assuming at least some applications (maybe KubeVirt?) don't
care about supporting old libvirt/QEMU versions and won't have
that problem.

-- 
Eduardo