From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4L3V-00056q-Oy for qemu-devel@nongnu.org; Wed, 09 Nov 2016 00:04:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4L3R-0003z8-Ha for qemu-devel@nongnu.org; Wed, 09 Nov 2016 00:04:13 -0500 Date: Wed, 9 Nov 2016 15:24:07 +1100 From: David Gibson Message-ID: <20161109042407.GE427@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> <20161108052956.GV28688@umbus.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TD8GDToEDw0WLGOL" 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 --TD8GDToEDw0WLGOL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 08, 2016 at 05:03:49PM +1100, Alexey Kardashevskiy wrote: > On 08/11/16 16:29, David Gibson wrote: > > 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-= ppc: > >>> Convert ppc cpu savevm to VMStateDescription"), a VMSTATE_EQUAL was u= sed > >>> to ensure that identical CPU models were used at source and destinati= on > >>> as based on the PVR (Processor Version Register). > >>> > >>> However this was a problem for HV KVM, where due to hardware limitati= ons > >>> 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". T= his > >>> left the onus on user / management to only attempt migration between > >>> compatible CPUs. > >>> > >>> Now that we've reworked the handling of compatiblity modes, we have t= he > >>> information to actually determine if we're making a compatible migrat= ion. > >>> So this patch partially restores the PVR check. If the source was ru= nning > >>> in a compatibility mode, we just make sure that the destination cpu c= an > >>> also run in that compatibility mode. However, if the source was runn= ing > >>> in "raw" mode, we verify that the destination has the same PVR value. > >>> > >>> Signed-off-by: David Gibson > >>> --- > >>> target-ppc/machine.c | 15 +++++++++++---- > >>> 1 file changed, 11 insertions(+), 4 deletions(-) > >>> > >>> 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 vers= ion_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 mod= e. > >>> + * 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 exact= ly > >>> + * 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 versi= on_id) > >>> error_free(local_err); > >>> return -1; > >>> } > >>> - } > >>> + } else > >>> #endif > >>> + { > >>> + if (env->spr[SPR_PVR] !=3D env->spr_cb[SPR_PVR].default_valu= e) { > >>> + return -1; > >>> + } > >>> + } > >> > >> This should break migration from host with PVR=3D004d0200 to host with > >> PVR=3D004d0201, what is the benefit of such limitation? > >=20 > > There probably isn't one. But the point is it also blocks migration > > from 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 >=20 > This is pcc->pvr_match() for this purpose. Hmm.. thinking about this. Obviously requiring an exactly matching PVR is the architecturally "safest" approach. For TCG and PR KVM, it really should be sufficient - if you can select "close" PVRs at each end, you should be able to select exactly matching ones just as well. For HV KVM, we should generally be using compatibility modes to allow migration between a relatively wide range of CPUs. My intention was basically to require moving to that model, rather than "approximate matching" real PVRs. I'm still convinced using compat modes is the right way to go medium to long term. However, allowing the approximate matches could make for a more forgiving transition, if people have existing hosts in "raw" mode. Ok, I'll add pvr_match checking to this. --=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 --TD8GDToEDw0WLGOL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYIqTiAAoJEGw4ysog2bOSfCYP/3Dsav/7GhD0/QXFaUA4niOw /8mY/tf1uQJaA1LoA2kBlNDb46L/Pe9z1w55Oh+FOkaFI3LevVx/mAbADV7CT6Vw P/xi4g7CZPMYilYC0fS6mLAXWHBqLEIwssIfGI5QdVfB2qX0eBZBDeUMk7UcdNaU LVXGv0bcEzi4RT3TLetwotOsyjxhNuiDIZ8ce4hI2W2ocjvuXSB91a6jbD0mHh/m 6BH5hv9GRty7WOe7/kwMu+mswrHgS3JHLu5AXio4CwZTiaXuzUPgevUOQbd5aR5Y bJC5aMYtqPT7a8LbqiMuxwplMtF3ftaMFlROP0dXdkOqYizFesXfVKk6Kt4L4m2G caXxPYQpTPYh2f3WODw0n1jdQQAMJz4w9zUSpyoacb5WMHH5acFAx755g0uosMgu 7bm/PtIj0QRJwqZeXuNt9spGdliGeYPbK327BqfQF7rFQenL6TkUty6tvg0AGxtK CnibA4crUydPzp3KsOwc8kegJRLVfv2rb8Ee2rOVwq9upFVGcqp7Y/xjJ33Yi+98 Cej5H8nuPi3Kmb99vYJ3lgV/YQW6xL8zFqCLtkHRLs0B5i+Mh8jLl2/IuCI8NAgq cR1ZkQi9J1UqhHnZsW2DLSsDDW9mcpGFHKpbSuW1XYuzujVsyPRRzdQx/+PtKPGJ 5t0uhID2R3ELQUOJs2IX =3woT -----END PGP SIGNATURE----- --TD8GDToEDw0WLGOL--