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: Bernhard Beschow
Subject: Re: [PATCH 02/10] hw/riscv/virt: Add a switch to enable/disable ACPI
Date: Mon, 06 Feb 2023 23:14:23 +0000


Am 6. Februar 2023 11:18:06 UTC schrieb "Philippe Mathieu-Daudé" 
<philmd@linaro.org>:
>On 6/2/23 11:54, Andrea Bolognani wrote:
>> On Thu, Feb 02, 2023 at 10:22:15AM +0530, Sunil V L wrote:
>>> +    object_class_property_add(oc, "acpi", "OnOffAuto",
>>> +                              virt_get_acpi, virt_set_acpi,
>>> +                              NULL, NULL);
>>> +    object_class_property_set_description(oc, "acpi",
>>> +                                          "Enable ACPI");
>> 
>> The way this works on other architectures (x86_64, aarch64) is that
>> you get ACPI by default and can use -no-acpi to disable it if
>> desired. Can we have the same on RISC-V, for consistency?
>
>-no-acpi rather seems a x86-specific hack for the ISA PC machine,

... for the i440FX/PIIX machine, to be precise. There it controls the presence 
of the PIIX ACPI controller and surely also the generation of ACPI tables. ACPI 
wasn't a thing in pure ISA times, so the switch doesn't make much sense for the 
ISA machine.

Here, for RISC-V, the "acpi" switch seems to just control the generation of 
ACPI tables which has quite different semantics than -no-acpi.

>and
>has a high maintenance cost / burden.
>
>If hardware provides ACPI support, QEMU should expose it to the guest.

Yes, I fully agree with both points.

>
>Actually, what is the value added by '-no-acpi'?

IIUC, it allows the PC machine to emulate a PCI PC without an ACPI bios. 
Unfortunately, it also omits the instantiation of the... erm... Frankenstein 
PIIX4_ACPI device which seems quite unnecessary to achieve that goal. Just 
always instantiating it seems much simpler.



reply via email to

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