On Tue, Feb 07, 2023 at 08:20:31PM +0100, Andrew Jones wrote: > On Tue, Feb 07, 2023 at 06:38:15AM -0800, Andrea Bolognani wrote: > > Well, it looks like -no-acpi will come for free after all, thanks to > > the code you pasted above, as long as the machine property follows > > the convention established by x86, arm and (I just noticed this one) > > loongarch. > > Not quite, because we also have > > $ grep -A1 '"no-acpi"' qemu-options.hx > DEF("no-acpi", 0, QEMU_OPTION_no_acpi, > "-no-acpi disable ACPI\n", QEMU_ARCH_I386 | QEMU_ARCH_ARM) > > So that means neither riscv nor loongarch get -no-acpi just by adding > the "acpi" machine property. > > If the plan is to deprecate -no-acpi, then riscv can be like loongarch > and only have the "acpi" property from the start.
Makes sense. For the libvirt integration, do I understand correctly that the machine property was added by commit commit 17e89077b7e3bc1d96540e21ddc7451c3e077049 Author: Gerd Hoffmann <kra...@redhat.com> Date: Fri Mar 20 11:01:36 2020 +0100 acpi: add acpi=OnOffAuto machine property to x86 and arm virt Remove the global acpi_enabled bool and replace it with an acpi OnOffAuto machine property. qemu throws an error now if you use -no-acpi while the machine type you are using doesn't support acpi in the first place. Signed-off-by: Gerd Hoffmann <kra...@redhat.com> Message-Id: <20200320100136.11717-1-kra...@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com> Acked-by: Paolo Bonzini <pbonz...@redhat.com> Reviewed-by: Michael S. Tsirkin <m...@redhat.com> Signed-off-by: Michael S. Tsirkin <m...@redhat.com> included in QEMU 5.0? libvirt still officially supports QEMU 4.2, so we'll have to make the use of the machine property conditional. -- Andrea Bolognani / Red Hat / Virtualization