qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 02/10] hw/riscv/virt: Add a switch to enable/disable ACPI


From: Thomas Huth
Subject: Re: [PATCH 02/10] hw/riscv/virt: Add a switch to enable/disable ACPI
Date: Thu, 9 Feb 2023 06:15:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0

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 <kraxel@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 <kraxel@redhat.com>
     Message-Id: <20200320100136.11717-1-kraxel@redhat.com>
     Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
     Acked-by: Paolo Bonzini <pbonzini@redhat.com>
     Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
     Signed-off-by: Michael S. Tsirkin <mst@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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]