From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBDkv-000548-3O 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 1cBDks-0004oC-0r for qemu-devel@nongnu.org; Sun, 27 Nov 2016 23:41:29 -0500 Date: Mon, 28 Nov 2016 15:23:46 +1100 From: David Gibson Message-ID: <20161128042346.GM30927@umbus.fritz.box> References: <1479248275-18889-1-git-send-email-david@gibson.dropbear.id.au> <20161126013316.069b40b4@bahia> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kUBUi7JBpjcBtem/" Content-Disposition: inline In-Reply-To: <20161126013316.069b40b4@bahia> 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 --kUBUi7JBpjcBtem/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 Thanks for doing these detailed tests, Greg. >=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-compat= 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 ho= st > > 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. 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. 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. Hence my inclination to only worry about those details if someone starts hitting them for real. > > 8) Hack guest to only advertise power7 compatibility, boot with -cpu ho= st > > 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 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 --kUBUi7JBpjcBtem/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYO7FSAAoJEGw4ysog2bOSmKcP/RMB4Qg983uiPNPUPj8tVwW1 EU1Z1lIKuGTIX8sHl6EaruzQFEwnyn02ZGXjH2qReq4CNWk1IfZwNIGei/O0qWHY kqAcYUu1REb60OCwW1gTf+XX0+GxHP5acYTOGNGRQDydu81XHynTLSyqpIWBmKyC YIKq7UWSHiZBPu2DgtutTopZ3vf77K1XaDmr6BOVOB/N2ONZi37lFSK+Ca6j6fIH 1zh9YTC63HSu/hgKMpb+c0pRR8Qzgwq6W6j4NFcSq+CrxZr0ZzPAAs/WzrQRaPG6 65XxMszrUoprg//YLxoKzFeB48fRCSnDe3pN4wF/unFTDGJP6VS14qVCREzHQl2N QCx9PdvqTHconS98GiI3wCCilU+EEB8l1eUW8O4Wq2y+PAx74L+tRcQt1v8YPp2q 3uIo1uDDwgZ6F1bgJtYUdC69lA5gpukUuVlilCTcabyY2+EvV5ASkHttOpsDiUrI coyMgbGQn1CEs/oufC+8c3NabeyMZH4GMM8HAYiiihl8BzqVz5RbleSs/HDCWQRI KYm3Y0O96duGbc6N2E4OZhJ4QVE/1YWCWQ7mGXOzeDn8ni7fhzJh2K10gHaHrm3g ko9LrSyvNV5jCxG6g6jb1MKDEolNvyZQSqbZRtIMyXRPLQVFDsjy56dvNQHuRfBQ nMzE2wbV1lEYcES8WB8g =5m1N -----END PGP SIGNATURE----- --kUBUi7JBpjcBtem/--