From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d42Dj-0006LA-NR for qemu-devel@nongnu.org; Fri, 28 Apr 2017 05:29:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d42Dg-0001zG-I1 for qemu-devel@nongnu.org; Fri, 28 Apr 2017 05:29:47 -0400 Received: from 4.mo5.mail-out.ovh.net ([178.33.111.247]:58304) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1d42Dg-0001w7-7z for qemu-devel@nongnu.org; Fri, 28 Apr 2017 05:29:44 -0400 Received: from player786.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id 61971EA9DE for ; Fri, 28 Apr 2017 11:29:37 +0200 (CEST) Date: Fri, 28 Apr 2017 11:29:22 +0200 From: Greg Kurz Message-ID: <20170428112922.6a7ecc53@bahia> In-Reply-To: <20170427072843.8089-1-david@gibson.dropbear.id.au> References: <20170427072843.8089-1-david@gibson.dropbear.id.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/p+6BlpT91bbdadcmYLyZWgf"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [PATCHv3 0/4] Clean up compatibility mode handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: clg@kaod.org, aik@ozlabs.ru, mdroth@linux.vnet.ibm.com, nikunj@linux.vnet.ibm.com, agraf@suse.de, abologna@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org --Sig_/p+6BlpT91bbdadcmYLyZWgf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 27 Apr 2017 17:28:39 +1000 David Gibson wrote: > This is a rebased and revised version of my patches revising CPU > compatiblity mode handling on ppc, last posted in November. Since > then, many of the patches have already been merged (some for 2.9, some > since). This is what's left. >=20 > * There was 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 > This hasn't been extensively tested yet. There are quite a few > migration cases to consider, for example: >=20 Hi David, I'll rerun the tests shortly. Cheers, -- Greg > Basic: >=20 > 1) Boot guest with -cpu host > Should go into POWER8 compat mode after CAS > Previously would have been raw mode >=20 > 2) Boot guest with -machine pseries,max-cpu-compat=3Dpower7 -cpu host > Should go into POWER7 compat mode >=20 > 3) Boot guest with -cpu host,compat=3Dpower7 > Should act as (2), but print a warning >=20 > 4) Boot guest via libvirt with power7 compat mode specified in XML > Should act as (3), (2) once we fix libvirt >=20 > 5) Hack guest to only advertise power7 compatibility, boot with -cpu host > Should go into POWER7 compat mode after CAS >=20 > 6) Hack guest to only advertise real PVRs > Should remain in POWER8 raw mode after CAS >=20 > 7) Hack guest to only advertise real PVRs > Boot with -machine pseries,max-cpu-compat=3Dpower8 > Should fail at CAS time >=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 > Migration: >=20 > 9) Boot guest with qemu-2.6 -machine pseries-2.6 -cpu host > Migrate to qemu-2.8 -machine pseries-2.6 -cpu host > Should work, end up running in power8 raw mode >=20 > 10) Boot guest with qemu-2.7 -machine pseries-2.7 -cpu host > Migrate to qemu-2.8 -machine pseries-2.7 -cpu host > Should work, end up running in power8 raw mode >=20 > 11) Boot guest with qemu-2.7 -machine pseries-2.7 -cpu host,compat=3Dpowe= r7 > Migrate to qemu-2.8 -machine pseries-2.7 -cpu host,compat=3Dpower7 > Should work, be running in POWER7 compat after, but give warning = like > (3) >=20 > 12) Boot guest with qemu-2.7 -machine pseries-2.7 -cpu host,compat=3Dpowe= r7 > Migrate to qemu-2.8 -machine pseries-2.7,max-cpu-compat=3Dpower7 -cpu= host > Should work, be running in POWER7 compat after, no warning >=20 > 13) Boot to SLOF with qemu-2.6 -machine pseries-2.6 -cpu host > Migrate to qemu-2.8 -machine pseries-2.6 -cpu host >=20 > ? >=20 > 14) Boot to SLOF with qemu-2.7 -machine pseries-2.7 -cpu host > Migrate to qemu-2.8 -machine pseries-2.7 -cpu host > ? >=20 > 15) Boot to SLOF with qemu-2.7 -machine pseries-2.7 -cpu host,compat=3Dpo= wer7 > Migrate to qemu-2.8 -machine pseries-2.7 -cpu host,compat=3Dpower7 > ? >=20 > 16) Boot to SLOF with qemu-2.7 -machine pseries-2.7 -cpu host,compat=3Dpo= wer7 > Migrate to qemu-2.8 -machine pseries-2.7,max-cpu-compat=3Dpower7 -cpu= host > ? >=20 > 17) Boot guest with qemu-2.6 -machine pseries-2.6 -cpu host > Migrate to qemu-2.7.z -machine pseries-2.6 -cpu host > Should work >=20 > 18) Hack guest to only advertise power7 compatibility, boot with -cpu host > Boot with qemu-2.8, migrate to qemu-2.8 > Should be in power7 compat mode after CAS on source, and still > in power7 compat mode on destination >=20 >=20 > Changes since RFCv2: > * Many patches dropped, since they're already merged > * Rebased, fixed conflicts > * Restored support for backwards migration (wasn't as complicated as > I thought) > * Updated final patch's description to more accurately reflect the > logic >=20 > Changes since RFCv1: > * Change CAS logic to prefer compatibility modes over raw mode > * Simplified by giving up on half-hearted attempts to maintain > backwards migration > * Folded migration stream changes into a single patch > * Removed some preliminary patches which are already merged >=20 >=20 >=20 > David Gibson (3): > pseries: Move CPU compatibility property to machine > pseries: Reset CPU compatibility mode > ppc: Rework CPU compatibility testing across migration >=20 > Greg Kurz (1): > qapi: add explicit null to string input and output visitors >=20 > hw/ppc/spapr.c | 8 ++++- > hw/ppc/spapr_cpu_core.c | 47 +++++++++++++++++++------ > hw/ppc/spapr_hcall.c | 2 +- > include/hw/ppc/spapr.h | 12 ++++--- > qapi/string-input-visitor.c | 11 ++++++ > qapi/string-output-visitor.c | 14 ++++++++ > target/ppc/compat.c | 65 ++++++++++++++++++++++++++++++++++ > target/ppc/cpu.h | 6 ++-- > target/ppc/machine.c | 71 +++++++++++++++++++++++++++++++++++-- > target/ppc/translate_init.c | 84 ++++++++++++--------------------------= ------ > 10 files changed, 238 insertions(+), 82 deletions(-) >=20 --Sig_/p+6BlpT91bbdadcmYLyZWgf Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlkDC3IACgkQAvw66wEB28JDFQCbBnFn/WH/NRwNhFmqy05v+t2t xssAmgKmwAoHqbTP3h3dkIZYVZX4maQ2 =f3j3 -----END PGP SIGNATURE----- --Sig_/p+6BlpT91bbdadcmYLyZWgf--