From: Russell Currey <hidden> Date: 2017-02-17 02:01:47
PVR value of 0x0F000005 means we are arch v3.00 compliant (i.e. POWER9).
Acked-by: Michael Neuling <redacted>
Signed-off-by: Russell Currey <redacted>
---
arch/powerpc/kernel/cputable.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-02-17 10:11:17
Daniel Axtens [off-list ref] writes:
Hi Russell,
This seems to go Power8, Power9, Power7 - is that intentional?
Regards,
Daniel
quoted
.platform = "power8",
...
quoted
+ .platform = "power9",
...
quoted
{ /* Power7 */
It's because we have the architected PVRs and the raw ones, and the
ordering is a bit odd:
$ grep -n -e '(architected)' -e '(raw)' arch/powerpc/kernel/cputable.c
323: .cpu_name = "POWER6 (raw)",
343: .cpu_name = "POWER6 (architected)",
356: .cpu_name = "POWER7 (architected)",
374: .cpu_name = "POWER8 (architected)",
392: .cpu_name = "POWER9 (architected)",
411: .cpu_name = "POWER7 (raw)",
431: .cpu_name = "POWER7+ (raw)",
451: .cpu_name = "POWER8E (raw)",
471: .cpu_name = "POWER8NVL (raw)",
491: .cpu_name = "POWER8 (raw)",
511: .cpu_name = "POWER8 (raw)",
531: .cpu_name = "POWER9 (raw)",
550: .cpu_name = "POWER9 (raw)",
But I don't think it matters in practice. The architected entries use a
pvr_mask of 0xffffffff so it has to be an exact match.
cheers
It's important *not* to set num_pmcs for the architected PVRs.
See the comment in setup_cpu_spec():
/*
* If we are overriding a previous value derived from the real
* PVR with a new value obtained using a logical PVR value,
* don't modify the performance monitor fields.
*/
if (old.num_pmcs && !s->num_pmcs) {
t->num_pmcs = old.num_pmcs;
t->pmc_type = old.pmc_type;
I realise that having that requirement in the code is serious foot gun
material on our part, but c'est la vie.
The reason we do that is there's no "compat mode" for the PMU. So if you
boot on a Power9, and then the logical PVR says "actually pretend you're
on a Power8", we flip most of the cpu_spec to have the Power8 values,
but *not* the PMU fields. That way the Power9 PMU code will still detect
that it's on a Power9 and work correctly.
Possibly now that oprofile is more or less dead we can rip all that crap
out, and have perf just look at the PVR directly.
cheers
It's important *not* to set num_pmcs for the architected PVRs.
See the comment in setup_cpu_spec():
/*
* If we are overriding a previous value derived from the real
* PVR with a new value obtained using a logical PVR value,
* don't modify the performance monitor fields.
*/
if (old.num_pmcs && !s->num_pmcs) {
t->num_pmcs = old.num_pmcs;
t->pmc_type = old.pmc_type;
I realise that having that requirement in the code is serious foot gun
material on our part, but c'est la vie.
The reason we do that is there's no "compat mode" for the PMU. So if you
boot on a Power9, and then the logical PVR says "actually pretend you're
on a Power8", we flip most of the cpu_spec to have the Power8 values,
but *not* the PMU fields. That way the Power9 PMU code will still detect
that it's on a Power9 and work correctly.
Possibly now that oprofile is more or less dead we can rip all that crap
out, and have perf just look at the PVR directly.
Thanks a lot for explaining, that's interesting. I thought it might just have
been an accidental omission in the architected entries but I should've dug
deeper.
It's important *not* to set num_pmcs for the architected PVRs.
See the comment in setup_cpu_spec():
/*
* If we are overriding a previous value derived from the real
* PVR with a new value obtained using a logical PVR value,
* don't modify the performance monitor fields.
*/
if (old.num_pmcs && !s->num_pmcs) {
t->num_pmcs = old.num_pmcs;
t->pmc_type = old.pmc_type;
I realise that having that requirement in the code is serious foot gun
material on our part, but c'est la vie.
The reason we do that is there's no "compat mode" for the PMU. So if you
boot on a Power9, and then the logical PVR says "actually pretend you're
on a Power8", we flip most of the cpu_spec to have the Power8 values,
but *not* the PMU fields. That way the Power9 PMU code will still detect
that it's on a Power9 and work correctly.
Possibly now that oprofile is more or less dead we can rip all that crap
out, and have perf just look at the PVR directly.
Oh and also, do you want me to respin or are you happy to drop it on your end?
- Russell
=20
It's important *not* to set num_pmcs for the architected PVRs.
...
Oh and also, do you want me to respin or are you happy to drop it on your=
end?
I fixed it up:
commit 6ae3f8ad2017079292cb49c8959b527bcbcbefed
Author: Russell Currey [off-list ref]
AuthorDate: Fri Feb 17 13:01:35 2017 +1100
Commit: Michael Ellerman [off-list ref]
CommitDate: Fri Feb 17 21:48:56 2017 +1100
powerpc: Add POWER9 architected mode to cputable
=20=20=20=20
PVR value of 0x0F000005 means we are arch v3.00 compliant (i.e. POWER9).
=20=20=20=20
Acked-by: Michael Neuling [off-list ref]
Signed-off-by: Russell Currey [off-list ref]
[mpe: Don't set num_pmcs, so we keep the PMU fields from the raw entry]
Signed-off-by: Michael Ellerman [off-list ref]