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

Peter Maydell <peter.maydell(a)linaro.org&gt; writes: > On 15 February 2016 at 20:18, Andrew Jones <drjones(a)redhat.com&gt; wrote: >> On Mon, Feb 15, 2016 at 08:40:54PM +0100, Markus Armbruster wrote: >>> How would the command line look like? >>> >> >> Here is what is available today >> >> # select gicv2 (this work with and without KVM) >> qemu-system-aarch64 -M virt # v2 is the default >> qemu-system-aarch64 -M virt,gic-version=2 ... >> >> # select gicv3 (only works with KVM) >> qemu-system-aarch64 -M virt,gic-version=3 ... > > This will work with TCG once we get the GICv3 emulation upstream. > >> # select whatever the host has >> qemu-system-aarch64 -M virt,gic-version=host ... > > This only works with KVM (like -cpu host). Aha, it's a machine option. Therefore, the generic direct solution would be command line introspection. A couple of remarks. We don't have comprehensive command line introspection. There's only query-command-line-options, but it's incomplete and insufficiently expressive. We usually sidestep command line introspection and introspect the corresponding QMP command, or we "look for a witness" in QMP, i.e. some introspectible indicator for the non-introspectible feature we need to know. The is no QMP command corresponding to --machine. There's a long term vision to start QEMU with a blank slate, then configure everything via QMP. With that, QMP introspection would cover machine options. Of course, visions aren't going to help you now. Even if there was a QMP command, the way we do --machine options would defeat QMP introspection: they're QOM properties, defined in code. Defining things in code is the most flexible solution, but it makes reasoning about them *much* harder: the only general way to learn what code does is run it. This is fundamentally incompatible with introspection. In other words, QOM's design sacrifices introspectability for flexibility. The flexibility isn't actually needed most of the time, but it defeats introspection all of the time. For me, this was an design mistake. We made the same mistake before, with migration. I figure we'll need to crack the QOM introspection problem to at least some useful degree. But it's going to be a lot of work. A less flexible, introspectible, data-driven interface could be layered on top of the code-driven one. With as many users as possible converted to the data-driven interface, the flexibility then defeats introspection only where we actually use the flexibility. Back to GIV. Recognized values of gic-version are fixed at compile time: 2, 3, host. Once again, QOM does things in code rather than data: the set of values is defined in the setter function virt_set_gic_version(). Some values are accepted only together with other configuration: 3 requires accel=kvm (for now), host requires -cpu host. Static introspection can't show such constraints. Would the proposed query-gic-capability show them? How?