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
