Re: [PATCH 1/7] qemu: capabilities: Introduce QEMU_CAPS_MACHINE_ACPI

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.