From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: "Andreas Färber" <afaerber@suse.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
Alexander Graf <agraf@suse.de>,
qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
Paul Mackerras <paulus@samba.org>
Subject: Re: [Qemu-devel] [RFC PATCH v4] powerpc: add PVR mask support
Date: Wed, 28 Aug 2013 20:31:22 +1000 [thread overview]
Message-ID: <521DD17A.5050308@ozlabs.ru> (raw)
In-Reply-To: <521B66ED.1010905@suse.de>
On 08/27/2013 12:32 AM, Andreas Färber wrote:
> Am 26.08.2013 15:04, schrieb Alexander Graf:
>>
>> On 19.08.2013, at 06:06, Alexey Kardashevskiy wrote:
>>
>>> IBM POWERPC processors encode PVR as a CPU family in higher 16 bits and
>>> a CPU version in lower 16 bits. Since there is no significant change
>>> in behavior between versions, there is no point to add every single CPU
>>> version in QEMU's CPU list. Also, new CPU versions of already supported
>>> CPU won't break the existing code.
>>>
>>> This does the following:
>>> 1. add a PVR mask support for a CPU family (in this patch for POWER7 only);
>>> 2. make CPU family not abstract;
>>> 3. add a @pvr_default (probably bad name) - the idea when QEMU instantiates
>>> POWERPC CPU from a CPU family class, this value will be written to PVR
>>> before the guest starts; KVM uses this to pass the actual PVR value to
>>> the guest if QEMU was started with -cpu host.
>>>
>>> As CPU family class name for POWER7 is "POWER7-family", there is no need
>>> to touch aliases.
>>>
>>> Cc: Andreas Färber <afaerber@suse.de>
>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>
>>> ---
>>>
>>> This does not pretend to be the final valid patch which can go to any tree
>>> (at least because it does need a POWER7+ family difinition and some bits
>>> for POWER8 family), it is me again asking stupid question in order to
>>> reduce my ignorance and get some understanding if anyone going to care of
>>> the PVR masks problem. Thank you for comments.
>>>
>>> ps. :)
>>> ---
>>> Changes:
>>> v4:
>>> * removed bogus layer from hierarchy
>>>
>>> v3:
>>> * renamed macros to describe the functionality better
>>> * added default PVR value for the powerpc cpu family (what alias used to do)
>>>
>>> v2:
>>> * aliases are replaced with another level in class hierarchy
>>> ---
>>> target-ppc/cpu-models.c | 2 ++
>>> target-ppc/cpu-models.h | 7 +++++++
>>> target-ppc/cpu-qom.h | 2 ++
>>> target-ppc/kvm.c | 2 ++
>>> target-ppc/translate_init.c | 9 +++++++--
>>> 5 files changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/target-ppc/cpu-models.c b/target-ppc/cpu-models.c
>>> index 8dea560..5ae88a5 100644
>>> --- a/target-ppc/cpu-models.c
>>> +++ b/target-ppc/cpu-models.c
>>> @@ -44,6 +44,8 @@
>>> PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc); \
>>> \
>>> pcc->pvr = _pvr; \
>>> + pcc->pvr_default = 0; \
>>
>> There is no need for pvr_default if you limit family instantiation to -cpu host. Just make sure to filter out from cpu ? (and the qmp equivalent) and we should be good.
>
> Matches what I was going to reply.
>
>>> + pcc->pvr_mask = CPU_POWERPC_DEFAULT_MASK; \
>>> pcc->svr = _svr; \
>>> dc->desc = _desc; \
>>> } \
>>> diff --git a/target-ppc/cpu-models.h b/target-ppc/cpu-models.h
>>> index d9145d1..2233053 100644
>>> --- a/target-ppc/cpu-models.h
>>> +++ b/target-ppc/cpu-models.h
>>> @@ -39,6 +39,7 @@ extern PowerPCCPUAlias ppc_cpu_aliases[];
>>> /*****************************************************************************/
>>> /* PVR definitions for most known PowerPC */
>>> enum {
>>> + CPU_POWERPC_DEFAULT_MASK = 0xFFFFFFFF,
>>> /* PowerPC 401 family */
>>> /* Generic PowerPC 401 */
>>> #define CPU_POWERPC_401 CPU_POWERPC_401G2
>>> @@ -557,6 +558,12 @@ enum {
>>> CPU_POWERPC_POWER7_v23 = 0x003F0203,
>>> CPU_POWERPC_POWER7P_v21 = 0x004A0201,
>>> CPU_POWERPC_POWER8_v10 = 0x004B0100,
>>> + CPU_POWERPC_POWER7 = 0x003F0000,
>>> + CPU_POWERPC_POWER7_MASK = 0xFFFF0000,
>>> + CPU_POWERPC_POWER7P = 0x004A0000,
>>> + CPU_POWERPC_POWER7P_MASK = 0xFFFF0000,
>>> + CPU_POWERPC_POWER8 = 0x004B0000,
>>> + CPU_POWERPC_POWER8_MASK = 0xFFFF0000,
>>
>> Please add support for all the other CPUs supported by PR and HV KVM at least on Book3S, but preferably everything Linux supports once this patch is out of RFC.
>
> Personally I didn't see that as a hard requirement - better to start
> somewhere where we are sure than touching everything and finding no one
> to ack. ;)
>
> What I would prefer here is to move the mask before the concrete PVRs
> and possibly to come up with a more telling suffix for the base PVR so
> that it doesn't get mixed up with a "real" PVR.
>
> E.g.,
> CPU_POWERPC_POWER7_BASE = 0x12340000,
> CPU_POWERPC_POWER7_MASK = 0xffff0000,
> CPU_POWERPC_POWER7_V21 = 0x12340201,
> CPU_POWERPC_POWER8_...
>
>>
>>> CPU_POWERPC_970 = 0x00390202,
>>> CPU_POWERPC_970FX_v10 = 0x00391100,
>>> CPU_POWERPC_970FX_v20 = 0x003C0200,
>>> diff --git a/target-ppc/cpu-qom.h b/target-ppc/cpu-qom.h
>>> index f3c710a..a1a712c 100644
>>> --- a/target-ppc/cpu-qom.h
>>> +++ b/target-ppc/cpu-qom.h
>>> @@ -54,6 +54,8 @@ typedef struct PowerPCCPUClass {
>>> void (*parent_reset)(CPUState *cpu);
>>>
>>> uint32_t pvr;
>>> + uint32_t pvr_default;
>>> + uint32_t pvr_mask;
>>> uint32_t svr;
>>> uint64_t insns_flags;
>>> uint64_t insns_flags2;
>>> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
>>> index 30a870e..315e499 100644
>>> --- a/target-ppc/kvm.c
>>> +++ b/target-ppc/kvm.c
>>> @@ -1731,6 +1731,8 @@ static void kvmppc_host_cpu_class_init(ObjectClass *oc, void *data)
>>> uint32_t dcache_size = kvmppc_read_int_cpu_dt("d-cache-size");
>>> uint32_t icache_size = kvmppc_read_int_cpu_dt("i-cache-size");
>>>
>>> + pcc->pvr_default = mfpvr();
>>> +
>>> /* Now fix up the class with information we can query from the host */
>>>
>>> if (vmx != -1) {
>
> This should be moved under the "fix up ... from host" heading. :)
>
>>> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
>>> index 13b290c..dfe398d 100644
>>> --- a/target-ppc/translate_init.c
>>> +++ b/target-ppc/translate_init.c
>>> @@ -3104,7 +3104,6 @@ static int check_pow_hid0_74xx (CPUPPCState *env)
>>> glue(glue(ppc_, _name), _cpu_family_type_info) = { \
>>> .name = stringify(_name) "-family-" TYPE_POWERPC_CPU, \
>>> .parent = TYPE_POWERPC_CPU, \
>>> - .abstract = true, \
>>> .class_init = glue(glue(ppc_, _name), _cpu_family_class_init), \
>>> }; \
>>> \
>
> This should no longer be necessary (once the fuzzy search is implemented
> in KVM host type registration code path) and trivially solves the -cpu ?
> / QMP aspect Alex mentioned above.
I do not really understand this part. Will we still need/want
.abstract==true? I'll post yet another version of my patch in next 3
minutes, there I skip PPC CPU classes which parent is TYPE_POWERPC_CPU,
pretty trivial already :)
--
Alexey
next prev parent reply other threads:[~2013-08-28 10:31 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-15 3:35 [Qemu-devel] [RFC PATCH] powerpc: add PVR mask support Alexey Kardashevskiy
2013-08-15 5:21 ` Alexander Graf
2013-08-15 5:44 ` Alexey Kardashevskiy
2013-08-15 6:03 ` Alexander Graf
2013-08-15 6:30 ` Benjamin Herrenschmidt
2013-08-15 6:39 ` Alexander Graf
2013-08-15 13:12 ` Anthony Liguori
2013-08-15 13:33 ` Alexander Graf
2013-08-15 15:11 ` Andreas Färber
2013-08-15 15:30 ` Alexander Graf
2013-08-15 15:48 ` Andreas Färber
2013-08-15 15:58 ` Alexander Graf
2013-08-15 16:22 ` Andreas Färber
2013-08-15 17:01 ` Alexander Graf
2013-08-15 16:04 ` Anthony Liguori
2013-08-15 5:54 ` Benjamin Herrenschmidt
2013-08-15 6:10 ` Alexander Graf
2013-08-15 6:28 ` Benjamin Herrenschmidt
2013-08-15 6:37 ` Alexander Graf
2013-08-15 6:00 ` [Qemu-devel] [Qemu-ppc] " Alexander Graf
2013-08-15 6:43 ` [Qemu-devel] [_R_F_C_ PATCH v2] " Alexey Kardashevskiy
2013-08-15 6:57 ` Alexander Graf
2013-08-15 7:45 ` [Qemu-devel] [RFC PATCH v3] " Alexey Kardashevskiy
2013-08-15 7:55 ` Alexander Graf
2013-08-15 8:06 ` Alexey Kardashevskiy
2013-08-15 8:45 ` Alexander Graf
2013-08-15 10:52 ` Andreas Färber
2013-08-15 11:03 ` Alexander Graf
2013-08-15 11:48 ` Andreas Färber
2013-08-15 11:59 ` Alexander Graf
2013-08-19 17:13 ` Andreas Färber
2013-08-15 13:55 ` Alexey Kardashevskiy
2013-08-15 14:47 ` Andreas Färber
2013-08-15 15:29 ` Alexander Graf
2013-08-15 15:43 ` Andreas Färber
2013-08-15 15:51 ` Alexander Graf
2013-08-15 16:08 ` Andreas Färber
2013-08-15 16:17 ` Alexander Graf
2013-08-16 0:20 ` Benjamin Herrenschmidt
2013-08-16 0:28 ` Anthony Liguori
2013-08-16 0:30 ` Benjamin Herrenschmidt
2013-08-19 17:34 ` Andreas Färber
2013-08-16 8:07 ` Alexey Kardashevskiy
2013-08-19 4:06 ` [Qemu-devel] [RFC PATCH v4] " Alexey Kardashevskiy
2013-08-26 13:04 ` Alexander Graf
2013-08-26 14:32 ` Andreas Färber
2013-08-28 10:31 ` Alexey Kardashevskiy [this message]
2013-08-28 10:34 ` Andreas Färber
2013-08-15 14:43 ` [Qemu-devel] [RFC PATCH v3] " Alexey Kardashevskiy
2013-08-15 15:17 ` 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=521DD17A.5050308@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aliguori@us.ibm.com \
--cc=paulus@samba.org \
--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).