From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3z4X-0000Hv-RG 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 1c3z4W-0002G3-JY for qemu-devel@nongnu.org; Tue, 08 Nov 2016 00:35:49 -0500 Date: Tue, 8 Nov 2016 16:31:08 +1100 From: David Gibson Message-ID: <20161108053108.GW28688@umbus.fritz.box> References: <1477825928-10803-1-git-send-email-david@gibson.dropbear.id.au> <1477825928-10803-17-git-send-email-david@gibson.dropbear.id.au> <57db31f3-e8b6-cdb4-da1e-e08f06bebd5c@ozlabs.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1Wg5Vd7si6EhrIHA" Content-Disposition: inline In-Reply-To: <57db31f3-e8b6-cdb4-da1e-e08f06bebd5c@ozlabs.ru> Subject: Re: [Qemu-devel] [RFC 16/17] ppc: Remove counter-productive "sanity checks" in 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 --1Wg5Vd7si6EhrIHA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 04, 2016 at 04:52:39PM +1100, Alexey Kardashevskiy wrote: > On 30/10/16 22:12, David Gibson wrote: > > When vmstate for the ppc cpu was introduced in a90db158 "target-ppc: > > Convert ppc cpu savevm to VMStateDescription", several "sanity check" > > fields were included, verifying that certain cpu parameters matched bet= ween > > source and destination. > >=20 > > This turns out not to have been a good idea. For one thing it's redund= ant > > with existing checks for a compatible cpu version at either end. But m= ore > > importantly the insns_flags and insns_flags2 checks actively break thin= gs: > > they expose what's essentially an internal TCG implementation detail in= the > > migration stream. That means that when new instruction classes are add= ed > > or rearranged, migration can break. > >=20 > > This removes these ill-considered sanity checks. > >=20 > > Signed-off-by: David Gibson > > --- > > target-ppc/machine.c | 8 ++++---- > > 1 file changed, 4 insertions(+), 4 deletions(-) > >=20 > > diff --git a/target-ppc/machine.c b/target-ppc/machine.c > > index 62b9e94..453ef0a 100644 > > --- a/target-ppc/machine.c > > +++ b/target-ppc/machine.c > > @@ -602,10 +602,10 @@ const VMStateDescription vmstate_ppc_cpu =3D { > > /* FIXME: access_type? */ > > =20 > > /* Sanity checking */ > > - VMSTATE_UINTTL_EQUAL(env.msr_mask, PowerPCCPU), > > - VMSTATE_UINT64_EQUAL(env.insns_flags, PowerPCCPU), > > - VMSTATE_UINT64_EQUAL(env.insns_flags2, PowerPCCPU), > > - VMSTATE_UINT32_EQUAL(env.nb_BATs, PowerPCCPU), > > + VMSTATE_UNUSED(sizeof(target_ulong) /* msr_mask */ > > + + sizeof(uint64_t) /* insns_flags */ > > + + sizeof(uint64_t) /* insns_flags2 */ > > + + sizeof(uint32_t)), /* nb_BATs */ >=20 >=20 > This breaks migration to older QEMU: >=20 > 25055@1478238734.537761:vmstate_load_field_error field "env.msr_mask" load > failed, ret =3D -22 Again, I don't think we generally support backwards migration. That said, it would be nice here to do a "set to this field on ourgoing migration, but ignore on incoming migration". Do you know a way to do that? a >=20 >=20 >=20 > > VMSTATE_END_OF_LIST() > > }, > > .subsections =3D (const VMStateDescription*[]) { > >=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 --1Wg5Vd7si6EhrIHA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYIWMcAAoJEGw4ysog2bOSVcsP/3l6aSogzrx9gMn2D4HYnpnU Ytlf9KAc4Y7vRLRAUMUC7c49CjBpYDR49VqqxEkL+Bwy1UO6WarM0QTs+1bpyxuQ Q3gO4vQol7enHJ3x/M6p13ayEL2+t9C/zqtAq+/JRWJeYmxYotV9TTCwS/StnHW1 m53PGZhoqUkkv1vyDBoWv07jC/TxgoFoa9NTBTny1xURLWnm/gyyZYUUgXS8jriV MRdulncea0m2Syo0fgOwp7vNkpURbvR/uvWMeEu7qm7SwKsaCuwHTwUyLeltoHN+ 8VsR4qbKCm6s27rbOhB3o3sXGcsshWX72o9fDYvSUEJwX7VJHMhZKFjivFsvsDcq sD8TH+xO7l3XkYxnMysrUxEdqrneMyjjMUbkdbqZiSMkxGROU0IjubScYC9WdeJD W3+DdV0aARfaYSZSvmH8w4zKxk1mA/AQIFG5vzZZmYD1hhXs2QsLFUJrTdGQulTO uTsoILzLOEeMylXhkyHoJa28j9zUFI3+bnh0F8XDdDXSogS1690jGdyGAwkHCof+ 9UF5j/rJ/V+ldPbEMWTEda5/umRtMWSqPKRFGNCQm5ZY6k0XPcsUOe62F892DqAU vF2vGeSqEoRHAJE8K7E/Y1q8KprpGhRposTZeeXlIz5TPXvrSveoYLmCYWLGhjI9 8b22F4RjO1pKW+g6wvZL =1y6A -----END PGP SIGNATURE----- --1Wg5Vd7si6EhrIHA--