From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3z4Y-0000IH-9O for qemu-devel@nongnu.org; Tue, 08 Nov 2016 00:35:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3z4X-0002GI-3t for qemu-devel@nongnu.org; Tue, 08 Nov 2016 00:35:50 -0500 Date: Tue, 8 Nov 2016 16:29:56 +1100 From: David Gibson Message-ID: <20161108052956.GV28688@umbus.fritz.box> References: <1477825928-10803-1-git-send-email-david@gibson.dropbear.id.au> <1477825928-10803-16-git-send-email-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FZIkiClxIZ9JeWSb" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC 15/17] ppc: Check that CPU model stays consistent across migration 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 --FZIkiClxIZ9JeWSb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 04, 2016 at 06:54:48PM +1100, Alexey Kardashevskiy wrote: > On 30/10/16 22:12, David Gibson wrote: > > When a vmstate for the ppc cpu was first introduced (a90db15 "target-pp= c: > > Convert ppc cpu savevm to VMStateDescription"), a VMSTATE_EQUAL was used > > to ensure that identical CPU models were used at source and destination > > as based on the PVR (Processor Version Register). > >=20 > > However this was a problem for HV KVM, where due to hardware limitations > > we always need to use the real PVR of the host CPU. So, to allow > > migration between hosts with "similar enough" CPUs, the PVR check was > > removed in 569be9f0 "target-ppc: Remove PVR check from migration". This > > left the onus on user / management to only attempt migration between > > compatible CPUs. > >=20 > > Now that we've reworked the handling of compatiblity modes, we have the > > information to actually determine if we're making a compatible migratio= n. > > So this patch partially restores the PVR check. If the source was runn= ing > > in a compatibility mode, we just make sure that the destination cpu can > > also run in that compatibility mode. However, if the source was running > > in "raw" mode, we verify that the destination has the same PVR value. > >=20 > > Signed-off-by: David Gibson > > --- > > target-ppc/machine.c | 15 +++++++++++---- > > 1 file changed, 11 insertions(+), 4 deletions(-) > >=20 > > diff --git a/target-ppc/machine.c b/target-ppc/machine.c > > index 5d87ff6..62b9e94 100644 > > --- a/target-ppc/machine.c > > +++ b/target-ppc/machine.c > > @@ -173,10 +173,12 @@ static int cpu_post_load(void *opaque, int versio= n_id) > > target_ulong msr; > > =20 > > /* > > - * We always ignore the source PVR. The user or management > > - * software has to take care of running QEMU in a compatible mode. > > + * If we're operating in compat mode, we should be ok as long as > > + * the destination supports the same compatiblity mode. > > + * > > + * Otherwise, however, we require that the destination has exactly > > + * the same CPU model as the source. > > */ > > - env->spr[SPR_PVR] =3D env->spr_cb[SPR_PVR].default_value; > > =20 > > #if defined(TARGET_PPC64) > > if (cpu->compat_pvr) { > > @@ -188,8 +190,13 @@ static int cpu_post_load(void *opaque, int version= _id) > > error_free(local_err); > > return -1; > > } > > - } > > + } else > > #endif > > + { > > + if (env->spr[SPR_PVR] !=3D env->spr_cb[SPR_PVR].default_value)= { > > + return -1; > > + } > > + } >=20 > This should break migration from host with PVR=3D004d0200 to host with > PVR=3D004d0201, what is the benefit of such limitation? There probably isn't one. But the point is it also blocks migration =66rom a host with PVR=3D004B0201 (POWER8) to one with PVR=3D00201400 (403GCX) and *that* has a clear benefit. I don't see a way to block the second without the first, except by creating a huge compatibility matrix table, which would require inordinate amounts of time to research carefully. --=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 --FZIkiClxIZ9JeWSb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYIWLUAAoJEGw4ysog2bOSnmEQALgTK6M3SFWqGWvjsF2PLbRm iU2VVjX4qJQr1kWklVG4vnCKO9R76cQsfL4dhecK+MykpUQ3Q5nQkbTyUbrgKAT5 vv3k13CtPfkNfXESxPUzkjgg7PtxygJ6nlOIL2zg6qbI2H1MfmITHAZK8gsnpYl0 BOWmJH/h2riLuhYGiSfeElhX2+hB+WwV1p6BJiqB5LVYXgRNgwKqgBTuAmqk2cLW k2So+Gl+FHH31oeZ8K64SRcoZwi3YgS93xpW/KehbeWvbht40y6Rcelu9IwyyJMM F4LUNxBjY+RjZY33+LC9L9uTnf0ZSPe8fis4xy9l1qjWpKFEG+3EIJ6ez4KJwANx 2E10Q9dXNA8XfbcV/uV/pG+sJOqKvJhw+Go6TVmySxzyOHwQ7UnplWBlqtXXvgLJ Cb+6XkAwDR+W9KdXz3NzXMkTse+vH9X5cxjOJFOPZAHnlzMOyU7HRcuUlozDJrn1 h9ohkr+Q8TTxDBZq1C+W0IWUUAnFPJQuF/OopjjIz4r3uAM1WJUGl5/cgx58LPZw pzi+j+ug6UV3R1FF41ZDz8no+e2sMhraF2jDT2L0CobJGbvmmz6TNNQ1SW3N2vox oEwqE/pKXXUyJIkMFGmjnTZd2XH6UeQw3MsiOmRQEPt6ghw7F6DDGIGyqTcQYpFb R0nWOpnVfaLt8QchqnHx =aobn -----END PGP SIGNATURE----- --FZIkiClxIZ9JeWSb--