Re: ARM Snapshots Not Backwards-Compatible

[Peter Maydell]

On Wed, 3 Feb 2021 at 04:01, Aaron Lindsay <aaron@os.amperecomputing.com> wrote:
>
> Hello,
>
> I'm attempting to restore an AArch64 snapshot taken on QEMU 4.1.0 on
> QEMU 5.2.0, using system mode. My previous impression, possibly from
> https://wiki.qemu.org/Features/Migration/Troubleshooting#Basics was that
> this ought to work:
>
> > Note that QEMU supports migrating forward between QEMU versions
>
> Note that I'm using qemu-system-aarch64 with -loadvm.

You don't say what machine type and command line you're using. Strictly,
Strictly speaking, the intended guarantee only covers versioned
machines, eg "virt-4.1" on QEMU 4.1 to "virt-4.1" on QEMU 5.2.

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

thanks
-- PMM