From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBDkv-000547-3I for qemu-devel@nongnu.org; Sun, 27 Nov 2016 23:41:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBDkr-0004o6-Tl for qemu-devel@nongnu.org; Sun, 27 Nov 2016 23:41:29 -0500 Date: Mon, 28 Nov 2016 15:25:01 +1100 From: David Gibson Message-ID: <20161128042501.GN30927@umbus.fritz.box> References: <1479248275-18889-1-git-send-email-david@gibson.dropbear.id.au> <20161126013316.069b40b4@bahia> <20161128042346.GM30927@umbus.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MmQIYbZiCoQ2kDro" Content-Disposition: inline In-Reply-To: <20161128042346.GM30927@umbus.fritz.box> Subject: Re: [Qemu-devel] [RFCv2 00/12] Clean up compatibility mode handling 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, agraf@suse.de, qemu-ppc@nongnu.org, qemu-devel@nongnu.org, abologna@redhat.com, thuth@redhat.com, lvivier@redhat.com --MmQIYbZiCoQ2kDro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 28, 2016 at 03:23:46PM +1100, David Gibson wrote: > On Sat, Nov 26, 2016 at 01:33:16AM +0100, Greg Kurz wrote: > > On Wed, 16 Nov 2016 09:17:43 +1100 > > David Gibson wrote: > >=20 > > > This series is a significant rework to how we handle CPU compatibility > > > modes on ppc. > > >=20 > > > * Information about compatibility modes was previously open coded and > > > scattered across a number of functions in both target-ppc and spapr > > > code. It's now brought together into a common table of > > > compatibility modes. > > >=20 > > > * There was significant conceptual confusion about what a > > > compatibility mode means, and how it interacts with the machine > > > type. This cleans that up, clarifying that a compatibility mode > > > (as an externally set option) only makes sense on machine types > > > that don't permit the guest hypervisor privilege (i.e. 'pseries') > > >=20 > > > * It was previously the user's (or management layer's) responsibility > > > to determine compatibility of CPUs on either end for migration. > > > This uses the compatibility modes to check that properly during an > > > incoming migration. > > >=20 > > > * Some ill-considered sanity checks broke migration from 2.6 to 2.7, > > > due to some new instruction classes being added. This should avoid > > > a repeat of that problem for 2.8 (we may be able to backport a > > > minimal subset to 2.7-stable to fix the existing problem). > > >=20 > > > Patches 1-3 are preliminary cleanups which could stand on their own. > > > Patches 4-12 are the compatibility mode cleanup proper. > > >=20 > > > So far, this has been mimimally tested. There are quite a few > > > migration cases to check. For example: > > >=20 > > > Basic: > > >=20 > > > 1) Boot guest with -cpu host > > > Should go into POWER8 compat mode after CAS > > > Previously would have been raw mode > > >=20 >=20 >=20 > Thanks for doing these detailed tests, Greg. >=20 > >=20 > > =3D=3D QEMU =3D=3D > >=20 > > spapr_cas_pvr current=3D0, explicit_match=3D1, new=3Df000004 > >=20 > > =3D=3D guest =3D=3D > >=20 > > cpu : POWER8 (architected), altivec supported > >=20 > > > 2) Boot guest with -machine pseries,max-cpu-compat=3Dpower7 -cpu host > > > Should go into POWER7 compat mode > > >=20 > >=20 > > =3D=3D QEMU =3D=3D > >=20 > > spapr_cas_pvr current=3Df000003, explicit_match=3D1, new=3Df000003 > >=20 > > =3D=3D guest =3D=3D > >=20 > > cpu : POWER7 (architected), altivec supported > >=20 > > > 3) Boot guest with -cpu host,compat=3Dpower7 > > > Should act as (2), but print a warning > > >=20 > >=20 > > With extra patch to add explicit null to string visitors: > >=20 > > qapi: add explicit null to string input and output visitors > > Message-Id: <147954362297.28064.5118492606031513925.stgit@bahia> > >=20 > > =3D=3D QEMU =3D=3D > >=20 > > CPU 'compat' property is deprecated and has no effect; use max-cpu-comp= at machine > > property instead > >=20 > > spapr_cas_pvr current=3Df000003, explicit_match=3D1, new=3Df000003 > >=20 > > =3D=3D guest =3D=3D > >=20 > > cpu : POWER7 (architected), altivec supported > >=20 > > > 4) Boot guest via libvirt with power7 compat mode specified in XML > > > Should act as (3), (2) once we fix libvirt > > >=20 > >=20 > > Not tested yet. > >=20 > > > 5) Hack guest to only advertise power7 compatibility, boot with -cpu = host > > > Should go into POWER7 compat mode after CAS > > >=20 > >=20 > > =3D=3D QEMU =3D=3D > >=20 > > spapr_cas_pvr current=3D0, explicit_match=3D1, new=3Df000003 > >=20 > > =3D=3D guest =3D=3D > >=20 > > cpu : POWER7 (architected), altivec supported > >=20 > > > 6) Hack guest to only advertise real PVRs > > > Should remain in POWER8 raw mode after CAS > > >=20 > >=20 > > =3D=3D QEMU =3D=3D > >=20 > > spapr_cas_pvr current=3D0, explicit_match=3D1, new=3D0 > >=20 > > =3D=3D guest =3D=3D > >=20 > > cpu : POWER8 (raw), altivec supported > >=20 > > > 7) Hack guest to only advertise real PVRs > > > Boot with -machine pseries,max-cpu-compat=3Dpower8 > > > Should fail at CAS time > > >=20 > >=20 > > =3D=3D QEMU =3D=3D > >=20 > > h_client_architecture_support() returns H_HARDWARE as > > expected because max-cpu-compat is set and no compat > > PVR was found (even though the real PVR was found). > >=20 > > =3D=3D guest =3D=3D > >=20 > > WARNING: ibm,client-architecture-support call FAILED! > >=20 > > but the guest boots anyway and we end up with: > >=20 > > cpu : POWER8 (architected), altivec supported > >=20 > > This looks weird since the guest explicitly said it only > > supports real PVRs... raw mode like case 6) would make > > more sense IMHO but patch 11/12 sets the default to max-cpu-compat > > at machine reset time: > >=20 > > + ppc_set_compat_all(spapr->max_compat_pvr, &error_abort); > >=20 > > Maybe we should at least switch to raw mode, return an error > > and let the guest decide ?=20 > >=20 > > Another option would be to do as specified in LoPAPR section B.6.2.3 > > when no acceptable PVR was found and to simply terminate the guest. >=20 > So.. I suspect this is probably good enough in practice, given that > all known guests will actually advertise compat modes. The FAILED > gives at least a hint as to what's going on. >=20 > To get it strictly correct, then yes, I think terminating the guest is > probably the PAPRishly correct thing to do, although it's not clear > quite what we do then. We don't really have a mechanism for shutting > the VM down entirely (which might surprise management), and if we > reboot we're likely to just hit the same error again. >=20 > Hence my inclination to only worry about those details if someone > starts hitting them for real. Oh.. that said, I think we should at least throw in a meaningful error_report() since that should get propagated up to the error logs that mangement layers are likely to keep. >=20 > > > 8) Hack guest to only advertise power7 compatibility, boot with -cpu = host > > > Reboot to normal guest > > > Should go to power7 compat mode after CAS of boot 1 > > > Should revert to raw mode on reboot > > > SHould go to power8 compat mode after CAS of boot 2 > > >=20 > >=20 > > =3D=3D QEMU =3D=3D > >=20 > > boot 1: spapr_cas_pvr current=3D0, explicit_match=3D1, new=3Df000003 > > boot 2: spapr_cas_pvr current=3D0, explicit_match=3D1, new=3Df000004 > >=20 > > =3D=3D guest =3D=3D > >=20 > > boot 1: cpu : POWER7 (architected), altivec supported > > boot 2: cpu : POWER8 (architected), altivec supported > >=20 > > > Migration: > > >=20 > >=20 > > I'll give a try to migration next week. > >=20 > > Cheers. > >=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 --MmQIYbZiCoQ2kDro Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYO7GcAAoJEGw4ysog2bOSjp4QAMrfiMp2bHqqgSmglm8IkMrr 8V0epfWw2/sRYIxrr8z1mAkArypZVR3oa3oQDiHyGtBG127UheNVoSR5b48fN8hF W9P9fkY+xQG9RbI58qW9svt09QBM0VXEP4DcstqhfEngdcfpZKzOmPkvDUbOS3nR nX6NHwpxL7IUtWyZbkQqep4Rva4GX7r3Vfiw5KG19w1y1YYHlcPsyUshtxoSsBdH Kgfqz9QcdqbhVgUqSVHgin2FI4scZZqryMO2eDl8QrS43pEXUDMVRvQ2vaK5swtd iSKOWGVE5HyvX3QL+/An5C4M6lzIxHujKbUFzDQxFAspzgNPlIdbITTKSD2KmA4i +su9ErxqTE0hVhFmOq1DA92Z4EUPZGFjZHhJPcMG0cEqmlIi5HDMv/DEpjOeQuXh 2Npxig+OfwlSDi7CGoSCMlxajmN+kq1bxMWjsRD7JStr6xdteRijlRVAqDBA1EL9 0kS+EQn8SnQRmVbsFNiZcX1suY5vuWvCurN53/UGX3+S6g/qvLTsXtld4MoqI+d4 IymTfdqiSqIf2shcsYnckIpCbPaJmQ8jd0ZeSaBoMc1gfguIOnq0fHm72B+85mGQ GYwvAZmCkv+XGqoDteYPkj8oEyfaTWqUGVhinX5Tk0pRc08tGa0GUsQlDkc6OYSO /qQrpRDAp58Cr+3bEfLl =n+Hc -----END PGP SIGNATURE----- --MmQIYbZiCoQ2kDro--