qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrea Bolognani
Subject: Re: [Qemu-devel] [PATCH] virtio: Provide version-specific variants of virtio PCI devices
Date: Wed, 17 Oct 2018 12:43:02 +0200

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

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.

[...]
> > 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.

-- 
Andrea Bolognani / Red Hat / Virtualization




reply via email to

[Prev in Thread] Current Thread [Next in Thread]