Am 05.04.22 um 21:06 schrieb Dr. David Alan Gilbert (git):
> From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
>
> The 'acpi_index' field is a statically configured field, which for
> some reason is migrated; this never makes much sense because it's
> command line static.
>
> However, on piix4 it's conditional, and the condition/test function
> ends up having the wrong pointer passed to it (it gets a PIIX4PMState
> not the AcpiPciHpState it was expecting, because VMSTATE_PCI_HOTPLUG
> is a macro and not another struct). This means the field is randomly
> loaded/saved based on a random pointer. In 6.x this random pointer
> randomly seems to get 0 for everyone (!); in 7.0rc it's getting junk
> and trying to load a field that the source didn't send. The migration
> stream gets out of line and hits the section footer.
>
> The bodge is on piix4 never to load the field:
> a) Most 6.x builds never send it, so most of the time the migration
> will work.
> b) We can backport this fix to 6.x to remove the boobytrap.
> c) It should never have made a difference anyway since the acpi-index
> is command line configured and should be correct on the destination
> anyway
> d) ich9 is still sending/receiving this (unconditionally all the time)
> but due to (c) should never notice. We could follow up to make it
> skip.
>
> It worries me just when (a) actually happens.
>
> Fixes: b32bd76 ("pci: introduce acpi-index property for PCI device")
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/932
>
> Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> ---
> hw/acpi/acpi-pci-hotplug-stub.c | 4 ----
> hw/acpi/pcihp.c | 6 ------
> hw/acpi/piix4.c | 11 ++++++++++-
> include/hw/acpi/pcihp.h | 2 --
> 4 files changed, 10 insertions(+), 13 deletions(-)
>
Fixes the issue for me, thanks!
Tested-by: Fabian Ebner <f.eb...@proxmox.com>
