query-command-line-options (was: [PATCH 1/7] qemu: capabilities: Introduce QEMU_CAPS_MACHINE_ACPI)

[Markus Armbruster]

[Resent with cc: qemu-devel and adjusted subject, sorry for the noise]

abologna at redhat.com (Andrea Bolognani) writes:

> On Mon, Feb 27, 2023 at 06:25:23PM +0100, Peter Krempa wrote:
>> On Mon, Feb 27, 2023 at 08:44:57 -0800, Andrea Bolognani wrote:
>> > This looks like you're checking whether -acpi itself exists as a
>> > top-level option. Which it doesn't, but -no-acpi does and yet it
>> > doesn't seem to be advertised in the output of
>> > query-command-line-options?
>>
>> Well, it actually does exist in the output of
>> query-command-line-options, but I have no idea what it means:
>>
>> virsh qemu-monitor-command --pretty cd query-command-line-options | jq 
>> .return[].option
>>
>> One of the options is "acpi".
>
> Right, I've seen that. What I wanted to say if that passing it to
> QEMU results in an error:
>
>   $ qemu-system-x86_64 -acpi
>   qemu-system-x86_64: -acpi: invalid option
>
> So it's not really an option, despite being advertised as such. And
> on the opposite end of the spectrum we have -no-acpi, which *does*
> work when passed to QEMU but is nowhere to be found in the JSON
> document returned by query-command-line-options.
>
>> > Basically it looks like there are some serious introspection
>> > shenanigans going on, and I'm not sure we can actually reliably
>> > detect whether -machine acpi can be used until your QEMU patch has
>> > been merged.
>> >
>> > Or I might just have missed something obvious! In which case, please
>> > let me know what it is :)
>>
>> I have no idea what the 'acpi' option does but it certainly mislead me.
>
> I'm not entirely sure, but I think it might be connected to this
> bit of code in vl.c:
>
>   case QEMU_OPTION_acpitable:
>       opts = qemu_opts_parse_noisily(qemu_find_opts("acpi"),
>                                      optarg, true);
>
> This is the handling for the -acpitable option, but notice how "acpi"
> is mentioned as well, to perform some sort of lookup. I think this
> might be the reason why "acpi" gets included in the JSON, while
> "acpitable" doesn't.
>
> Another example I've found is "smp-opts", which seems to be used to
> implement the -smp option. Once again, in the JSON we find "smp-opts"
> instead of "smp".
>
> I think it would be worthwile to check with the QEMU developers and
> make sure that they're aware of this behavior. Is it intended? Is it
> documented anywhere? It certainly seems extremely confusing to me.

query-command-line-options has... issues.

First, it's generally[*] limited to options that use QemuOpts.

Second, it reports configuration group names, which are often, but not
always the same as the option name.  The exceptions you just have to
know.  Group name "acpi" vs. option name "acpitable" is one.

Third, information on option parameters can be incomplete, or missing
entirely.

Fourth, even when it's there, it's often insufficiently detailed.

These are design issues.  I believe the command cannot be fixed, only
replaced.

See my talk "QEMU interface introspection: From hacks to
solutions", KVM Forum 2015.
Video at https://www.youtube.com/watch?v=IEa8Ao8_B9o
Slides at 
http://www.linux-kvm.org/images/7/7a/02x05-Aspen-Markus_Armbruster-QEMU_interface_introspection.pdf

Questions?


[*] "Generally", because we hacked in a special case to keep "machine"
in its output when we weaned it off QemuOpts.  QEMU commit 40e07370f21.