On 2/3/21 3:58 PM, Aaron Lindsay wrote: > On Feb 03 10:01, Peter Maydell wrote: >>> The third is that meanings of the bits in env->features (as defined by >>> `enum arm_features` in target/arm/cpu.h) has shifted. For example, >>> ARM_FEATURE_PXN, ARM_FEATURE_CRC, ARM_FEATURE_VFP, ARM_FEATURE_VFP3, >>> ARM_FEATURE_VFP4 have all been removed and ARM_FEATURE_V8_1M has been >>> added since 4.1.0. Heck, even I have added a field there in the past. >>> Unfortunately, these additions/removals mean that when env->features is >>> saved on one version and restored on another the bits can mean different >>> things. Notably, the removal of the *VFP features means that a snapshot >>> of a CPU reporting it supports ARM_FEATURE_VFP3 on 4.1.0 thinks it's now >>> ARM_FEATURE_M on 5.2.0! >> >> Ow. I didn't realize the env->features was in the migration state :-( >> There is no reason for it to be, because it's a constant property >> of the CPU. The easy fix is to replace >> VMSTATE_UINT64(env.features, ARMCPU), >> in target/arm/machine.c with whatever the syntax is for "ignore >> 64 bits of data here". Then we'll ignore whatever is coming in >> from the source, which we don't need, and we'll stop sending it >> out if we're the destination. > > I'll look into this.
I think this is: VMSTATE_UNUSED(sizeof(uint64_t)) > > -Aaron >
