Hi Cedric,
> Subject: Re: [PATCH v2 01/18] aspeed/smc: Fix write incorrect data into flash
> in
> user mode
>
> >>
> >> static const VMStateDescription vmstate_aspeed_smc = {
> >> .name = "aspeed.smc",
> >> - .version_id = 2,
> >> + .version_id = 3,
> >> .minimum_version_id = 2,
> >> .fields = (const VMStateField[]) {
> >> VMSTATE_UINT32_ARRAY(regs, AspeedSMCState,
> ASPEED_SMC_R_MAX),
> >> VMSTATE_UINT8(snoop_index, AspeedSMCState),
> >> VMSTATE_UINT8(snoop_dummies, AspeedSMCState),
> >> + VMSTATE_BOOL(unselect, AspeedSMCState),
> >> VMSTATE_END_OF_LIST()
> >> }
> >> };
> >
> > I think this will break migration compatibility. In order to enable at
> > least forward migration, it should be:
> >
> > VMSTATE_BOOL_V(unselect, AspeedSMCState, 3),
>
> This is correct. I will fix the patch.
>
If I need to re-send v3 patch, I will fix it.
Thanks for help.
Jamin
> Some background,
>
> The aspeed machines are fully emulated and the Aspeed SoC models are not
> part of any virt* machines (yet). So migration support is a bit of a theory.
> We
> have done our best to maintain some support, compatibility not being a
> priority. IOW, it's not perfectly tuned as on virt machines.
>
> Also, on ARM, migration of the CPU secure mode (I think this is the reason,
> Peter please correct me !) is not supported and if migration is initiated
> after
> Linux has started, the machine will hang.
>
> However, if one day, an aspeed model becomes part of a virt machine, we
> should be more careful. I would start by resetting all vmstate versions to 1!
>
> Thanks,
>
> C.
>
>
>
> >
> > For allowing backwards migration, too, we should consider making it a
> > subsection instead that allows migration in the default case of an
> > idle device.
> >
> > Kevin
> >
