From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60906) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4egd-0001nJ-DY for qemu-devel@nongnu.org; Wed, 09 Nov 2016 21:01:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4egc-00008V-6c for qemu-devel@nongnu.org; Wed, 09 Nov 2016 21:01:55 -0500 Date: Thu, 10 Nov 2016 12:59:37 +1100 From: David Gibson Message-ID: <20161110015937.GD18060@umbus.fritz.box> References: <1477825928-10803-1-git-send-email-david@gibson.dropbear.id.au> <1477825928-10803-13-git-send-email-david@gibson.dropbear.id.au> <761e90db-fce0-1533-d5db-e97d188bb949@ozlabs.ru> <20161108051950.GT28688@umbus.fritz.box> <22849a41-ef7c-636a-85ac-a445b04eed68@ozlabs.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs" Content-Disposition: inline In-Reply-To: <22849a41-ef7c-636a-85ac-a445b04eed68@ozlabs.ru> Subject: Re: [Qemu-devel] [RFC 12/17] ppc: Migrate compatibility mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: nikunj@linux.vnet.ibm.com, mdroth@linux.vnet.ibm.com, thuth@redhat.com, lvivier@redhat.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org --eheScQNz3K90DVRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 08, 2016 at 04:51:10PM +1100, Alexey Kardashevskiy wrote: > On 08/11/16 16:19, David Gibson wrote: > > On Fri, Nov 04, 2016 at 04:58:47PM +1100, Alexey Kardashevskiy wrote: > >> On 30/10/16 22:12, David Gibson wrote: > >>> Server-class POWER CPUs can be put into several compatibility modes. = These > >>> can be specified on the command line, or negotiated by the guest duri= ng > >>> boot. > >>> > >>> Currently we don't migrate the compatibility mode, which means after a > >>> migration the guest will revert to running with whatever compatibility > >>> mode (or none) specified on the command line. > >>> > >>> With the limited range of CPUs currently used, this doesn't usually c= ause > >>> a problem, but it could. Fix this by adding the compatibility mode (= if > >>> set) to the migration stream. > >>> > >>> Signed-off-by: David Gibson > >>> --- > >>> target-ppc/machine.c | 34 ++++++++++++++++++++++++++++++++++ > >>> 1 file changed, 34 insertions(+) > >>> > >>> diff --git a/target-ppc/machine.c b/target-ppc/machine.c > >>> index 4820f22..5d87ff6 100644 > >>> --- a/target-ppc/machine.c > >>> +++ b/target-ppc/machine.c > >>> @@ -9,6 +9,7 @@ > >>> #include "mmu-hash64.h" > >>> #include "migration/cpu.h" > >>> #include "exec/exec-all.h" > >>> +#include "qapi/error.h" > >>> =20 > >>> static int cpu_load_old(QEMUFile *f, void *opaque, int version_id) > >>> { > >>> @@ -176,6 +177,20 @@ static int cpu_post_load(void *opaque, int versi= on_id) > >>> * software has to take care of running QEMU in a compatible mod= e. > >>> */ > >>> env->spr[SPR_PVR] =3D env->spr_cb[SPR_PVR].default_value; > >>> + > >>> +#if defined(TARGET_PPC64) > >>> + if (cpu->compat_pvr) { > >>> + Error *local_err =3D NULL; > >>> + > >>> + ppc_set_compat(cpu, cpu->compat_pvr, &local_err); > >>> + if (local_err) { > >>> + error_report_err(local_err); > >>> + error_free(local_err); > >>> + return -1; > >>> + } > >>> + } > >>> +#endif > >>> + > >>> env->lr =3D env->spr[SPR_LR]; > >>> env->ctr =3D env->spr[SPR_CTR]; > >>> cpu_write_xer(env, env->spr[SPR_XER]); > >>> @@ -528,6 +543,24 @@ static const VMStateDescription vmstate_tlbmas = =3D { > >>> } > >>> }; > >>> =20 > >>> +static bool compat_needed(void *opaque) > >>> +{ > >>> + PowerPCCPU *cpu =3D opaque; > >>> + > >>> + return cpu->compat_pvr !=3D 0; > >> > >> > >> Finally got to trying how this affects migration :) > >> > >> This breaks migration to QEMU <=3D2.7, and it should not at least when= both > >> source and destination are running with -cpu host,compat=3Dpower7. > >=20 > > IIUC, we don't generally try to maintain backwards migration, even for > > old machine types. >=20 >=20 > I thought the opposite - we generally try to maintain it, this is pretty > much why we use these subsections in cases like this; otherwise you could > just add a new field and bump the vmstate_ppc_cpu.version. Hm, I guess that's true. We do at least try to allow backwards migration, we just don't insist on it. The example here partially suceeds - it will allow backwards migration for CPUs in raw mode. I'll look at just bumping the version instead. >=20 >=20 > >=20 > >> > >> > >>> +} > >>> + > >>> +static const VMStateDescription vmstate_compat =3D { > >>> + .name =3D "cpu/compat", > >>> + .version_id =3D 1, > >>> + .minimum_version_id =3D 1, > >>> + .needed =3D compat_needed, > >>> + .fields =3D (VMStateField[]) { > >>> + VMSTATE_UINT32(compat_pvr, PowerPCCPU), > >>> + VMSTATE_END_OF_LIST() > >>> + } > >>> +}; > >>> + > >>> const VMStateDescription vmstate_ppc_cpu =3D { > >>> .name =3D "cpu", > >>> .version_id =3D 5, > >>> @@ -580,6 +613,7 @@ const VMStateDescription vmstate_ppc_cpu =3D { > >>> &vmstate_tlb6xx, > >>> &vmstate_tlbemb, > >>> &vmstate_tlbmas, > >>> + &vmstate_compat, > >>> NULL > >>> } > >>> }; > >>> > >> > >> > >=20 >=20 >=20 --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --eheScQNz3K90DVRs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYI9SGAAoJEGw4ysog2bOSF0kP/iJJERxb4OnNefTztOLaE1fi YIVRpwSNaV8cykKQLGwjTMN+QGzQu6leJJykUMrTAsrlGF59RwDYl40aJFhHH9ud ZxhX9gEz55ASoCvXTKjUcyq31wOLWhaYge5hUfLh+RO6+1MVY4g6puVLvanWI056 cAg1xnRe6LPjIkt/Ug8mRVIgacfTo8RFo1xK+QteEl0lc4Tra1LJ4Cm2xqiCr2J8 R2bvQ/tTRziNhWB7A1Av2zYC4cML7o73TslhWSXtr7+B0XLnm1tvPeoDBAZZezv6 3xzkGFzGrIgmDbPZWqq+YZrLavRD7e3fOxFcg3k7c/seQDULAbliy7kHHhcYzAJ/ hQGnsqZH0ZUQCBn8wqWlpLbwhqLA8S7pmdpyXnOWaXP529UdmB7ulBjHL2waF1x6 e1ZIymIirrpt0r0oFWnj8mmy4bkfeIxCsKF66vV1tl/XmHGRzQXQ8qh907npmfI8 Kv5kiCdxj1LL2fvO+zefF6jZe5LNbjaCqn4b4utLF9p9JsZuFvESJzGx11BbXTAl YinlPNukNCCo5hMFACsptu3CAjqEpsUDNuFlzgEvH8AuMz+Mx/zAf7To9/nNnVXX d50pWhJzVu4qErT1OX7v0QdQtXe6iuOOhothy81WZ8kwNWII+JdIccCq3qfCh5/S N9PWSQCg1C8nwT55UjlM =v6/H -----END PGP SIGNATURE----- --eheScQNz3K90DVRs--