On 15 February 2016 at 15:08, Markus Armbruster <armbru@xxxxxxxxxx> wrote: > Peter Xu <peterx@xxxxxxxxxx> writes: >> On Mon, Feb 15, 2016 at 10:52:01AM +0100, Markus Armbruster wrote: >>> Peter Xu <peterx@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list