|
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"); break;
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.
Thomas
[Prev in Thread] | Current Thread | [Next in Thread] |