qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: David Gibson <david@gibson.dropbear.id.au>
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
Subject: Re: [Qemu-devel] [RFCv2 00/12] Clean up compatibility mode handling
Date: Sat, 26 Nov 2016 01:33:16 +0100	[thread overview]
Message-ID: <20161126013316.069b40b4@bahia> (raw)
In-Reply-To: <1479248275-18889-1-git-send-email-david@gibson.dropbear.id.au>

On Wed, 16 Nov 2016 09:17:43 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> This series is a significant rework to how we handle CPU compatibility
> modes on ppc.
> 
>  * 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.
> 
>  * 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')
> 
>  * 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.
> 
>  * 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).
> 
> Patches 1-3 are preliminary cleanups which could stand on their own.
> Patches 4-12 are the compatibility mode cleanup proper.
> 
> So far, this has been mimimally tested.  There are quite a few
> migration cases to check.  For example:
> 
> Basic:
> 
> 1) Boot guest with -cpu host
> 	Should go into POWER8 compat mode after CAS
> 	Previously would have been raw mode
> 

== QEMU ==

spapr_cas_pvr current=0, explicit_match=1, new=f000004

== guest ==

cpu             : POWER8 (architected), altivec supported

> 2) Boot guest with -machine pseries,max-cpu-compat=power7 -cpu host
> 	Should go into POWER7 compat mode
> 

== QEMU ==

spapr_cas_pvr current=f000003, explicit_match=1, new=f000003

== guest ==

cpu             : POWER7 (architected), altivec supported

> 3) Boot guest with -cpu host,compat=power7
> 	Should act as (2), but print a warning
> 

With extra patch to add explicit null to string visitors:

qapi: add explicit null to string input and  output visitors
Message-Id: <147954362297.28064.5118492606031513925.stgit@bahia>

== QEMU ==

CPU 'compat' property is deprecated and has no effect; use max-cpu-compat machine
property instead

spapr_cas_pvr current=f000003, explicit_match=1, new=f000003

== guest ==

cpu             : POWER7 (architected), altivec supported

> 4) Boot guest via libvirt with power7 compat mode specified in XML
> 	Should act as (3), (2) once we fix libvirt
> 

Not tested yet.

> 5) Hack guest to only advertise power7 compatibility, boot with -cpu host
> 	Should go into POWER7 compat mode after CAS
> 

== QEMU ==

spapr_cas_pvr current=0, explicit_match=1, new=f000003

== guest ==

cpu             : POWER7 (architected), altivec supported

> 6) Hack guest to only advertise real PVRs
> 	Should remain in POWER8 raw mode after CAS
> 

== QEMU ==

spapr_cas_pvr current=0, explicit_match=1, new=0

== guest ==

cpu             : POWER8 (raw), altivec supported

> 7) Hack guest to only advertise real PVRs
>    Boot with -machine pseries,max-cpu-compat=power8
>    	Should fail at CAS time
> 

== QEMU ==

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).

== guest ==

WARNING: ibm,client-architecture-support call FAILED!

but the guest boots anyway and we end up with:

cpu             : POWER8 (architected), altivec supported

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:

+        ppc_set_compat_all(spapr->max_compat_pvr, &error_abort);

Maybe we should at least switch to raw mode, return an error
and let the guest decide ? 

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.

> 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
> 

== QEMU ==

boot 1: spapr_cas_pvr current=0, explicit_match=1, new=f000003
boot 2: spapr_cas_pvr current=0, explicit_match=1, new=f000004

== guest ==

boot 1: cpu             : POWER7 (architected), altivec supported
boot 2: cpu             : POWER8 (architected), altivec supported

> Migration:
> 

I'll give a try to migration next week.

Cheers.

--
Greg

