Certain ARM machine types don't support ACPI. Given our historically broken design of using '<acpi/>' without attribute to enable ACPI and qemu's default of enabling it without '-no-acpi' such configurations would not work. Now when qemu reports whether given machine type supports ACPI we can do a better decision and un-break those configs. Unfortunately not retroactively. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/297 --- src/qemu/qemu_command.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index cb21765509..7b80490b77 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -6787,6 +6787,7 @@ qemuBuildMachineACPI(virBuffer *machineOptsBuf, virQEMUCaps *qemuCaps) { virTristateSwitch defACPI = def->features[VIR_DOMAIN_FEATURE_ACPI]; + virTristateBool machineACPI = virQEMUCapsMachineSupportsACPI(qemuCaps, def->virtType, def->os.machine); /* QEMU_CAPS_MACHINE_ACPI indicates that '-machine acpi=' syntax should be * used. Presence of QEMU_CAPS_MACHINE_ACPI masks out QEMU_CAPS_NO_ACPI and @@ -6801,9 +6802,17 @@ qemuBuildMachineACPI(virBuffer *machineOptsBuf, * The default in qemu was historically to enable ACPI and '-no-acpi' was * used to disable it when the '<acpi/>' flag is not present. * - * We thus convert VIR_TRISTATE_SWITCH_ABSENT to VIR_TRISTATE_SWITCH_OFF. + * VIR_TRISTATE_SWITCH_ABSENT can't be converted to VIR_TRISTATE_SWITCH_OFF + * blindy as there are machine types on certain platforms which do not + * support ACPI, but others do. Thus the presence of QEMU_CAPS_MACHINE_ACPI + * capability does not fully cover the above. + * + * We thus avoid conversion of VIR_TRISTATE_SWITCH_ABSENT to + * VIR_TRISTATE_SWITCH_OFF if we are certain that given machine does not + * support ACPI. */ - if (defACPI == VIR_TRISTATE_SWITCH_ABSENT) + if (machineACPI != VIR_TRISTATE_BOOL_NO && + defACPI == VIR_TRISTATE_SWITCH_ABSENT) defACPI = VIR_TRISTATE_SWITCH_OFF; if (defACPI != VIR_TRISTATE_SWITCH_ABSENT) -- 2.39.2
