On 08/02/2023 17.48, Andrea Bolognani wrote:
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.
Sounds right, and testing for the machine option should be possible with the
upcoming QEMU 8.0. FWIW, I assume this is similar to the -no-hpet option
which has been turned into a machine property, too:
https://gitlab.com/libvirt/libvirt/-/commit/3c508e7d4310aeb8
Thomas
