* Philippe Mathieu-Daudé (phi...@redhat.com) wrote: > 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))
It's interesting that on x86 we've got a longterm request to *add* cpu features to the stream to detect screwups caused by using mismatched CPUs; so it's not necessarily a bad idea to include it once you realise it's there. Dave > > > > -Aaron > > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK