On 29/05/14 16:38, Peter Maydell wrote: > On 29 May 2014 15:29, James Hogan <james.ho...@imgtec.com> wrote: >> On 29/05/14 14:26, Peter Maydell wrote: >>> On 29 May 2014 14:22, James Hogan <james.ho...@imgtec.com> wrote: >>>> loadvm/migration will write Config3, possibly with a different value if >>>> the snapshot being loaded is an older one without userlocal support. >>> >>> Migration load always happens with a freshly reset system, >>> so this isn't a problem. >> >> Why does that make a difference? The snapshot may have been saved on a >> slightly different version without that bit set (if that isn't supported >> then we may as well not bother trying to support loading different >> snapshot versions). > > A key requirement of migration or vm restore is that the > machine configuration (including all command line parameters) > must be exactly identical at both ends. (We don't attempt to > catch this user error, which typically results in weird stuff > happening or in a migration failure with an obscure message). > So you'll never get a migration from a bit-set config to a > bit-cleared config. Note that this is different from a cross > version migration, which would be "from QEMU 2.0 with config-X > to QEMU 2.1 with config-X".
Presumably we want to be able to add the bit to Config3 in existing machines in target-mips/translate_init.c at some point though to take advantage of the extra performance (e.g. in v2.1), in which case you could get a migration between bit-clear and bit-set... > >> Also loadvm can happen at any time, not just after >> reset. > > The "loadvm" monitor command is implemented as "first reset; > then load state". Okay cool. It's fine then as long as there are no old translations lying around and the Config3 etc are migrated unchanged from the snapshot. Thanks James
