On Tue, Feb 07, 2023 at 06:38:15AM -0800, Andrea Bolognani wrote:
> On Tue, Feb 07, 2023 at 03:02:19PM +0100, Thomas Huth wrote:
> > On 07/02/2023 14.56, Andrea Bolognani wrote:
> > > 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.
>
> Well, it looks like -no-acpi will come for free after all, thanks to
> the code you pasted above, as long as the machine property follows
> the convention established by x86, arm and (I just noticed this one)
> loongarch.
Not quite, because we also have
$ grep -A1 '"no-acpi"' qemu-options.hx
DEF("no-acpi", 0, QEMU_OPTION_no_acpi,
"-no-acpi disable ACPI\n", QEMU_ARCH_I386 | QEMU_ARCH_ARM)
So that means neither riscv nor loongarch get -no-acpi just by adding
the "acpi" machine property.
If the plan is to deprecate -no-acpi, then riscv can be like loongarch
and only have the "acpi" property from the start.
Thanks,
drew
