]> git.ipfire.org Git - thirdparty/qemu.git/commit
acpi: fix acpi_index migration
authorDr. David Alan Gilbert <dgilbert@redhat.com>
Wed, 6 Apr 2022 18:58:12 +0000 (14:58 -0400)
committerPeter Maydell <peter.maydell@linaro.org>
Wed, 6 Apr 2022 19:03:26 +0000 (20:03 +0100)
commita83c2844903c45aa7d32cdd17305f23ce2c56ab9
tree9eea3924e2fe01b6973cdb443a64aee8ae3011b1
parentf53faa70bb63cc0c8e2fd0752b7ad2c8a79616ba
acpi: fix acpi_index migration

vmstate_acpi_pcihp_use_acpi_index() was expecting AcpiPciHpState
as state but it actually received PIIX4PMState, because
VMSTATE_PCI_HOTPLUG is a macro and not another struct.
So it ended up accessing random pointer, which resulted
in 'false' return value and acpi_index field wasn't ever
sent.

However in 7.0 that pointer de-references to value > 0, and
destination QEMU starts to expect the field which isn't
sent in migratioon stream from older QEMU (6.2 and older).
As result migration fails with:
  qemu-system-x86_64: Missing section footer for 0000:00:01.3/piix4_pm
  qemu-system-x86_64: load of migration failed: Invalid argument

In addition with QEMU-6.2, destination due to not expected
state, also never expects the acpi_index field in migration
stream.

Q35 is not affected as it always sends/expects the field as
long as acpi based PCI hotplug is enabled.

Fix issue by introducing compat knob to never send/expect
acpi_index in migration stream for 6.2 and older PC machine
types and always send it for 7.0 and newer PC machine types.

Diagnosed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Fixes: b32bd76 ("pci: introduce acpi-index property for PCI device")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/932
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
hw/acpi/acpi-pci-hotplug-stub.c
hw/acpi/pcihp.c
hw/acpi/piix4.c
hw/core/machine.c
include/hw/acpi/pcihp.h