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

[Markus Armbruster]

Peter Maydell <peter.maydell at linaro.org> writes:

> On 15 February 2016 at 20:18, Andrew Jones <drjones at redhat.com> 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?