[libvirt] [PATCHv5 00/13] qemu: allow disabling certain virtio revisions

Peter Krempa pkrempa at redhat.com
Wed Sep 7 15:10:01 UTC 2016


On Wed, Aug 24, 2016 at 00:20:42 +0200, Ján Tomko wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1227354
> v1: https://www.redhat.com/archives/libvir-list/2016-July/msg01235.html
> v2: https://www.redhat.com/archives/libvir-list/2016-August/msg00412.html
>   * probe for the qemu capability
>   * add the attribute to virtio1-only devices such as virtio-gpu
>     and virtio-input devices
>   * allow multiple revisions to be specified
> 
> v3:
>   * touch up documentation
>   * rename the capability from "virtio-revision" to "virtio-disable-legacy"
>   * move the formatting in qemuBuildNicDevStr after the address
>     and only do it for virtio
>   * get rid of novelty enum names
> 
> v4:
>   * only probe the capability for PCI devices
> 
> v5:
>   * instead of a separate element, use one attribute under the driver
>     element

So as usual the qemu documentation for this is rather sparse, but from
skimming through the qemu commits and the bugzilla I've got the
following feeling:

I'm basically wondering whether it's worth to expose this to be
controlled manually or we can have good enough chance to try to controll
it according to other settings and then infer the required mode.
(basically what Daniel said in the comment in bugzilla).

The "--disable-modern" flag is basically considered just as a safeguard
if qemu would be buggy, but I'm not really a fan of such workaround.
Since the "modern" approach is supposed to be compatible I don't quite
see a big need to use it.

The "--disable-legacy" part is more important feature, as it allows to
assign more devices on a PCIe bus (as the IO region is not necessary)
but the legacy mode is required for legacy guests and/or if booting from
such device is necessary (?).

This design basically requires the users to do the correct decision,
which was also the reason why I asked for more docs.

In this current version I'm also missing any form of safeguards that an
invalid configuration won't be accepted. Currently we'd allow to specify
it for a emulated device as well as virio.

Obviously making the user responsible for correct setting is much
easier.

Sigh. It'd be great if somebody else could also state their opinion on
this. I can't say that I'm a big fan of this approach but it looks like
as if it would be the only sensible one.

Peter




More information about the libvir-list mailing list