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