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

[Daniel P. Berrange]

On Wed, Sep 07, 2016 at 05:10:01PM +0200, Peter Krempa wrote:
> 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.

I tend to agree. I'd be incredibly happy if we didn't add any of this to
the XML and would simply "do the best thing" automatically.

I'm particularly not a fan of adding something "just in case there is a
bug"

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|