From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c6812-0006vg-4X for qemu-devel@nongnu.org; Sun, 13 Nov 2016 22:33:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c680y-0000Ri-Ue for qemu-devel@nongnu.org; Sun, 13 Nov 2016 22:33:04 -0500 Date: Mon, 14 Nov 2016 12:15:16 +1100 From: David Gibson Message-ID: <20161114011516.GA24747@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> <20161110015937.GD18060@umbus.fritz.box> <20161110235536.21247.22235@loki> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20161110235536.21247.22235@loki> Subject: Re: [Qemu-devel] [RFC 12/17] ppc: Migrate compatibility mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: Alexey Kardashevskiy , nikunj@linux.vnet.ibm.com, thuth@redhat.com, lvivier@redhat.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 10, 2016 at 05:55:36PM -0600, Michael Roth wrote: > Quoting David Gibson (2016-11-09 19:59:37) > > 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 wrot= e: > > > >> On 30/10/16 22:12, David Gibson wrote: > > > >>> Server-class POWER CPUs can be put into several compatibility mod= es. These > > > >>> can be specified on the command line, or negotiated by the guest = during > > > >>> boot. > > > >>> > > > >>> Currently we don't migrate the compatibility mode, which means af= ter a > > > >>> migration the guest will revert to running with whatever compatib= ility > > > >>> mode (or none) specified on the command line. > > > >>> > > > >>> With the limited range of CPUs currently used, this doesn't usual= ly cause > > > >>> a problem, but it could. Fix this by adding the compatibility mo= de (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_i= d) > > > >>> { > > > >>> @@ -176,6 +177,20 @@ static int cpu_post_load(void *opaque, int v= ersion_id) > > > >>> * software has to take care of running QEMU in a compatible= mode. > > > >>> */ > > > >>> 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_tlbm= as =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 pre= tty > > > much why we use these subsections in cases like this; otherwise you c= ould > > > just add a new field and bump the vmstate_ppc_cpu.version. > >=20 > > 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. >=20 > What if we changed the condition to cpu->compat_pvr !=3D cpu->max_compat? > Assuming each end sets compat=3DpowerX (which seems like a reasonable > requirement for migration), it seems like in most cases the guest would = end > up negotiating max_compat anyway. It's only in cases where it doesn't tha= t we > end up in an ambiguous state. So, since I've already given up on backwards migration in other cases, I've changed this in my next version to simply (cpu->vhyp !=3D NULL), so the compat mode (including raw) is always transferred on pseries. > Newer QEMU would guard against this by migrating it's compat_pvr > accordingly (which will probably become more important with p9 guests > potentially running older kernels), but otherwise it seems like we could > maintain backwards migration in most cases. >=20 > Although with the proposed version bump for vmstate_spapr_pci I guess > the discussion is somewhat moot unless we decide we rely want to > maintain backward migration... Not enough that it's worth the considerable extra difficulty it entails, I think. >=20 > >=20 > > I'll look at just bumping the version instead. > >=20 > > >=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 > >=20 > >=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 --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYKRAbAAoJEGw4ysog2bOSbXIP/1vB/rRodn4mvCJa6uCb7q9m h+OVq8E1roLHZmuXklzI5VBJzNipNSFyOfrK6OcRB3uRwbp37NVXBjnWUTuabozQ 70k8FKMOT0Vyt82/YYD6oWcIQByS3wCwS4lfoAuduN8+tZNHclifqHNnwvYX1SJx BhVNsrWpjj2jWTeRGLAcaQHdvlZkGMt33a6ZZU0aXZxgEMIJKQjYe3IEXJZ8BlQi 0suUwmJJ0rkhzYu2YveLEU0agu5UyBGyj5VS7Ci8E8jvbHkdraZXYOoFLUYsOU6U TfBHJ/UEWucf41PcrO6MSfErpcBsUp/roOr+QIyIVYk424TEqYMfbF8bXXKwGyc8 c1YeSzmTnV/X9ourGC93pKo4Qvu+f5Um5bmaeWgNx9v5mhmIfpvL/jBYhvOO4b4l 0ZU2Jw86QT8uN4638UkE/DILMTcG/M9h5AxXYAR6QyIUFAd+egfefm6LOvgdACfQ /wuZD69/zH8zpLEaCLRoIJiT2ZCLNx82Pnc9j53Hua+LL4x41ZBFHeP7BbqBleWn FIFFfk0eUrF98fTFrIgD9qykUI6nRxCrc1pLMrKN8RYRICxMz27r3xTaXS2VaTj/ G9PfJrNZl0u5euH6WzTYrtImiW/MriubcWfoSPkwAuCZbgGyhZPuk9zeLAj7Fu9j jLyVOLAj1jUcxWnY08J0 =F342 -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE--