On Wed, Apr 06, 2022 at 09:29:02PM +0100, Peter Maydell wrote: > On Wed, 6 Apr 2022 at 19:59, Dr. David Alan Gilbert <dgilb...@redhat.com> > wrote: > > > > * Igor Mammedov (imamm...@redhat.com) wrote: > > > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > > > > > > 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 <dgilb...@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 <imamm...@redhat.com> > > > > Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com> > > Applied to master for rc3, thanks. > > -- PMM
Oh. I had this in my queue with a different commit log. But sure. Feel free to add: Reviewed-by: Michael S. Tsirkin <m...@redhat.com> -- MST