On Mon, Jan 22, 2024 at 12:17:24AM +0100, Philippe Mathieu-Daudé wrote:
> > @@ -560,7 +569,7 @@ static const VMStateDescription
> > vmstate_designware_pcie_viewport = {
> > .fields = (const VMStateField[]) {
> > VMSTATE_UINT64(base, DesignwarePCIEViewport),
> > VMSTATE_UINT64(target, DesignwarePCIEViewport),
> > - VMSTATE_UINT32(limit, DesignwarePCIEViewport),
> > + VMSTATE_UINT64(limit, DesignwarePCIEViewport),
>
> Unfortunately this breaks the migration stream. I'm not sure
> what is the best way to deal with it (Cc'ing migration
> maintainers).
My understanding is that we can have at least two ways to do this, one
relying on machine type properties, the other one can be VMSD versioning.
Frankly I don't have a solid mind either on which is the best approach.
I never had a talk with either Juan / Dave before on this, but my
understanding is that VMSD versioning is just less-flexible, because it
doesn't support backward migrations (only forward). While machine-type
property based solution can support both (forward + backward).
I decided to draft a doc update for this, to put my thoughts here:
https://lore.kernel.org/qemu-devel/20240122070600.16681-1-pet...@redhat.com
It can be seen as a reference, or review comments also welcomed.
This device seems to be only supported by CONFIG_FSL_IMX7. Maybe vmsd
versioning would be good enough here, then? If so, instead of
VMSTATE_UINT64(), we may want a new VMSTATE_UINT32_V() with a boosted
version.
Thanks,
--
Peter Xu
