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