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

Andrea Bolognani abologna at redhat.com
Mon Feb 27 19:18:46 UTC 2023


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.

-- 
Andrea Bolognani / Red Hat / Virtualization



More information about the libvir-list mailing list