> 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
> 
> 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
> 
> 11) Boot guest with qemu-2.7 -machine pseries-2.7 -cpu host,compat=power7
>     Migrate to qemu-2.8 -machine pseries-2.7 -cpu host,compat=power7
>    	Should work, be running in POWER7 compat after, but give warning like
> 	(3)
> 
> 12) Boot guest with qemu-2.7 -machine pseries-2.7 -cpu host,compat=power7
>     Migrate to qemu-2.8 -machine pseries-2.7,max-cpu-compat=power7 -cpu host
>    	Should work, be running in POWER7 compat after, no warning
> 
> 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
> 	?
> 
> 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
>    	?
> 
> 15) Boot to SLOF with qemu-2.7 -machine pseries-2.7 -cpu host,compat=power7
>     Migrate to qemu-2.8 -machine pseries-2.7 -cpu host,compat=power7
>    	?
> 
> 16) Boot to SLOF with qemu-2.7 -machine pseries-2.7 -cpu host,compat=power7
>     Migrate to qemu-2.8 -machine pseries-2.7,max-cpu-compat=power7 -cpu host
>    	?
> 
> 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
> 
> 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
> 
> 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
> 
> David Gibson (12):
>   pseries: Always use core objects for CPU construction
>   pseries: Make cpu_update during CAS unconditional
>   ppc: Clean up and QOMify hypercall emulation
>   ppc: Rename cpu_version to compat_pvr
>   ppc: Rewrite ppc_set_compat()
>   ppc: Rewrite ppc_get_compat_smt_threads()
>   ppc: Validate compatibility modes when setting
>   pseries: Rewrite CAS PVR compatibility logic
>   ppc: Add ppc_set_compat_all()
>   pseries: Move CPU compatibility property to machine
>   pseries: Reset CPU compatibility mode
>   ppc: Rework CPU compatibility testing across migration
> 
>  hw/ppc/spapr.c              | 158 ++++++++++++++++------------
>  hw/ppc/spapr_cpu_core.c     |  85 ++++++++++-----
>  hw/ppc/spapr_hcall.c        | 140 +++++++------------------
>  hw/ppc/trace-events         |   2 +-
>  include/hw/ppc/spapr.h      |  12 ++-
>  target-ppc/Makefile.objs    |   2 +-
>  target-ppc/compat.c         | 249 ++++++++++++++++++++++++++++++++++++++++++++
>  target-ppc/cpu.h            |  49 +++++++--
>  target-ppc/excp_helper.c    |  11 +-
>  target-ppc/kvm.c            |   4 +-
>  target-ppc/kvm_ppc.h        |   4 +-
>  target-ppc/machine.c        |  87 ++++++++++++++--
>  target-ppc/translate_init.c | 157 +++++++---------------------
>  13 files changed, 607 insertions(+), 353 deletions(-)
>  create mode 100644 target-ppc/compat.c
> 

  parent reply	other threads:[~2016-11-26  0:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15 22:17 [Qemu-devel] [RFCv2 00/12] Clean up compatibility mode handling David Gibson
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 01/12] pseries: Always use core objects for CPU construction David Gibson
2016-11-18 15:00   ` Greg Kurz
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 02/12] pseries: Make cpu_update during CAS unconditional David Gibson
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 03/12] ppc: Clean up and QOMify hypercall emulation David Gibson
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 04/12] ppc: Rename cpu_version to compat_pvr David Gibson
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 05/12] ppc: Rewrite ppc_set_compat() David Gibson
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 06/12] ppc: Rewrite ppc_get_compat_smt_threads() David Gibson
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 07/12] ppc: Validate compatibility modes when setting David Gibson
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 08/12] pseries: Rewrite CAS PVR compatibility logic David Gibson
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 09/12] ppc: Add ppc_set_compat_all() David Gibson
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 10/12] pseries: Move CPU compatibility property to machine David Gibson
2016-11-19  8:27   ` Greg Kurz
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 11/12] pseries: Reset CPU compatibility mode David Gibson
2016-11-15 22:17 ` [Qemu-devel] [RFCv2 12/12] ppc: Rework CPU compatibility testing across migration David Gibson
2016-12-02 14:48   ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2016-12-05  4:09     ` David Gibson
2016-12-13 17:58       ` Greg Kurz
2016-11-15 22:44 ` [Qemu-devel] [RFCv2 00/12] Clean up compatibility mode handling no-reply
2016-11-26  0:33 ` Greg Kurz [this message]
2016-11-28  4:23   ` David Gibson
2016-11-28  4:25     ` David Gibson
2016-12-01 13:16 ` Greg Kurz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161126013316.069b40b4@bahia \
    --to=groug@kaod.org \
    --cc=abologna@redhat.com \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=clg@kaod.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=lvivier@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).