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

[Andrea Bolognani]

On Mon, Feb 27, 2023 at 04:27:37PM +0100, Peter Krempa wrote:
> Detect that ACPI can be controlled via '-machine acpi=off' rather than
> use of -no-acpi.

First of all, thank you for picking up this work. I was planning on
doing this myself, but you've beaten me to it and I'm absolutely
ecstatic about that :)

> +++ b/src/qemu/qemu_capabilities.c
>  static struct virQEMUCapsCommandLineProps virQEMUCapsCommandLine[] = {
> +    { "acpi", NULL, QEMU_CAPS_MACHINE_ACPI },
>      { "fsdev", "multidevs", QEMU_CAPS_FSDEV_MULTIDEVS },
>      { "machine", "hpet", QEMU_CAPS_MACHINE_HPET },
>      { "sandbox", NULL, QEMU_CAPS_SECCOMP_SANDBOX },
>
> +++ b/tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml
>    <flag name='virtio-blk.queue-size'/>
>    <flag name='usb-host.guest-resets-all'/>
>    <flag name='virtio-crypto'/>
> +  <flag name='machine-acpi'/>

Are you sure you're detecting this correctly? Based on an earlier
discussion about this topic[1], I would have expected the flag to
show up for QEMU 5.0.0, but *not* for QEMU 4.2.0.

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?

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 :)


[1] https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg02217.html
-- 
Andrea Bolognani / Red Hat / Virtualization