Re: [PATCH v2] acpi: fix acpi_index migration

["Michael S. Tsirkin" <mst@redhat.com>]

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 <dgilbert@redhat.com> wrote:
> >
> > * Igor Mammedov (imammedo@redhat.com) wrote:
> > > From: "Dr. David Alan Gilbert" <dgilbert@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 <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>
> 
> 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 <mst@redhat.com>

-- 
MST