RE: [PATCH v2 01/18] aspeed/smc: Fix write incorrect data into flash in user mode

[Jamin Lin]

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
> >