On Mon, Feb 06, 2023 at 01:35:20PM +0100, Andrew Jones wrote: > 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. >
Since all other architectures use Auto instead of a simple bool, I opted for the same to keep it consistent. However, default AUTO looked ambiguous to me. Since we still need to support external interrupt controllers (IMSIC/APLIC/PLIC), I chose to keep it OFF by default for now. Thanks Sunil > > > > -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
