[libvirt] [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version

[Peter Maydell]

On 15 February 2016 at 15:08, Markus Armbruster <armbru at redhat.com> wrote:
> Peter Xu <peterx at redhat.com> writes:
>> On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote:
>>> Peter Xu <peterx at redhat.com> writes:
>>> Adding ad hoc queries as we go won't scale.  Is there really no generic
>>> way to get this information, e.g. with qom-get?
>>
>> Haven't used "qom-get" before, but it seems to fetch one property
>> for a specific object. If so, will it be strange to hide some
>> capability bits into every GIC objects (though there is possibly
>> one object)?
>
> Pardon my ignorance...  what are these "GIC objects"?
>
> What exactly is the "GIC type", and how would the result of
> query-gic-capability be used?

The GIC type (for our purposes) is the revision of the interrupt
controller supported by the host, which comes in two versions
(v2 and v3). These are not compatible, unless your host has
the v3-with-v2-compat flavour. If a host is v3-only, it is not
possible for it to give the guest a v2 virtual interrupt
controller; if v2, it can't give the guest a v3 virtual interrupt
controller. (If you ask QEMU to do this via command line options
we will report an error at startup.)

The underlying aim is to allow libvirt to say "this VM config
won't work on this host", rather than ploughing blindly on
and creating a VM config that always errors on startup.

The "GIC object" presumably is the GIC QOM device object.
However we do the "does this host support this GIC version?"
check in QEMU before we ever create the GIC device object,
so trying to probe it for properties isn't going to work.

The only other QOM object potentially available to probe would be
the machine (board) object. However as I understand it libvirt
does all its probing with the "none" machine type, and it seems
a bit odd to put a bunch of properties on the "none" machine
type. It would be possible though I guess.

thanks
-- PMM