qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Paul Mackerras <paulus@samba.org>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Stuart Yoder <stuart.yoder@freescale.com>,
	Alexey Kardashevskiy <aik@ozlabs.ru>,
	qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
	qemu-ppc@nongnu.org, Scott Wood <scottwood@freescale.com>
Subject: Re: [Qemu-devel] [PATCH] target-ppc: Add POWER7+ CPU model
Date: Mon, 05 Aug 2013 10:24:53 +0200	[thread overview]
Message-ID: <51FF6155.2060505@suse.de> (raw)
In-Reply-To: <20130805054341.GE19254@iris.ozlabs.ibm.com>

Am 05.08.2013 07:43, schrieb Paul Mackerras:
> On Fri, Aug 02, 2013 at 06:14:46PM +0200, Andreas Färber wrote:
>> Am 02.08.2013 04:59, schrieb Alexey Kardashevskiy:
>>> This patch adds CPU PVR definition for POWER7+.
>>>
>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>> ---
>>>  target-ppc/cpu-models.c | 2 ++
>>>  target-ppc/cpu-models.h | 1 +
>>>  2 files changed, 3 insertions(+)
>>>
>>> diff --git a/target-ppc/cpu-models.c b/target-ppc/cpu-models.c
>>> index 9578ed8..c97c183 100644
>>> --- a/target-ppc/cpu-models.c
>>> +++ b/target-ppc/cpu-models.c
>>> @@ -1143,6 +1143,8 @@
>>>                  "POWER7 v2.1")
>>>      POWERPC_DEF("POWER7_v2.3",   CPU_POWERPC_POWER7_v23,             POWER7,
>>>                  "POWER7 v2.3")
>>> +    POWERPC_DEF("POWER7P",       CPU_POWERPC_POWER7P,                POWER7,
>>> +                "POWER7P")
>>
>> Subject says POWER7+ rather than POWER7P. Since this is a string there's
>> nothing wrong with +. How should it show up in SLOF?
> 
> Do you mean in the device tree?  The children of the /cpus node should
> be named like "PowerPC,POWER7+@xxx".

Thanks.

>> See also below.
>>
>>>      POWERPC_DEF("POWER8_v1.0",   CPU_POWERPC_POWER8_v10,             POWER8,
>>>                  "POWER8 v1.0")
>>>      POWERPC_DEF("970",           CPU_POWERPC_970,                    970,
>>> diff --git a/target-ppc/cpu-models.h b/target-ppc/cpu-models.h
>>> index 01e488f..c3c78d1 100644
>>> --- a/target-ppc/cpu-models.h
>>> +++ b/target-ppc/cpu-models.h
>>> @@ -556,6 +556,7 @@ enum {
>>>      CPU_POWERPC_POWER7_v20         = 0x003F0200,
>>>      CPU_POWERPC_POWER7_v21         = 0x003F0201,
>>>      CPU_POWERPC_POWER7_v23         = 0x003F0203,
>>> +    CPU_POWERPC_POWER7P            = 0x004A0201,
>>
>> Shouldn't this be ..._POWER7P_v21 to align with the surrounding models?
>> Ditto for the model name then, POWER7+ being an alias to the latest
>> version only.
> 
> Does the fact that all these minor revisions are enumerated imply that
> QEMU is always matching all the bits of the PVR value?

Yes, see target-ppc/kvm.c.

>  If so then
> that seems very fragile to me, given that QEMU looks at the host's PVR
> value when using KVM.  All it takes is for IBM to release a new minor
> revision of a CPU to break existing compiled versions of qemu
> (e.g. from a distro).

>  Wouldn't it be better to be able to match only
> the top 16 bits, at least for the situations where there is no
> architectural or significant behavioural change between the versions?

Not being the ppc maintainer, I can only point out that this is how QEMU
works today and that, independently, it makes sense to name the PVR and
model after the revision they encode for self-documentation.

Ben has pointed out that POWER5++ PVR-wise was a POWER5+ v3.0+ or so
and, according to you, POWER5++ is not just a revision with
hardware-only changes and a new marketing name. So no, it's not always
just the upper 16 bits.

For e500v1/v2 the revision appears to be encoded in the two least
significant nibbles rather than in the two least significant bytes.
For e300 it's in the second most significant byte.
For the 405/440 models it's not linear from a to b to c at all.
Cf. target-ppc/cpu-models.h.

If we wanted to make our matching less precise, we'd need to specify an
explicit wildcard per model. And we can only match known models, i.e. up
to v2.1 as long as we don't know whether v2.2 or v3.0 will have the same
guest-exposed/emulation features (in which case we could've picked them
instead), because otherwise we'd need a versioning mechanism like x86
has, to avoid guest-visible CPU features changing between releases once
we do know what features new revisions have.

Also, if we stopped modeling exact revisions, it may be a good idea to
add properties to the PowerPCCPU to specify a particular major/minor
revision within the wildcard. We may need to limit such properties to
IBM's CPU models since apparently that scheme does not apply to all
PVRs. CC'ing Scott and Stuart.

Examples:
-device POWER7+-powerpc64-cpu,major-revision=2,minor-revision=0
-device POWER7+-powerpc64-cpu,pvr=0x12345678

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

  reply	other threads:[~2013-08-05  8:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-02  2:59 [Qemu-devel] [PATCH] target-ppc: Add POWER7+ CPU model Alexey Kardashevskiy
2013-08-02 16:14 ` Andreas Färber
2013-08-05  5:43   ` Paul Mackerras
2013-08-05  8:24     ` Andreas Färber [this message]
2013-08-05  9:15       ` Benjamin Herrenschmidt
2013-08-14 16:28 ` Anthony Liguori

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=51FF6155.2060505@suse.de \
    --to=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=aliguori@us.ibm.com \
    --cc=paulus@samba.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=scottwood@freescale.com \
    --cc=stuart.yoder@freescale.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).