[Top][All Lists]

[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: Thomas Huth
Subject: Re: [PATCH 02/10] hw/riscv/virt: Add a switch to enable/disable ACPI
Date: Tue, 7 Feb 2023 15:02:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0

On 07/02/2023 14.56, Andrea Bolognani wrote:
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?

Yes, it is, see softmmu/vl.c:

            case QEMU_OPTION_no_acpi:
                qdict_put_str(machine_opts_dict, "acpi", "off");

Is it considered desirable to get rid of -no-acpi?

Sounds like a good idea, indeed!

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.

I agree. IMHO the machine parameter should be enough, no need to introduce "-no-acpi" here.


reply via email to

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