On Tue, Feb 07, 2023 at 11:23:53AM +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? > > > > -no-acpi rather seems a x86-specific hack for the ISA PC machine, and > > has a high maintenance cost / burden. > > Can you elaborate on this? RISCV doesn't need '-no-acpi' specifically. > If -no-acpi is problematic for some reason, then something like > '-machine virt,acpi=off' would be sufficient for switching to DT too.
I would greatly prefer it if the command line interface could be kept consistent across architectures. It looks like i440fx and q35 both have an 'acpi' machine property. Is -no-acpi just sugar for acpi=off? Is it considered desirable to get rid of -no-acpi? If so, we should follow the usual deprecation process and get rid of it after libvirt has had a chance to adapt. In the scenario described above, it would make sense for RISC-V to only offer the machine type option (assuming that -no-acpi doesn't come for free with that) instead of putting additional effort into implementing an interface that is already on its way out. -- Andrea Bolognani / Red Hat / Virtualization
