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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list