From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDlHc-0000OW-9u for qemu-devel@nongnu.org; Sun, 04 Dec 2016 23:53:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDlHa-0000Ur-PA for qemu-devel@nongnu.org; Sun, 04 Dec 2016 23:53:44 -0500 Date: Mon, 5 Dec 2016 15:09:16 +1100 From: David Gibson Message-ID: <20161205040916.GB32366@umbus.fritz.box> References: <1479248275-18889-1-git-send-email-david@gibson.dropbear.id.au> <1479248275-18889-13-git-send-email-david@gibson.dropbear.id.au> <20161202154825.613bc4ad@bahia> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: <20161202154825.613bc4ad@bahia> Subject: Re: [Qemu-devel] [Qemu-ppc] [RFCv2 12/12] ppc: Rework CPU compatibility testing across migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: clg@kaod.org, aik@ozlabs.ru, mdroth@linux.vnet.ibm.com, nikunj@linux.vnet.ibm.com, lvivier@redhat.com, thuth@redhat.com, qemu-devel@nongnu.org, abologna@redhat.com, qemu-ppc@nongnu.org --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2016 at 03:48:25PM +0100, Greg Kurz wrote: > On Wed, 16 Nov 2016 09:17:55 +1100 > David Gibson wrote: >=20 > > Migrating between different CPU versions is quite complicated for ppc. > > A long time ago, we ensure identical CPU versions at either end by chec= king > > the PVR had the same value. However, this breaks under KVM HV, because > > we always have to use the host's PVR - it's not virtualized. That would > > mean we couldn't migrate between hosts with different PVRs, even if the > > CPUs are close enough to compatible in practice (sometimes identical co= res > > with different surrounding logic have different PVRs, so this happens in > > practice quite often). > >=20 > > So, we removed the PVR check, but instead checked that several flags > > indicating supported instructions matched. This turns out to be a bad > > idea, because those instruction masks are not architected information, = but > > essentially a TCG implementation detail. So changes to qemu internal C= PU > > modelling can break migration - this happened between qemu-2.6 and > > qemu-2.7. > >=20 > > Modern server-class CPUs can be placed into compatibility modes. Now t= hat > > we're handling those properly, we finally have the information to sanely > > deal with CPU compatibility across migration. > >=20 > > This patch bumps the migration version number for the ppc CPU removing = the > > instruction mask field (and some other unwise VMSTATE_EQUAL checks), and > > adding the compatibility PVR to the migration stream. > >=20 >=20 > Things have changed since you posted this RFC: >=20 > commit 16a2497bd44cac1856e259654fd304079bd1dcdc > Author: David Gibson > Date: Mon Nov 21 16:28:12 2016 +1100 >=20 > target-ppc: Fix CPU migration from qemu-2.6 <-> later versions >=20 > and >=20 > commit 146c11f16f12dbfea62cbd7f865614bb6fcbc6b5 > Author: David Gibson > Date: Mon Nov 21 16:29:30 2016 +1100 >=20 > target-ppc: Allow eventual removal of old migration mistakes >=20 > I guess that the version bumping isn't necessary anymore if we keep these. >=20 > I'll assume yes and rebase this patch against current master, simply drop= ping > the version bumping and related lines. Yeah, I realised that breaking backwards migration was a bad idea, and with some help from Dave Gilbert worked out how to make it possible. I realize I'm going to have to rework my compat series in light of these changes. > > We consider the CPUs compatible for migration if: > > * The source was running in a compatibility mode which the destinat= ion > > supports > > OR * The source has a PVR matching the same qemu CPU class as the > > destination, either an exact match or an approximate match determ= ined > > by the cpu class's pvr_match hook. > >=20 > > Signed-off-by: David Gibson > > --- > > target-ppc/machine.c | 87 ++++++++++++++++++++++++++++++++++++++++++++= +++----- > > 1 file changed, 79 insertions(+), 8 deletions(-) > >=20 > > diff --git a/target-ppc/machine.c b/target-ppc/machine.c > > index e43cb6c..25a30d5 100644 > > --- a/target-ppc/machine.c > > +++ b/target-ppc/machine.c > > @@ -8,6 +8,7 @@ > > #include "helper_regs.h" > > #include "mmu-hash64.h" > > #include "migration/cpu.h" > > +#include "qapi/error.h" > > =20 > > static int cpu_load_old(QEMUFile *f, void *opaque, int version_id) > > { > > @@ -163,6 +164,30 @@ static void cpu_pre_save(void *opaque) > > } > > } > > =20 > > +/* > > + * Determine if a given PVR is a "close enough" match to the CPU > > + * object. For TCG and KVM PR it would probably be sufficient to > > + * require an exact PVR match. However for KVM HV the user is > > + * restricted to a PVR exactly matching the host CPU. The correct way > > + * to handle this is to put the guest into an architected > > + * compatibility mode. However, to allow a more forgiving transition > > + * and migration from before this was widely done, we allow migration > > + * between sufficiently similar PVRs, as determined by the CPU class's > > + * pvr_match() hook. > > + */ > > +static bool pvr_match(PowerPCCPU *cpu, uint32_t pvr) > > +{ > > + PowerPCCPUClass *pcc =3D POWERPC_CPU_GET_CLASS(cpu); > > + > > + if (pvr =3D=3D pcc->pvr) { > > + return true; > > + } > > + if (pcc->pvr_match) { > > + return pcc->pvr_match(pcc, pvr); > > + } > > + return false; > > +} > > + > > static int cpu_post_load(void *opaque, int version_id) > > { > > PowerPCCPU *cpu =3D opaque; > > @@ -171,10 +196,31 @@ 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; > > + > > +#if defined(TARGET_PPC64) > > + if (cpu->compat_pvr) { > > + Error *local_err =3D NULL; > > + > > + ppc_set_compat(cpu, cpu->compat_pvr, &local_err); >=20 > This calls cpu_synchronize_state(CPU(cpu)) and trashes the registers. This > is the root cause behind the program interrupts I mentioned in another ma= il. >=20 > Adding a sync_needed boolean argument to ppc_set_compat() seems to be eno= ugh > to get this working. So I'll just do that and rerun the tests. >=20 > Cheers. >=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 --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYROhpAAoJEGw4ysog2bOSjsUP/izgrwGjjoPaCGCN2cGnDUHx 4C3kJAj+4TQRmh+3q0jWsYuLx/pwhxwN2IpaVS8WM1G3qlxrE/wpcSTNxRq/bmCG aoEAclVbphKrnJ3pJKfvStD3ULD+Cf4zfawre6+VtjxisKJRwftp4Wb2NqQbLJqx AtRSKwubB3smrhBl+amPllX4fWZT9/E0Ub0a7m2xbo18A3t2rXlzbmcGaRlvMyrY o61aTeAPxKxCC3kKlHTFSx1CePGQewsjqh+5C0VbpfwB5+E/nMcGt1F0Ab7ZRMFs pID/Nlg8BE9G59nJv/aodsBj90PIGHLU4t4gJOAFAodFGguFuT0nwMiMFg7b9KqM TfoJcfYh/ECsKClC8WLtiKDGQIwPDtPfiSBCCoRniyWPHhYHtklU+6d3xq+L/0fY 1bkAkVkK0in28dGUN8egSvtHOnHVaCJpsUQOo3j98AepJ11qEjcPOxn7oPKNXqsi H7Vwz3eUJgwAy4wXWcNiSmw6EWw78qRhjdC0N6d2Marx84UW2XDB2FuRq6Ype2pn IlKj7eOcSzl0hmR7yInxe1W8e1oP9UnU3+ALhOnsU4x72sZ1feeyobJ86r0wMfHR q9SYQW1ZSoA4NIssWNEl8wZLvCGLWoB9xmoctF1CE39ztwBMUuf38wTP/+BmkNms hzco2aYYIMFr2Y8PXdfX =U2i9 -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU--