On Tue, Feb 2, 2016 at 4:52 PM, Eric Blake <eblake(a)redhat.com> 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