From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Andrew Jones <drjones@redhat.com>,
Juan Quintela <quintela@redhat.com>,
qemu-devel@nongnu.org,
Aaron Lindsay <aaron@os.amperecomputing.com>,
qemu-arm <qemu-arm@nongnu.org>
Subject: Re: ARM Snapshots Not Backwards-Compatible
Date: Wed, 3 Feb 2021 10:27:58 +0000 [thread overview]
Message-ID: <20210203102758.GC2950@work-vm> (raw)
In-Reply-To: <153e5c54-f8bf-d088-502d-502309f5d2a6@redhat.com>
* Philippe Mathieu-Daudé (philmd@redhat.com) wrote:
> Cc'ing migration team and qemu-arm@ list.
I'll have to leave the detail of that to the ARM peole; but from a
migration point of view I think we do want the 64 bit ARM migrations to
be stable now. Please tie incompatible changes to machine types.
Dave
> On 2/3/21 5:01 AM, Aaron Lindsay 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.
> >
> > However, I've run into several issues I thought I should report. The
> > first of them was that this commit changed the address of CBAR, which
> > resulted in a mismatch of the register IDs in `cpu_post_load` in
> > target/arm/machine.c:
> > https://patchwork.kernel.org/project/qemu-devel/patch/20190927144249.29999-2-peter.maydell@linaro.org/
> >
> > The second was that several system registers have changed which bits are
> > allowed to be written in different circumstances, seemingly as a result
> > of a combination of bugfixes and implementation of additional behavior.
> > These hit errors detected in `write_list_to_cpustate` in
> > target/arm/helper.c.
> >
> > 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!
> >
> > My guess, given the numerous issues and the additional complexity
> > required to properly implement backwards-compatible snapshotting, is
> > that this is not a primary goal. However, if it is a goal, what steps
> > can/should we take to support it more thoroughly?
> >
> > Thanks!
> >
> > -Aaron
> >
> > p.s. Now for an admission: the snapshots I'm testing with were
> > originally taken with `-cpu max`. This was unintentional, and I
> > understand if the response is that I can't expect `-cpu max` checkpoints
> > to work across QEMU versions... but I also don't think that all of these
> > issues can be blamed on that (notably CBAR and env->features).
> >
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2021-02-03 10:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 4:01 ARM Snapshots Not Backwards-Compatible Aaron Lindsay
2021-02-03 8:21 ` Philippe Mathieu-Daudé
2021-02-03 10:27 ` Dr. David Alan Gilbert [this message]
2021-02-03 10:38 ` Peter Maydell
2021-02-03 10:49 ` Dr. David Alan Gilbert
2021-02-03 10:52 ` Peter Maydell
2021-02-03 10:59 ` Dr. David Alan Gilbert
2021-02-03 16:04 ` Philippe Mathieu-Daudé
2021-02-03 12:44 ` Andrew Jones
2021-02-03 15:45 ` aaron--- via
2021-02-03 15:45 ` aaron--- via
2021-02-03 15:53 ` Andrew Jones
2021-02-03 10:01 ` Peter Maydell
2021-02-03 14:58 ` Aaron Lindsay
2021-02-03 15:02 ` Philippe Mathieu-Daudé
2021-02-03 15:10 ` Dr. David Alan Gilbert
2021-02-03 15:26 ` Peter Maydell
2021-02-03 15:54 ` Aaron Lindsay
2021-02-03 16:13 ` [PATCH] target/arm: Don't migrate CPUARMState.features Aaron Lindsay
2021-02-03 16:24 ` Philippe Mathieu-Daudé
2021-02-03 20:06 ` Andrew Jones
2021-02-08 13:11 ` Peter Maydell
2021-02-03 15:42 ` ARM Snapshots Not Backwards-Compatible aaron--- via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210203102758.GC2950@work-vm \
--to=dgilbert@redhat.com \
--cc=aaron@os.amperecomputing.com \
--cc=drjones@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.