Peter Maydell <peter.maydell@xxxxxxxxxx> writes: > 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.) How would the command line look like? I'm asking because the answer will point us to the introspection problem to solve. > 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. Yes, finding out with a suitable introspection interface is easier and more robust than "try and guess what the error message might mean". > 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. QMP introspection would ideally cover introspecting device objects: simply introspect device_add. But it doesn't cover it now, because QMP introspection is really a special case of QAPI schema introspection, and the QAPI schema cannot express device_add for two reasons: 1. The QAPI schema is fixed at compile time, but the device models aren't. Instead, whatever device models are linked into QEMU register themselves during startup. Collecting them at compile time is a solvable problem, but unlikely to be fun. 2. The QAPI schema is data, but general QOM properties are code. As always, code is much harder to work with than data. You can't extract properties from code at compile time, you have to run the code. To introspect QOM properties, you have to instantiate an object, examine it, then destroy it. Aside: this requires instantiate + destroy to have no lasting side effects, and experience tells that device model code gets that wrong easily. Paolo suggested that we special-case device introspection instead of somehow hook it into QMP introsprection. Even if we do that, developing it will take time. It'll always be easier and more expedient to add another ad hoc query instead. But it leaves the generic problem unsolved while the ad hoc queries pile up. > 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list