Am 6. Februar 2023 11:18:06 UTC schrieb "Philippe Mathieu-Daudé"
<phi...@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.
