On Mon, Feb 06, 2023 at 12:18:06PM +0100, Philippe Mathieu-Daudé wrote: > 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?
Default on, with a user control to turn off, can be done with a boolean. I'm not sure why/if Auto is needed for acpi. Auto is useful when a configuration doesn't support a default setting for a feature. If the user hasn't explicitly requested the feature to be on or off, then the configuration can silently select what works. If, however, the user explicitly chooses what doesn't work, then qemu will fail with an error instead. > > -no-acpi rather seems a x86-specific hack for the ISA PC machine, and > has a high maintenance cost / burden. > > If hardware provides ACPI support, QEMU should expose it to the guest. > > Actually, what is the value added by '-no-acpi'? IIRC, when booting, at least arm guests, with edk2 and ACPI tables, then edk2 will provide the guest ACPI tables instead of DT. To ensure we can boot with edk2, but still allow the guest to boot with DT, we need a way to disable the generation of ACPI tables. Thanks, drew
