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, abologna@redhat.com,
	armbru@redhat.com, qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [PATCHv3 0/4] Clean up compatibility mode handling
Date: Fri, 28 Apr 2017 11:29:22 +0200	[thread overview]
Message-ID: <20170428112922.6a7ecc53@bahia> (raw)
In-Reply-To: <20170427072843.8089-1-david@gibson.dropbear.id.au>

[-- Attachment #1: Type: text/plain, Size: 5680 bytes --]

On Thu, 27 Apr 2017 17:28:39 +1000
David Gibson <david@gibson.dropbear.id.au> 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.
> 
>  * 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')
> 
>  * 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.
> 
> This hasn't been extensively tested yet.  There are quite a few
> migration cases to consider, for example:
> 

Hi David,

I'll rerun the tests shortly.

Cheers,

--
Greg

> Basic:
> 
> 1) Boot guest with -cpu host
>         Should go into POWER8 compat mode after CAS
>         Previously would have been raw mode
> 
> 2) Boot guest with -machine pseries,max-cpu-compat=power7 -cpu host
>         Should go into POWER7 compat mode
> 
> 3) Boot guest with -cpu host,compat=power7
>         Should act as (2), but print a warning
> 
> 4) Boot guest via libvirt with power7 compat mode specified in XML
>         Should act as (3), (2) once we fix libvirt
> 
> 5) Hack guest to only advertise power7 compatibility, boot with -cpu host
>         Should go into POWER7 compat mode after CAS
> 
> 6) Hack guest to only advertise real PVRs
>         Should remain in POWER8 raw mode after CAS
> 
> 7) Hack guest to only advertise real PVRs
>    Boot with -machine pseries,max-cpu-compat=power8
>         Should fail at CAS time
> 
> 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
> 
> Migration:
> 
> 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 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
> 
> 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 (3):
>   pseries: Move CPU compatibility property to machine
>   pseries: Reset CPU compatibility mode
>   ppc: Rework CPU compatibility testing across migration
> 
> Greg Kurz (1):
>   qapi: add explicit null to string input and output visitors
> 
>  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(-)
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  parent reply	other threads:[~2017-04-28  9:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27  7:28 [Qemu-devel] [PATCHv3 0/4] Clean up compatibility mode handling David Gibson
2017-04-27  7:28 ` [Qemu-devel] [PATCHv3 1/4] qapi: add explicit null to string input and output visitors David Gibson
2017-05-02 11:48   ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2017-04-27  7:28 ` [Qemu-devel] [PATCHv3 2/4] pseries: Move CPU compatibility property to machine David Gibson
2017-04-27 17:23   ` Michael Roth
2017-05-01  2:33     ` David Gibson
2017-05-02 11:23       ` Greg Kurz
2017-05-02 14:24   ` Greg Kurz
2017-05-26  1:24     ` David Gibson
2017-05-04 10:06   ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2017-05-04 17:09   ` [Qemu-devel] " Andrea Bolognani
2017-05-04 18:50     ` Greg Kurz
2017-05-12  7:08       ` David Gibson
2017-05-26  2:10     ` David Gibson
2017-04-27  7:28 ` [Qemu-devel] [PATCHv3 3/4] pseries: Reset CPU compatibility mode David Gibson
2017-04-27 18:08   ` Michael Roth
2017-04-27  7:28 ` [Qemu-devel] [PATCHv3 4/4] ppc: Rework CPU compatibility testing across migration David Gibson
2017-04-27 19:51   ` Michael Roth
2017-05-01  6:48     ` David Gibson
2017-05-26  3:40     ` David Gibson
2017-05-04 10:07   ` Greg Kurz
2017-05-26  4:16     ` David Gibson
2017-05-29 10:51       ` Greg Kurz
2017-04-27  8:04 ` [Qemu-devel] [PATCHv3 0/4] Clean up compatibility mode handling no-reply
2017-04-28  9:29 ` Greg Kurz [this message]
2017-05-03 18:03 ` Greg Kurz
2017-05-04 14:32 ` Andrea Bolognani
2017-05-04 19:22   ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2017-05-12  7:33     ` David Gibson
2017-05-12  8:33       ` Andrea Bolognani

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=20170428112922.6a7ecc53@bahia \
    --to=groug@kaod.org \
    --cc=abologna@redhat.com \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=armbru@redhat.com \
    --cc=clg@kaod.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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).