qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: Alexander Graf <agraf@suse.de>
Cc: "Nikunj A Dadhania" <nikunj@linux.vnet.ibm.com>,
	"Alexey Kardashevskiy" <aik@ozlabs.ru>,
	qemu-devel <qemu-devel@nongnu.org>,
	"open list:PowerPC" <qemu-ppc@nongnu.org>,
	"Anthony Liguori" <anthony@codemonkey.ws>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support
Date: Thu, 5 Sep 2013 21:55:01 +1000	[thread overview]
Message-ID: <20130905115501.GC18222@iris.ozlabs.ibm.com> (raw)
In-Reply-To: <E25C70F9-F7A0-4BD6-BFE7-FAE07E7B5747@suse.de>

On Thu, Sep 05, 2013 at 12:19:09PM +0200, Alexander Graf wrote:
> 
> On 05.09.2013, at 12:16, Paul Mackerras wrote:
> 
> > On Wed, Sep 04, 2013 at 04:32:20PM -0500, Anthony Liguori wrote:
> >> On Wed, Sep 4, 2013 at 8:37 AM, Alexander Graf <agraf@suse.de> wrote:
> >>> 
> >>>> 
> >>>>> So IMHO this whole thing should be orthogonal to -cpu.
> >>>> 
> >>>> Well, since we cannot change CPU class on the fly, yes, it should be a
> >>>> "compatibility" flags/properties/methods/whatever of the default CPU for
> >>>> the specific family.
> >>> 
> >>> Since it's machine global, it could just as well be a machine option, no? Or can you have multiple CPUs with different compat modes in a single system?
> >> 
> >> AFAIK, this has nothing to do with CPUs.
> > 
> > I'm not sure what you mean by that; it has to do with CPUs since it
> > means changing the CPUs' behaviour, at least for user-mode programs.
> > 
> >>>>> Why? Just because you're on POWER7 as default doesn't mean you can't bump to a newer compat later on, no?
> >>>> 
> >>>> Bump when exactly? And it won't be a new compat, it will be a native CPU. I
> >>> 
> >>> If you configure your guest to boot in POWER7-compat mode on your POWER8 box and it then tells you through ibm,client-architecture-support that it can do POWER8, we can just remove all the compat bits and be happy, no?
> > 
> > Answering Alex here -- if we want to preserve the option of migrating
> > to a POWER7 host in future, we would run the guest in POWER7 compat
> > mode even if the current host is a POWER8 and the guest knows about
> > POWER8.
> 
> Yes, so we boot the guest with compat mode set to POWER7, then the guest calls ibm,client-architecutre-support including POWER8 and then we can reconfigure the guest to be POWER8, right?

Not if we want to be able to migrate to a real POWER7 later.  If we
tell the guest it's a POWER8, it will start using POWER8 features, and
then break when we migrate it to a POWER7 where those features don't
exist.  If we run the POWER8 in POWER7 compatibility mode (and more
importantly, the device tree says it's a 2.06 architecture processor),
it should only use POWER7 features and then work just fine when
migrated to a real POWER7.

Paul.

  reply	other threads:[~2013-09-05 11:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-04 10:19 [Qemu-devel] [RFC PATCH] spapr: add initial ibm, client-architecture-support rtas call support Alexey Kardashevskiy
2013-09-04 10:42 ` Alexander Graf
2013-09-04 11:40   ` Alexey Kardashevskiy
2013-09-04 11:54     ` Benjamin Herrenschmidt
2013-09-04 12:59       ` Alexey Kardashevskiy
2013-09-04 12:13     ` Alexander Graf
2013-09-04 13:08       ` Alexey Kardashevskiy
2013-09-04 13:37         ` Alexander Graf
2013-09-04 21:32           ` Anthony Liguori
2013-09-05 10:16             ` Paul Mackerras
2013-09-05 10:19               ` Alexander Graf
2013-09-05 11:55                 ` Paul Mackerras [this message]
2013-09-05 13:04                   ` Alexander Graf

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=20130905115501.GC18222@iris.ozlabs.ibm.com \
    --to=paulus@samba.org \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=anthony@codemonkey.ws \
    --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).