On Tue, Feb 2, 2016 at 4:52 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: > On 02/02/2016 07:05 AM, Christoffer Dall wrote: > >>> >>> I'm not familiar enough with libvirt, nor the use of QMP, to really argue >>> one way or another, but I find it a bit strange that we'd prefer libvirt >>> to query two entities over one. And, why should the libvirt installed on >>> a particular host prefer gicv3 as the default, just because KVM supports >>> it, even when QEMU does not? >> >> I think the assumption here is that if you install a recent libvirt you >> also install a recent QEMU. You always have the risk of things not >> working if you have too old a QEMU, right? > > Libvirt exists for providing back-compat glue. The following > combinations are supported: > > old libvirt, old qemu > new libvirt, old qemu > new libvirt, new qemu > > and it is only this combination that might require a libvirt upgrade to > work correctly: > > old libvirt, new qemu > ok, so that would mean we need to implement a QMP command to tell us which gic versions are supported for a given machine. Current possible responses are "2", "3" and "2,3" and we also need to add code to libvirt to try that QMP command, and if it doesn't exist, fall back to not specifying gic-version, using the old-qemu compatible default of providing a gicv2 to guests, and if the QMP command exists, use the newest gic-version. users can then always override this behavior by directly specifying a gic version "host", "2", or "3" in their xml file. any objections? -Christoffer -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list