* Re: [PATCH v2 4/5] powerpc/sysfs: Show idle_purr and idle_spurr for every CPU
From: Nathan Lynch @ 2020-02-21 16:50 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Tyrel Datwyler, linux-kernel, Kamalesh Babulal, Naveen N. Rao,
Vaidyanathan Srinivasan, linuxppc-dev
In-Reply-To: <1582262314-8319-5-git-send-email-ego@linux.vnet.ibm.com>
"Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index 80a676d..5b4b450 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -19,6 +19,7 @@
> #include <asm/smp.h>
> #include <asm/pmc.h>
> #include <asm/firmware.h>
> +#include <asm/idle.h>
> #include <asm/svm.h>
>
> #include "cacheinfo.h"
> @@ -733,6 +734,42 @@ static void create_svm_file(void)
> }
> #endif /* CONFIG_PPC_SVM */
>
> +static void read_idle_purr(void *val)
> +{
> + u64 *ret = (u64 *)val;
No cast from void* needed.
> +
> + *ret = read_this_idle_purr();
> +}
> +
> +static ssize_t idle_purr_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct cpu *cpu = container_of(dev, struct cpu, dev);
> + u64 val;
> +
> + smp_call_function_single(cpu->dev.id, read_idle_purr, &val, 1);
> + return sprintf(buf, "%llx\n", val);
> +}
> +static DEVICE_ATTR(idle_purr, 0400, idle_purr_show, NULL);
> +
> +static void read_idle_spurr(void *val)
> +{
> + u64 *ret = (u64 *)val;
> +
> + *ret = read_this_idle_spurr();
> +}
> +
> +static ssize_t idle_spurr_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct cpu *cpu = container_of(dev, struct cpu, dev);
> + u64 val;
> +
> + smp_call_function_single(cpu->dev.id, read_idle_spurr, &val, 1);
> + return sprintf(buf, "%llx\n", val);
> +}
> +static DEVICE_ATTR(idle_spurr, 0400, idle_spurr_show, NULL);
It's regrettable that we have to wake up potentially idle CPUs in order
to derive correct idle statistics for them, but I suppose the main user
(lparstat) of these interfaces already is causing this to happen by
polling the existing per-cpu purr and spurr attributes.
So now lparstat will incur at minimum four syscalls and four IPIs per
CPU per polling interval -- one for each of purr, spurr, idle_purr and
idle_spurr. Correct?
At some point it's going to make sense to batch sampling of remote CPUs'
SPRs.
> static int register_cpu_online(unsigned int cpu)
> {
> struct cpu *c = &per_cpu(cpu_devices, cpu);
> @@ -794,10 +831,15 @@ static int register_cpu_online(unsigned int cpu)
> if (!firmware_has_feature(FW_FEATURE_LPAR))
> add_write_permission_dev_attr(&dev_attr_purr);
> device_create_file(s, &dev_attr_purr);
> + if (firmware_has_feature(FW_FEATURE_LPAR))
> + device_create_file(s, &dev_attr_idle_purr);
> }
>
> - if (cpu_has_feature(CPU_FTR_SPURR))
> + if (cpu_has_feature(CPU_FTR_SPURR)) {
> device_create_file(s, &dev_attr_spurr);
> + if (firmware_has_feature(FW_FEATURE_LPAR))
> + device_create_file(s, &dev_attr_idle_spurr);
> + }
>
> if (cpu_has_feature(CPU_FTR_DSCR))
> device_create_file(s, &dev_attr_dscr);
> @@ -879,11 +921,17 @@ static int unregister_cpu_online(unsigned int cpu)
> if (cpu_has_feature(CPU_FTR_MMCRA))
> device_remove_file(s, &dev_attr_mmcra);
>
> - if (cpu_has_feature(CPU_FTR_PURR))
> + if (cpu_has_feature(CPU_FTR_PURR)) {
> device_remove_file(s, &dev_attr_purr);
> + if (firmware_has_feature(FW_FEATURE_LPAR))
> + device_remove_file(s, &dev_attr_idle_purr);
> + }
>
> - if (cpu_has_feature(CPU_FTR_SPURR))
> + if (cpu_has_feature(CPU_FTR_SPURR)) {
> device_remove_file(s, &dev_attr_spurr);
> + if (firmware_has_feature(FW_FEATURE_LPAR))
> + device_remove_file(s, &dev_attr_idle_spurr);
> + }
>
> if (cpu_has_feature(CPU_FTR_DSCR))
> device_remove_file(s, &dev_attr_dscr);
The cpu register/unregister stuff here looks correct.
^ permalink raw reply
* Re: [PATCH v2 3/5] powerpc/pseries: Account for SPURR ticks on idle CPUs
From: Nathan Lynch @ 2020-02-21 16:47 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Tyrel Datwyler, linux-kernel, Kamalesh Babulal, Naveen N. Rao,
Vaidyanathan Srinivasan, linuxppc-dev
In-Reply-To: <1582262314-8319-4-git-send-email-ego@linux.vnet.ibm.com>
"Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> +static inline void snapshot_spurr_idle_entry(void)
> +{
> + *this_cpu_ptr(&idle_entry_spurr_snap) = mfspr(SPRN_SPURR);
> +}
> +
[...]
> +static inline void update_idle_spurr_accounting(void)
> +{
> + u64 *idle_spurr_cycles_ptr = this_cpu_ptr(&idle_spurr_cycles);
> + u64 in_spurr = *this_cpu_ptr(&idle_entry_spurr_snap);
> +
> + *idle_spurr_cycles_ptr += mfspr(SPRN_SPURR) - in_spurr;
> +}
[...]
> +static inline u64 read_this_idle_spurr(void)
> +{
> + /*
> + * If we are reading from an idle context, update the
> + * idle-spurr cycles corresponding to the last idle period.
> + * Since the idle context is not yet over, take a fresh
> + * snapshot of the idle-spurr.
> + */
> + if (get_lppaca()->idle == 1) {
> + update_idle_spurr_accounting();
> + snapshot_spurr_idle_entry();
This samples spurr twice when it could do with just one. I don't know
the performance implications, but will the results be coherent?
^ permalink raw reply
* [PATCH v3] KVM: PPC: Book3S HV: Treat TM-related invalid form instructions on P9 like the valid ones
From: Gustavo Romero @ 2020-02-21 16:29 UTC (permalink / raw)
To: kvm-ppc, paulus; +Cc: leonardo, mikey, linuxppc-dev, gromero
On P9 DD2.2 due to a CPU defect some TM instructions need to be emulated by
KVM. This is handled at first by the hardware raising a softpatch interrupt
when certain TM instructions that need KVM assistance are executed in the
guest. Althought some TM instructions per Power ISA are invalid forms they
can raise a softpatch interrupt too. For instance, 'tresume.' instruction
as defined in the ISA must have bit 31 set (1), but an instruction that
matches 'tresume.' PO and XO opcode fields but has bit 31 not set (0), like
0x7cfe9ddc, also raises a softpatch interrupt. Similarly for 'treclaim.'
and 'trechkpt.' instructions with bit 31 = 0, i.e. 0x7c00075c and
0x7c0007dc, respectively. Hence, if a code like the following is executed
in the guest it will raise a softpatch interrupt just like a 'tresume.'
when the TM facility is enabled ('tabort. 0' in the example is used only
to enable the TM facility):
int main() { asm("tabort. 0; .long 0x7cfe9ddc;"); }
Currently in such a case KVM throws a complete trace like:
[345523.705984] WARNING: CPU: 24 PID: 64413 at arch/powerpc/kvm/book3s_hv_tm.c:211 kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
[345523.705985] Modules linked in: kvm_hv(E) xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat
iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ebtable_filter ebtables ip6table_filter
ip6_tables iptable_filter bridge stp llc sch_fq_codel ipmi_powernv at24 vmx_crypto ipmi_devintf ipmi_msghandler
ibmpowernv uio_pdrv_genirq kvm opal_prd uio leds_powernv ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp
libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear tg3
crct10dif_vpmsum crc32c_vpmsum ipr [last unloaded: kvm_hv]
[345523.706030] CPU: 24 PID: 64413 Comm: CPU 0/KVM Tainted: G W E 5.5.0+ #1
[345523.706031] NIP: c0080000072cb9c0 LR: c0080000072b5e80 CTR: c0080000085c7850
[345523.706034] REGS: c000000399467680 TRAP: 0700 Tainted: G W E (5.5.0+)
[345523.706034] MSR: 900000010282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 24022428 XER: 00000000
[345523.706042] CFAR: c0080000072b5e7c IRQMASK: 0
GPR00: c0080000072b5e80 c000000399467910 c0080000072db500 c000000375ccc720
GPR04: c000000375ccc720 00000003fbec0000 0000a10395dda5a6 0000000000000000
GPR08: 000000007cfe9ddc 7cfe9ddc000005dc 7cfe9ddc7c0005dc c0080000072cd530
GPR12: c0080000085c7850 c0000003fffeb800 0000000000000001 00007dfb737f0000
GPR16: c0002001edcca558 0000000000000000 0000000000000000 0000000000000001
GPR20: c000000001b21258 c0002001edcca558 0000000000000018 0000000000000000
GPR24: 0000000001000000 ffffffffffffffff 0000000000000001 0000000000001500
GPR28: c0002001edcc4278 c00000037dd80000 800000050280f033 c000000375ccc720
[345523.706062] NIP [c0080000072cb9c0] kvmhv_p9_tm_emulation+0x68/0x620 [kvm_hv]
[345523.706065] LR [c0080000072b5e80] kvmppc_handle_exit_hv.isra.53+0x3e8/0x798 [kvm_hv]
[345523.706066] Call Trace:
[345523.706069] [c000000399467910] [c000000399467940] 0xc000000399467940 (unreliable)
[345523.706071] [c000000399467950] [c000000399467980] 0xc000000399467980
[345523.706075] [c0000003994679f0] [c0080000072bd1c4] kvmhv_run_single_vcpu+0xa1c/0xb80 [kvm_hv]
[345523.706079] [c000000399467ac0] [c0080000072bd8e0] kvmppc_vcpu_run_hv+0x5b8/0xb00 [kvm_hv]
[345523.706087] [c000000399467b90] [c0080000085c93cc] kvmppc_vcpu_run+0x34/0x48 [kvm]
[345523.706095] [c000000399467bb0] [c0080000085c582c] kvm_arch_vcpu_ioctl_run+0x244/0x420 [kvm]
[345523.706101] [c000000399467c40] [c0080000085b7498] kvm_vcpu_ioctl+0x3d0/0x7b0 [kvm]
[345523.706105] [c000000399467db0] [c0000000004adf9c] ksys_ioctl+0x13c/0x170
[345523.706107] [c000000399467e00] [c0000000004adff8] sys_ioctl+0x28/0x80
[345523.706111] [c000000399467e20] [c00000000000b278] system_call+0x5c/0x68
[345523.706112] Instruction dump:
[345523.706114] 419e0390 7f8a4840 409d0048 6d497c00 2f89075d 419e021c 6d497c00 2f8907dd
[345523.706119] 419e01c0 6d497c00 2f8905dd 419e00a4 <0fe00000> 38210040 38600000 ebc1fff0
and then treats the executed instruction as a 'nop'.
However the POWER9 User's Manual, in section "4.6.10 Book II Invalid
Forms", informs that for TM instructions bit 31 is in fact ignored, thus
for the TM-related invalid forms ignoring bit 31 and handling them like the
valid forms is an acceptable way to handle them. POWER8 behaves the same
way too.
This commit changes the handling of the cases here described by treating
the TM-related invalid forms that can generate a softpatch interrupt
just like their valid forms (w/ bit 31 = 1) instead of as a 'nop' and by
gently reporting any other unrecognized case to the host and treating it as
illegal instruction instead of throwing a trace and treating it as a 'nop'.
Signed-off-by: Gustavo Romero <gromero@linux.ibm.com>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Acked-By: Michael Neuling <mikey@neuling.org>
Reviewed-by: Leonardo Bras <leonardo@linux.ibm.com>
---
arch/powerpc/include/asm/kvm_asm.h | 3 +++
arch/powerpc/kvm/book3s_hv_tm.c | 28 ++++++++++++++++++++-----
arch/powerpc/kvm/book3s_hv_tm_builtin.c | 16 ++++++++++++--
3 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_asm.h b/arch/powerpc/include/asm/kvm_asm.h
index 635fb154b33f..a3633560493b 100644
--- a/arch/powerpc/include/asm/kvm_asm.h
+++ b/arch/powerpc/include/asm/kvm_asm.h
@@ -150,4 +150,7 @@
#define KVM_INST_FETCH_FAILED -1
+/* Extract PO and XOP opcode fields */
+#define PO_XOP_OPCODE_MASK 0xfc0007fe
+
#endif /* __POWERPC_KVM_ASM_H__ */
diff --git a/arch/powerpc/kvm/book3s_hv_tm.c b/arch/powerpc/kvm/book3s_hv_tm.c
index 0db937497169..cc90b8b82329 100644
--- a/arch/powerpc/kvm/book3s_hv_tm.c
+++ b/arch/powerpc/kvm/book3s_hv_tm.c
@@ -3,6 +3,8 @@
* Copyright 2017 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/kvm_host.h>
#include <asm/kvm_ppc.h>
@@ -44,7 +46,18 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
u64 newmsr, bescr;
int ra, rs;
- switch (instr & 0xfc0007ff) {
+ /*
+ * rfid, rfebb, and mtmsrd encode bit 31 = 0 since it's a reserved bit
+ * in these instructions, so masking bit 31 out doesn't change these
+ * instructions. For treclaim., tsr., and trechkpt. instructions if bit
+ * 31 = 0 then they are per ISA invalid forms, however P9 UM, in section
+ * 4.6.10 Book II Invalid Forms, informs specifically that ignoring bit
+ * 31 is an acceptable way to handle these invalid forms that have
+ * bit 31 = 0. Moreover, for emulation purposes both forms (w/ and wo/
+ * bit 31 set) can generate a softpatch interrupt. Hence both forms
+ * are handled below for these instructions so they behave the same way.
+ */
+ switch (instr & PO_XOP_OPCODE_MASK) {
case PPC_INST_RFID:
/* XXX do we need to check for PR=0 here? */
newmsr = vcpu->arch.shregs.srr1;
@@ -105,7 +118,8 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
vcpu->arch.shregs.msr = newmsr;
return RESUME_GUEST;
- case PPC_INST_TSR:
+ /* ignore bit 31, see comment above */
+ case (PPC_INST_TSR & PO_XOP_OPCODE_MASK):
/* check for PR=1 and arch 2.06 bit set in PCR */
if ((msr & MSR_PR) && (vcpu->arch.vcore->pcr & PCR_ARCH_206)) {
/* generate an illegal instruction interrupt */
@@ -140,7 +154,8 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
vcpu->arch.shregs.msr = msr;
return RESUME_GUEST;
- case PPC_INST_TRECLAIM:
+ /* ignore bit 31, see comment above */
+ case (PPC_INST_TRECLAIM & PO_XOP_OPCODE_MASK):
/* check for TM disabled in the HFSCR or MSR */
if (!(vcpu->arch.hfscr & HFSCR_TM)) {
/* generate an illegal instruction interrupt */
@@ -176,7 +191,8 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
vcpu->arch.shregs.msr &= ~MSR_TS_MASK;
return RESUME_GUEST;
- case PPC_INST_TRECHKPT:
+ /* ignore bit 31, see comment above */
+ case (PPC_INST_TRECHKPT & PO_XOP_OPCODE_MASK):
/* XXX do we need to check for PR=0 here? */
/* check for TM disabled in the HFSCR or MSR */
if (!(vcpu->arch.hfscr & HFSCR_TM)) {
@@ -208,6 +224,8 @@ int kvmhv_p9_tm_emulation(struct kvm_vcpu *vcpu)
}
/* What should we do here? We didn't recognize the instruction */
- WARN_ON_ONCE(1);
+ kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
+ pr_warn_ratelimited("Unrecognized TM-related instruction %#x for emulation", instr);
+
return RESUME_GUEST;
}
diff --git a/arch/powerpc/kvm/book3s_hv_tm_builtin.c b/arch/powerpc/kvm/book3s_hv_tm_builtin.c
index 217246279dfa..fad931f224ef 100644
--- a/arch/powerpc/kvm/book3s_hv_tm_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_tm_builtin.c
@@ -23,7 +23,18 @@ int kvmhv_p9_tm_emulation_early(struct kvm_vcpu *vcpu)
u64 newmsr, msr, bescr;
int rs;
- switch (instr & 0xfc0007ff) {
+ /*
+ * rfid, rfebb, and mtmsrd encode bit 31 = 0 since it's a reserved bit
+ * in these instructions, so masking bit 31 out doesn't change these
+ * instructions. For the tsr. instruction if bit 31 = 0 then it is per
+ * ISA an invalid form, however P9 UM, in section 4.6.10 Book II Invalid
+ * Forms, informs specifically that ignoring bit 31 is an acceptable way
+ * to handle TM-related invalid forms that have bit 31 = 0. Moreover,
+ * for emulation purposes both forms (w/ and wo/ bit 31 set) can
+ * generate a softpatch interrupt. Hence both forms are handled below
+ * for tsr. to make them behave the same way.
+ */
+ switch (instr & PO_XOP_OPCODE_MASK) {
case PPC_INST_RFID:
/* XXX do we need to check for PR=0 here? */
newmsr = vcpu->arch.shregs.srr1;
@@ -73,7 +84,8 @@ int kvmhv_p9_tm_emulation_early(struct kvm_vcpu *vcpu)
vcpu->arch.shregs.msr = newmsr;
return 1;
- case PPC_INST_TSR:
+ /* ignore bit 31, see comment above */
+ case (PPC_INST_TSR & PO_XOP_OPCODE_MASK):
/* we know the MSR has the TS field = S (0b01) here */
msr = vcpu->arch.shregs.msr;
/* check for PR=1 and arch 2.06 bit set in PCR */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 00/27] Add support for OpenCAPI Persistent Memory devices
From: Dan Williams @ 2020-02-21 16:24 UTC (permalink / raw)
To: Alastair D'Silva
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Mahesh Salgaonkar,
Masahiro Yamada, Oliver O'Halloran, Mauro Carvalho Chehab,
Ira Weiny, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
alastair, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Thomas Gleixner,
Hari Bathini, Linux MM, Greg Kroah-Hartman,
Linux Kernel Mailing List, Vishal Verma, Frederic Barrat,
Paul Mackerras, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <CAPcyv4j2hut1YDrotC=QkcM+S0SZwpd9_4hD2aChn+cKD+62oA@mail.gmail.com>
On Fri, Feb 21, 2020 at 8:21 AM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Thu, Feb 20, 2020 at 7:28 PM Alastair D'Silva <alastair@au1.ibm.com> wrote:
> >
> > From: Alastair D'Silva <alastair@d-silva.org>
> >
> > This series adds support for OpenCAPI Persistent Memory devices, exposing
> > them as nvdimms so that we can make use of the existing infrastructure.
>
> A single sentence to introduce:
>
> 24 files changed, 3029 insertions(+), 97 deletions(-)
>
> ...is inadequate. What are OpenCAPI Persistent Memory devices? How do
> they compare, in terms relevant to libnvdimm, to other persistent
> memory devices? What challenges do they pose to the existing enabling?
> What is the overall approach taken with this 27 patch break down? What
> are the changes since v2, v1? If you incorporated someone's review
> feedback note it in the cover letter changelog, if you didn't
Assumptions and tradeoffs the implementation considered are also
critical for reviewing the approach.
^ permalink raw reply
* Re: [PATCH v3 00/27] Add support for OpenCAPI Persistent Memory devices
From: Dan Williams @ 2020-02-21 16:21 UTC (permalink / raw)
To: Alastair D'Silva
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Mahesh Salgaonkar,
Masahiro Yamada, Oliver O'Halloran, Mauro Carvalho Chehab,
Ira Weiny, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
alastair, Andrew Donnellan, Arnd Bergmann, Greg Kurz,
Nicholas Piggin, Cédric Le Goater, Thomas Gleixner,
Hari Bathini, Linux MM, Greg Kroah-Hartman,
Linux Kernel Mailing List, Vishal Verma, Frederic Barrat,
Paul Mackerras, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-1-alastair@au1.ibm.com>
On Thu, Feb 20, 2020 at 7:28 PM Alastair D'Silva <alastair@au1.ibm.com> wrote:
>
> From: Alastair D'Silva <alastair@d-silva.org>
>
> This series adds support for OpenCAPI Persistent Memory devices, exposing
> them as nvdimms so that we can make use of the existing infrastructure.
A single sentence to introduce:
24 files changed, 3029 insertions(+), 97 deletions(-)
...is inadequate. What are OpenCAPI Persistent Memory devices? How do
they compare, in terms relevant to libnvdimm, to other persistent
memory devices? What challenges do they pose to the existing enabling?
What is the overall approach taken with this 27 patch break down? What
are the changes since v2, v1? If you incorporated someone's review
feedback note it in the cover letter changelog, if you didn't
incorporate someone's feedback note that too with an explanation.
In short, provide a bridge document for someone familiar with the
upstream infrastructure, but not necessarily steeped in powernv /
OpenCAPI platform details, to get started with this code.
For now, no need to resend the whole series, just reply to this
message with a fleshed out cover letter and then incorporate it going
forward for v4+.
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 7f08c318df48fbcfc16a1cfbfad6818542510d57
From: kbuild test robot @ 2020-02-21 15:40 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 7f08c318df48fbcfc16a1cfbfad6818542510d57 powerpc/kernel/sysfs: Add new config option PMU_SYSFS to enable PMU SPRs sysfs file creation
elapsed time: 3028m
configs tested: 292
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
s390 allmodconfig
sparc defconfig
xtensa common_defconfig
s390 debug_defconfig
m68k multi_defconfig
nds32 allnoconfig
sh titan_defconfig
ia64 allyesconfig
sparc64 defconfig
h8300 h8s-sim_defconfig
h8300 h8300h-sim_defconfig
nios2 3c120_defconfig
openrisc or1ksim_defconfig
sparc64 allnoconfig
um defconfig
sh allmodconfig
ia64 allnoconfig
s390 defconfig
sh sh7785lcr_32bit_defconfig
m68k allmodconfig
um x86_64_defconfig
m68k sun3_defconfig
csky defconfig
s390 allnoconfig
sh allnoconfig
c6x allyesconfig
h8300 edosk2674_defconfig
mips malta_kvm_defconfig
i386 alldefconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 defconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
openrisc simple_smp_defconfig
xtensa iss_defconfig
alpha defconfig
nds32 defconfig
m68k m5475evb_defconfig
arc allyesconfig
arc defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips fuloong2e_defconfig
parisc allnoconfig
parisc allyesconfig
parisc generic-32bit_defconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200220
x86_64 randconfig-a002-20200220
x86_64 randconfig-a003-20200220
i386 randconfig-a001-20200220
i386 randconfig-a002-20200220
i386 randconfig-a003-20200220
x86_64 randconfig-a001-20200221
x86_64 randconfig-a002-20200221
x86_64 randconfig-a003-20200221
i386 randconfig-a001-20200221
i386 randconfig-a002-20200221
i386 randconfig-a003-20200221
x86_64 randconfig-a001-20200219
x86_64 randconfig-a002-20200219
x86_64 randconfig-a003-20200219
i386 randconfig-a001-20200219
i386 randconfig-a002-20200219
i386 randconfig-a003-20200219
alpha randconfig-a001-20200221
m68k randconfig-a001-20200221
mips randconfig-a001-20200221
nds32 randconfig-a001-20200221
parisc randconfig-a001-20200221
riscv randconfig-a001-20200221
alpha randconfig-a001-20200220
m68k randconfig-a001-20200220
mips randconfig-a001-20200220
nds32 randconfig-a001-20200220
parisc randconfig-a001-20200220
riscv randconfig-a001-20200220
alpha randconfig-a001-20200219
m68k randconfig-a001-20200219
nds32 randconfig-a001-20200219
parisc randconfig-a001-20200219
riscv randconfig-a001-20200219
mips randconfig-a001-20200219
c6x randconfig-a001-20200221
h8300 randconfig-a001-20200221
microblaze randconfig-a001-20200221
nios2 randconfig-a001-20200221
sparc64 randconfig-a001-20200221
c6x randconfig-a001-20200220
h8300 randconfig-a001-20200220
microblaze randconfig-a001-20200220
nios2 randconfig-a001-20200220
sparc64 randconfig-a001-20200220
c6x randconfig-a001-20200219
h8300 randconfig-a001-20200219
microblaze randconfig-a001-20200219
nios2 randconfig-a001-20200219
sparc64 randconfig-a001-20200219
csky randconfig-a001-20200219
openrisc randconfig-a001-20200219
s390 randconfig-a001-20200219
xtensa randconfig-a001-20200219
csky randconfig-a001-20200220
openrisc randconfig-a001-20200220
s390 randconfig-a001-20200220
sh randconfig-a001-20200220
xtensa randconfig-a001-20200220
csky randconfig-a001-20200221
openrisc randconfig-a001-20200221
s390 randconfig-a001-20200221
sh randconfig-a001-20200221
xtensa randconfig-a001-20200221
sh randconfig-a001-20200219
x86_64 randconfig-b001-20200219
x86_64 randconfig-b002-20200219
x86_64 randconfig-b003-20200219
i386 randconfig-b001-20200219
i386 randconfig-b002-20200219
i386 randconfig-b003-20200219
x86_64 randconfig-b001-20200220
x86_64 randconfig-b002-20200220
x86_64 randconfig-b003-20200220
i386 randconfig-b001-20200220
i386 randconfig-b002-20200220
i386 randconfig-b003-20200220
x86_64 randconfig-b001-20200221
x86_64 randconfig-b002-20200221
x86_64 randconfig-b003-20200221
i386 randconfig-b001-20200221
i386 randconfig-b002-20200221
i386 randconfig-b003-20200221
x86_64 randconfig-c001-20200220
x86_64 randconfig-c002-20200220
x86_64 randconfig-c003-20200220
i386 randconfig-c001-20200220
i386 randconfig-c002-20200220
i386 randconfig-c003-20200220
x86_64 randconfig-c001-20200221
x86_64 randconfig-c002-20200221
x86_64 randconfig-c003-20200221
i386 randconfig-c001-20200221
i386 randconfig-c002-20200221
i386 randconfig-c003-20200221
x86_64 randconfig-c001-20200219
x86_64 randconfig-c002-20200219
x86_64 randconfig-c003-20200219
i386 randconfig-c001-20200219
i386 randconfig-c002-20200219
i386 randconfig-c003-20200219
x86_64 randconfig-d001-20200220
x86_64 randconfig-d002-20200220
x86_64 randconfig-d003-20200220
i386 randconfig-d001-20200220
i386 randconfig-d002-20200220
i386 randconfig-d003-20200220
x86_64 randconfig-d001-20200219
x86_64 randconfig-d002-20200219
x86_64 randconfig-d003-20200219
i386 randconfig-d001-20200219
i386 randconfig-d002-20200219
i386 randconfig-d003-20200219
x86_64 randconfig-d001-20200221
x86_64 randconfig-d002-20200221
x86_64 randconfig-d003-20200221
i386 randconfig-d001-20200221
i386 randconfig-d002-20200221
i386 randconfig-d003-20200221
x86_64 randconfig-e001-20200220
x86_64 randconfig-e002-20200220
x86_64 randconfig-e003-20200220
i386 randconfig-e001-20200220
i386 randconfig-e002-20200220
i386 randconfig-e003-20200220
x86_64 randconfig-e001-20200219
x86_64 randconfig-e002-20200219
x86_64 randconfig-e003-20200219
i386 randconfig-e001-20200219
i386 randconfig-e002-20200219
i386 randconfig-e003-20200219
x86_64 randconfig-f001-20200220
x86_64 randconfig-f002-20200220
x86_64 randconfig-f003-20200220
i386 randconfig-f001-20200220
i386 randconfig-f002-20200220
i386 randconfig-f003-20200220
x86_64 randconfig-f001-20200221
x86_64 randconfig-f002-20200221
x86_64 randconfig-f003-20200221
i386 randconfig-f001-20200221
i386 randconfig-f002-20200221
i386 randconfig-f003-20200221
x86_64 randconfig-g001-20200219
x86_64 randconfig-g002-20200219
x86_64 randconfig-g003-20200219
i386 randconfig-g001-20200219
i386 randconfig-g002-20200219
i386 randconfig-g003-20200219
x86_64 randconfig-g001-20200221
x86_64 randconfig-g002-20200221
x86_64 randconfig-g003-20200221
i386 randconfig-g001-20200221
i386 randconfig-g002-20200221
i386 randconfig-g003-20200221
x86_64 randconfig-g001-20200220
x86_64 randconfig-g002-20200220
x86_64 randconfig-g003-20200220
i386 randconfig-g001-20200220
i386 randconfig-g002-20200220
i386 randconfig-g003-20200220
x86_64 randconfig-h001-20200219
x86_64 randconfig-h002-20200219
x86_64 randconfig-h003-20200219
i386 randconfig-h001-20200219
i386 randconfig-h002-20200219
i386 randconfig-h003-20200219
x86_64 randconfig-h001-20200221
x86_64 randconfig-h002-20200221
x86_64 randconfig-h003-20200221
i386 randconfig-h001-20200221
i386 randconfig-h002-20200221
i386 randconfig-h003-20200221
x86_64 randconfig-h001-20200220
x86_64 randconfig-h002-20200220
x86_64 randconfig-h003-20200220
i386 randconfig-h001-20200220
i386 randconfig-h002-20200220
i386 randconfig-h003-20200220
arc randconfig-a001-20200220
arm randconfig-a001-20200220
arm64 randconfig-a001-20200220
ia64 randconfig-a001-20200220
powerpc randconfig-a001-20200220
sparc randconfig-a001-20200220
arc randconfig-a001-20200221
arm randconfig-a001-20200221
arm64 randconfig-a001-20200221
ia64 randconfig-a001-20200221
powerpc randconfig-a001-20200221
sparc randconfig-a001-20200221
arc randconfig-a001-20200219
arm randconfig-a001-20200219
arm64 randconfig-a001-20200219
ia64 randconfig-a001-20200219
powerpc randconfig-a001-20200219
sparc randconfig-a001-20200219
riscv allmodconfig
riscv allnoconfig
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
s390 alldefconfig
s390 allyesconfig
s390 zfcpdump_defconfig
sh rsk7269_defconfig
sparc64 allmodconfig
sparc64 allyesconfig
um i386_defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 65b2623f395a4e25ab3ff4cff1c9c7623619a22d
From: kbuild test robot @ 2020-02-21 15:38 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 65b2623f395a4e25ab3ff4cff1c9c7623619a22d Automatic merge of branches 'master', 'next' and 'fixes' into merge
elapsed time: 3027m
configs tested: 278
configs skipped: 0
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
sparc defconfig
parisc generic-64bit_defconfig
powerpc defconfig
sparc64 allyesconfig
riscv allyesconfig
sh titan_defconfig
sparc64 defconfig
h8300 h8300h-sim_defconfig
nios2 3c120_defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
ia64 allnoconfig
openrisc simple_smp_defconfig
alpha defconfig
m68k sun3_defconfig
sh allmodconfig
xtensa iss_defconfig
powerpc allnoconfig
s390 allnoconfig
mips malta_kvm_defconfig
arc defconfig
i386 alldefconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allyesconfig
ia64 defconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
openrisc or1ksim_defconfig
xtensa common_defconfig
csky defconfig
nds32 allnoconfig
nds32 defconfig
h8300 edosk2674_defconfig
m68k m5475evb_defconfig
m68k multi_defconfig
arc allyesconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips fuloong2e_defconfig
parisc allnoconfig
parisc allyesconfig
parisc generic-32bit_defconfig
x86_64 randconfig-a001-20200219
x86_64 randconfig-a002-20200219
x86_64 randconfig-a003-20200219
i386 randconfig-a001-20200219
i386 randconfig-a002-20200219
i386 randconfig-a003-20200219
x86_64 randconfig-a001-20200220
x86_64 randconfig-a002-20200220
x86_64 randconfig-a003-20200220
i386 randconfig-a001-20200220
i386 randconfig-a002-20200220
i386 randconfig-a003-20200220
x86_64 randconfig-a001-20200221
x86_64 randconfig-a002-20200221
x86_64 randconfig-a003-20200221
i386 randconfig-a001-20200221
i386 randconfig-a002-20200221
i386 randconfig-a003-20200221
alpha randconfig-a001-20200219
m68k randconfig-a001-20200219
nds32 randconfig-a001-20200219
parisc randconfig-a001-20200219
riscv randconfig-a001-20200219
alpha randconfig-a001-20200220
m68k randconfig-a001-20200220
mips randconfig-a001-20200220
nds32 randconfig-a001-20200220
parisc randconfig-a001-20200220
riscv randconfig-a001-20200220
c6x randconfig-a001-20200221
h8300 randconfig-a001-20200221
microblaze randconfig-a001-20200221
nios2 randconfig-a001-20200221
sparc64 randconfig-a001-20200221
c6x randconfig-a001-20200220
h8300 randconfig-a001-20200220
microblaze randconfig-a001-20200220
nios2 randconfig-a001-20200220
sparc64 randconfig-a001-20200220
c6x randconfig-a001-20200219
h8300 randconfig-a001-20200219
microblaze randconfig-a001-20200219
nios2 randconfig-a001-20200219
sparc64 randconfig-a001-20200219
csky randconfig-a001-20200219
openrisc randconfig-a001-20200219
s390 randconfig-a001-20200219
xtensa randconfig-a001-20200219
csky randconfig-a001-20200220
openrisc randconfig-a001-20200220
s390 randconfig-a001-20200220
sh randconfig-a001-20200220
xtensa randconfig-a001-20200220
csky randconfig-a001-20200221
openrisc randconfig-a001-20200221
s390 randconfig-a001-20200221
sh randconfig-a001-20200221
xtensa randconfig-a001-20200221
x86_64 randconfig-b001-20200219
x86_64 randconfig-b002-20200219
x86_64 randconfig-b003-20200219
i386 randconfig-b001-20200219
i386 randconfig-b002-20200219
i386 randconfig-b003-20200219
x86_64 randconfig-b001-20200220
x86_64 randconfig-b002-20200220
x86_64 randconfig-b003-20200220
i386 randconfig-b001-20200220
i386 randconfig-b002-20200220
i386 randconfig-b003-20200220
x86_64 randconfig-c003-20200219
i386 randconfig-c002-20200219
i386 randconfig-c001-20200219
x86_64 randconfig-c002-20200219
x86_64 randconfig-c001-20200219
i386 randconfig-c003-20200219
x86_64 randconfig-c001-20200220
x86_64 randconfig-c002-20200220
x86_64 randconfig-c003-20200220
i386 randconfig-c001-20200220
i386 randconfig-c002-20200220
i386 randconfig-c003-20200220
x86_64 randconfig-c001-20200221
x86_64 randconfig-c002-20200221
x86_64 randconfig-c003-20200221
i386 randconfig-c001-20200221
i386 randconfig-c002-20200221
i386 randconfig-c003-20200221
x86_64 randconfig-d001-20200220
x86_64 randconfig-d002-20200220
x86_64 randconfig-d003-20200220
i386 randconfig-d001-20200220
i386 randconfig-d002-20200220
i386 randconfig-d003-20200220
x86_64 randconfig-d001-20200221
x86_64 randconfig-d002-20200221
x86_64 randconfig-d003-20200221
i386 randconfig-d001-20200221
i386 randconfig-d002-20200221
i386 randconfig-d003-20200221
x86_64 randconfig-e001-20200220
x86_64 randconfig-e002-20200220
x86_64 randconfig-e003-20200220
i386 randconfig-e001-20200220
i386 randconfig-e002-20200220
i386 randconfig-e003-20200220
x86_64 randconfig-e001-20200219
x86_64 randconfig-e002-20200219
x86_64 randconfig-e003-20200219
i386 randconfig-e001-20200219
i386 randconfig-e002-20200219
i386 randconfig-e003-20200219
x86_64 randconfig-f001-20200220
x86_64 randconfig-f002-20200220
x86_64 randconfig-f003-20200220
i386 randconfig-f001-20200220
i386 randconfig-f002-20200220
i386 randconfig-f003-20200220
x86_64 randconfig-f001-20200219
x86_64 randconfig-f002-20200219
x86_64 randconfig-f003-20200219
i386 randconfig-f001-20200219
i386 randconfig-f002-20200219
i386 randconfig-f003-20200219
x86_64 randconfig-f001-20200221
x86_64 randconfig-f002-20200221
x86_64 randconfig-f003-20200221
i386 randconfig-f001-20200221
i386 randconfig-f002-20200221
i386 randconfig-f003-20200221
x86_64 randconfig-g001-20200220
x86_64 randconfig-g002-20200220
x86_64 randconfig-g003-20200220
i386 randconfig-g001-20200220
i386 randconfig-g002-20200220
i386 randconfig-g003-20200220
x86_64 randconfig-g001-20200219
x86_64 randconfig-g002-20200219
x86_64 randconfig-g003-20200219
i386 randconfig-g001-20200219
i386 randconfig-g002-20200219
i386 randconfig-g003-20200219
x86_64 randconfig-g001-20200221
x86_64 randconfig-g002-20200221
x86_64 randconfig-g003-20200221
i386 randconfig-g001-20200221
i386 randconfig-g002-20200221
i386 randconfig-g003-20200221
x86_64 randconfig-h001-20200219
x86_64 randconfig-h002-20200219
x86_64 randconfig-h003-20200219
i386 randconfig-h001-20200219
i386 randconfig-h002-20200219
i386 randconfig-h003-20200219
x86_64 randconfig-h001-20200221
x86_64 randconfig-h002-20200221
x86_64 randconfig-h003-20200221
i386 randconfig-h001-20200221
i386 randconfig-h002-20200221
i386 randconfig-h003-20200221
x86_64 randconfig-h001-20200220
x86_64 randconfig-h002-20200220
x86_64 randconfig-h003-20200220
i386 randconfig-h001-20200220
i386 randconfig-h002-20200220
i386 randconfig-h003-20200220
arc randconfig-a001-20200219
arm randconfig-a001-20200219
arm64 randconfig-a001-20200219
ia64 randconfig-a001-20200219
powerpc randconfig-a001-20200219
sparc randconfig-a001-20200219
arc randconfig-a001-20200220
arm randconfig-a001-20200220
arm64 randconfig-a001-20200220
ia64 randconfig-a001-20200220
powerpc randconfig-a001-20200220
sparc randconfig-a001-20200220
arc randconfig-a001-20200221
arm randconfig-a001-20200221
arm64 randconfig-a001-20200221
ia64 randconfig-a001-20200221
powerpc randconfig-a001-20200221
sparc randconfig-a001-20200221
riscv allmodconfig
riscv allnoconfig
riscv defconfig
s390 alldefconfig
s390 allmodconfig
s390 allyesconfig
s390 debug_defconfig
s390 defconfig
s390 zfcpdump_defconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sparc64 allmodconfig
sparc64 allnoconfig
um defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v2 1/5] powerpc: Move idle_loop_prolog()/epilog() functions to header file
From: Nathan Lynch @ 2020-02-21 15:03 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Tyrel Datwyler, linux-kernel, Kamalesh Babulal, Naveen N. Rao,
Vaidyanathan Srinivasan, linuxppc-dev
In-Reply-To: <1582262314-8319-2-git-send-email-ego@linux.vnet.ibm.com>
"Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> Currently prior to entering an idle state on a Linux Guest, the
> pseries cpuidle driver implement an idle_loop_prolog() and
> idle_loop_epilog() functions which ensure that idle_purr is correctly
> computed, and the hypervisor is informed that the CPU cycles have been
> donated.
>
> These prolog and epilog functions are also required in the default
> idle call, i.e pseries_lpar_idle(). Hence move these accessor
> functions to a common header file and call them from
> pseries_lpar_idle(). Since the existing header files such as
> asm/processor.h have enough clutter, create a new header file
> asm/idle.h.
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/idle.h | 27 +++++++++++++++++++++++++++
> arch/powerpc/platforms/pseries/setup.c | 7 +++++--
> drivers/cpuidle/cpuidle-pseries.c | 24 +-----------------------
> 3 files changed, 33 insertions(+), 25 deletions(-)
> create mode 100644 arch/powerpc/include/asm/idle.h
>
> diff --git a/arch/powerpc/include/asm/idle.h b/arch/powerpc/include/asm/idle.h
> new file mode 100644
> index 0000000..f32a7d8
> --- /dev/null
> +++ b/arch/powerpc/include/asm/idle.h
> @@ -0,0 +1,27 @@
> +#ifndef _ASM_POWERPC_IDLE_H
> +#define _ASM_POWERPC_IDLE_H
> +#include <asm/runlatch.h>
> +
> +static inline void idle_loop_prolog(unsigned long *in_purr)
> +{
> + ppc64_runlatch_off();
> + *in_purr = mfspr(SPRN_PURR);
> + /*
> + * Indicate to the HV that we are idle. Now would be
> + * a good time to find other work to dispatch.
> + */
> + get_lppaca()->idle = 1;
> +}
> +
> +static inline void idle_loop_epilog(unsigned long in_purr)
> +{
> + u64 wait_cycles;
> +
> + wait_cycles = be64_to_cpu(get_lppaca()->wait_state_cycles);
> + wait_cycles += mfspr(SPRN_PURR) - in_purr;
> + get_lppaca()->wait_state_cycles = cpu_to_be64(wait_cycles);
> + get_lppaca()->idle = 0;
> +
> + ppc64_runlatch_on();
> +}
> +#endif
Looks fine and correct as a cleanup, but asm/include/idle.h and
idle_loop_prolog, idle_loop_epilog, strike me as too generic for
pseries-specific code.
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.6-3 tag
From: Michael Ellerman @ 2020-02-21 11:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: mikey, gustavold, sbobroff, linux-kernel, oohall, linuxppc-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.6. This is two weeks worth as I was
out sick last week.
The following changes since commit 11a48a5a18c63fd7621bb050228cebf13566e4d8:
Linux 5.6-rc2 (2020-02-16 13:16:59 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.6-3
for you to fetch changes up to 9eb425b2e04e0e3006adffea5bf5f227a896f128:
powerpc/entry: Fix an #if which should be an #ifdef in entry_32.S (2020-02-19 10:35:22 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.6 #3
- Three fixes for the recently added VMAP_STACK on 32-bit.
- Three fixes related to hugepages on 8xx (32-bit).
- A fix for a bug in our transactional memory handling that could lead to a
kernel crash if we saw a page fault during signal delivery.
- A fix for a deadlock in our PCI EEH (Enhanced Error Handling) code.
- A couple of other minor fixes.
Thanks to:
Christophe Leroy, Erhard F, Frederic Barrat, Gustavo Luiz Duarte, Larry
Finger, Leonardo Bras, Oliver O'Halloran, Sam Bobroff.
- ------------------------------------------------------------------
Christophe Leroy (7):
powerpc/hugetlb: Fix 512k hugepages on 8xx with 16k page size
powerpc/hugetlb: Fix 8M hugepages on 8xx
powerpc/8xx: Fix clearing of bits 20-23 in ITLB miss
powerpc/32s: Fix DSI and ISI exceptions for CONFIG_VMAP_STACK
powerpc/chrp: Fix enter_rtas() with CONFIG_VMAP_STACK
powerpc/6xx: Fix power_save_ppc32_restore() with CONFIG_VMAP_STACK
powerpc/entry: Fix an #if which should be an #ifdef in entry_32.S
Gustavo Luiz Duarte (1):
powerpc/tm: Fix clearing MSR[TS] in current when reclaiming on signal delivery
Oliver O'Halloran (1):
powerpc/xmon: Fix whitespace handling in getstring()
Sam Bobroff (1):
powerpc/eeh: Fix deadlock handling dead PHB
arch/powerpc/include/asm/page.h | 5 +
arch/powerpc/include/asm/processor.h | 4 +
arch/powerpc/kernel/asm-offsets.c | 12 ++
arch/powerpc/kernel/eeh_driver.c | 21 +--
arch/powerpc/kernel/entry_32.S | 13 +-
arch/powerpc/kernel/head_32.S | 155 +++++++++++++++++++-
arch/powerpc/kernel/head_32.h | 21 ++-
arch/powerpc/kernel/head_8xx.S | 2 +-
arch/powerpc/kernel/idle_6xx.S | 8 +
arch/powerpc/kernel/signal.c | 17 ++-
arch/powerpc/kernel/signal_32.c | 28 ++--
arch/powerpc/kernel/signal_64.c | 22 ++-
arch/powerpc/mm/book3s32/hash_low.S | 52 +++----
arch/powerpc/mm/book3s32/mmu.c | 10 +-
arch/powerpc/mm/hugetlbpage.c | 29 ++--
arch/powerpc/mm/kasan/kasan_init_32.c | 3 +-
arch/powerpc/xmon/xmon.c | 5 +
17 files changed, 308 insertions(+), 99 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl5PwfYACgkQUevqPMjh
pYBuFg//b2i/1wn5+CQiqCM4B7Z0fbNvAWH0CFrseR1f72OnO0c9h92vTMjNDIVf
SItrgl4bBstVq/1YjHnZn00WpJPihIFcXPveQbiH+9yb89Mkcwjj3jLrV/DYIpRW
gtHxCJImc4/A4tLOUhRA2armXL4AoFlolF/Pbe2m/2lGeH1+tfY4Xd50FJF8c9Zc
zLdIN4B5Y+IkROQO23LFKiYV0tarvc4q5z6VOY5WlaGd/dpK4OQmheymeDMTYiNN
CH81u4b6jiiq9uwAWRXao2RTotac3m3Q4XnEswf3obDNGF2mDkAWvpqIgKxRxPNu
7vtmlamHxhpuqtZpRPPYIaH57j0pGZH63gvCThjJ+V9SL7J856cml9mv4UJOcmI3
Fkyk8S/QbiP5Rt9KV+CELHGcWaVt+uCuKPwlFrkoEMw1HZ6GErhpKzBNHyoNA1mG
xLMR4joCHZig62WBEHlZXgLzPVsetO7ZpY+j7tYEWrllfmOeL0F8HzNQ2e6ukF1R
gyF7eEThKajDhCwgz8pGnE2te+mz56oLHv9lcqU/wEgxHadyzeMjkiRUfxgiQ+K1
sOWzQjYEt7dhocavOAJb3qtfNMhwSfvSk75P6x8PQNFhQ+KhbNi6JpkOYSTmESBP
T8po1xh7Hm7IiIROT0hvcdnNb2fIIBNrKaheUlmvOOObEfWaa2Q=
=rC3U
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo
From: Amit Kachhap @ 2020-02-21 9:06 UTC (permalink / raw)
To: Bhupesh Sharma, Dave Anderson, James Morse
Cc: Mark Rutland, Ard Biesheuvel, linux-doc, Catalin Marinas, x86,
kexec, linux-kernel, linuxppc-dev, Kazuhito Hagio, bhupesh linux,
Will Deacon, linux-arm-kernel, Steve Capper
In-Reply-To: <04287d60-e99e-631b-c134-d6dc39e6a193@redhat.com>
Hi Bhupesh,
On 1/13/20 5:44 PM, Bhupesh Sharma wrote:
> Hi James,
>
> On 01/11/2020 12:30 AM, Dave Anderson wrote:
>>
>> ----- Original Message -----
>>> Hi Bhupesh,
>>>
>>> On 25/12/2019 19:01, Bhupesh Sharma wrote:
>>>> On 12/12/2019 04:02 PM, James Morse wrote:
>>>>> On 29/11/2019 19:59, Bhupesh Sharma wrote:
>>>>>> vabits_actual variable on arm64 indicates the actual VA space size,
>>>>>> and allows a single binary to support both 48-bit and 52-bit VA
>>>>>> spaces.
>>>>>>
>>>>>> If the ARMv8.2-LVA optional feature is present, and we are running
>>>>>> with a 64KB page size; then it is possible to use 52-bits of address
>>>>>> space for both userspace and kernel addresses. However, any kernel
>>>>>> binary that supports 52-bit must also be able to fall back to 48-bit
>>>>>> at early boot time if the hardware feature is not present.
>>>>>>
>>>>>> Since TCR_EL1.T1SZ indicates the size offset of the memory region
>>>>>> addressed by TTBR1_EL1 (and hence can be used for determining the
>>>>>> vabits_actual value) it makes more sense to export the same in
>>>>>> vmcoreinfo rather than vabits_actual variable, as the name of the
>>>>>> variable can change in future kernel versions, but the architectural
>>>>>> constructs like TCR_EL1.T1SZ can be used better to indicate intended
>>>>>> specific fields to user-space.
>>>>>>
>>>>>> User-space utilities like makedumpfile and crash-utility, need to
>>>>>> read/write this value from/to vmcoreinfo
>>>>>
>>>>> (write?)
>>>>
>>>> Yes, also write so that the vmcoreinfo from an (crashing) arm64
>>>> system can
>>>> be used for
>>>> analysis of the root-cause of panic/crash on say an x86_64 host using
>>>> utilities like
>>>> crash-utility/gdb.
>>>
>>> I read this as as "User-space [...] needs to write to vmcoreinfo".
>
> That's correct. But for writing to vmcore dump in the kdump kernel, we
> need to read the symbols from the vmcoreinfo in the primary kernel.
>
>>>>>> for determining if a virtual address lies in the linear map range.
>>>>>
>>>>> I think this is a fragile example. The debugger shouldn't need to know
>>>>> this.
>>>>
>>>> Well that the current user-space utility design, so I am not sure we
>>>> can
>>>> tweak that too much.
>>>>
>>>>>> The user-space computation for determining whether an address lies in
>>>>>> the linear map range is the same as we have in kernel-space:
>>>>>>
>>>>>> #define __is_lm_address(addr) (!(((u64)addr) &
>>>>>> BIT(vabits_actual -
>>>>>> 1)))
>>>>>
>>>>> This was changed with 14c127c957c1 ("arm64: mm: Flip kernel VA
>>>>> space"). If
>>>>> user-space
>>>>> tools rely on 'knowing' the kernel memory layout, they must have to
>>>>> constantly be fixed
>>>>> and updated. This is a poor argument for adding this to something that
>>>>> ends up as ABI.
>>>>
>>>> See above. The user-space has to rely on some ABI/guaranteed
>>>> hardware-symbols which can be
>>>> used for 'determining' the kernel memory layout.
>>>
>>> I disagree. Everything and anything in the kernel will change. The
>>> ABI rules apply to
>>> stuff exposed via syscalls and kernel filesystems. It does not apply
>>> to kernel internals,
>>> like the memory layout we used yesterday. 14c127c957c1 is a case in
>>> point.
>>>
>>> A debugger trying to rely on this sort of thing would have to play
>>> catchup whenever it
>>> changes.
>>
>> Exactly. That's the whole point.
>>
>> The crash utility and makedumpfile are not in the same league as other
>> user-space tools.
>> They have always had to "play catchup" precisely because they depend
>> upon kernel internals,
>> which constantly change.
>
> I agree with you and DaveA here. Software user-space debuggers are
> dependent on kernel internals (which can change from time-to-time) and
> will have to play catch-up (which has been the case since the very start).
>
> Unfortunately we don't have any clear ABI for software debugging tools -
> may be something to look for in future.
>
> A case in point is gdb/kgdb, which still needs to run with KASLR
> turned-off (nokaslr) for debugging, as it confuses gdb which resolve
> kernel symbol address from symbol table of vmlinux. But we can
> work-around the same in makedumpfile/crash by reading the 'kaslr_offset'
> value. And I have several users telling me now they cannot use gdb on
> KASLR enabled kernel to debug panics, but can makedumpfile + crash
> combination to achieve the same.
>
> So, we should be looking to fix these utilities which are broken since
> the 52-bit changes for arm64. Accordingly, I will try to send the v6
> soon while incorporating the comments posted on the v5.
Any update on the next v6 version. Since this patch series is fixing the
current broken kdump so need this series to add some more fields in
vmcoreinfo for Pointer Authentication work.
Thanks,
Amit Daniel
>
> Thanks,
> Bhupesh
>
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] soc: fsl: dpio: remove set but not used variable 'addr_cena'
From: YueHaibing @ 2020-02-21 8:36 UTC (permalink / raw)
To: Roy.Pledge, leoyang.li, youri.querry_1
Cc: YueHaibing, linuxppc-dev, linux-kernel, linux-arm-kernel
commit 3b2abda7d28c ("soc: fsl: dpio: Replace QMAN array
mode with ring mode enqueue") introduced this, but not
used, so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/soc/fsl/dpio/qbman-portal.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/soc/fsl/dpio/qbman-portal.c b/drivers/soc/fsl/dpio/qbman-portal.c
index 740ee0d..350de56 100644
--- a/drivers/soc/fsl/dpio/qbman-portal.c
+++ b/drivers/soc/fsl/dpio/qbman-portal.c
@@ -658,7 +658,6 @@ int qbman_swp_enqueue_multiple_direct(struct qbman_swp *s,
const uint32_t *cl = (uint32_t *)d;
uint32_t eqcr_ci, eqcr_pi, half_mask, full_mask;
int i, num_enqueued = 0;
- uint64_t addr_cena;
spin_lock(&s->access_spinlock);
half_mask = (s->eqcr.pi_ci_mask>>1);
@@ -711,7 +710,6 @@ int qbman_swp_enqueue_multiple_direct(struct qbman_swp *s,
/* Flush all the cacheline without load/store in between */
eqcr_pi = s->eqcr.pi;
- addr_cena = (size_t)s->addr_cena;
for (i = 0; i < num_enqueued; i++)
eqcr_pi++;
s->eqcr.pi = eqcr_pi & full_mask;
@@ -822,7 +820,6 @@ int qbman_swp_enqueue_multiple_desc_direct(struct qbman_swp *s,
const uint32_t *cl;
uint32_t eqcr_ci, eqcr_pi, half_mask, full_mask;
int i, num_enqueued = 0;
- uint64_t addr_cena;
half_mask = (s->eqcr.pi_ci_mask>>1);
full_mask = s->eqcr.pi_ci_mask;
@@ -866,7 +863,6 @@ int qbman_swp_enqueue_multiple_desc_direct(struct qbman_swp *s,
/* Flush all the cacheline without load/store in between */
eqcr_pi = s->eqcr.pi;
- addr_cena = (uint64_t)s->addr_cena;
for (i = 0; i < num_enqueued; i++)
eqcr_pi++;
s->eqcr.pi = eqcr_pi & full_mask;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 02/27] mm/memory_hotplug: Allow check_hotplug_memory_addressable to be called from drivers
From: Andrew Donnellan @ 2020-02-21 7:03 UTC (permalink / raw)
To: Alastair D'Silva, alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Arnd Bergmann, Greg Kurz, Nicholas Piggin,
Cédric Le Goater, Dan Williams, Hari Bathini, linux-mm,
Greg Kroah-Hartman, linux-kernel, Vishal Verma, Frederic Barrat,
Paul Mackerras, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-3-alastair@au1.ibm.com>
On 21/2/20 2:26 pm, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> When setting up OpenCAPI connected persistent memory, the range check may
> not be performed until quite late (or perhaps not at all, if the user does
> not establish a DAX device).
>
> This patch makes the range check callable so we can perform the check while
> probing the OpenCAPI SCM device.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH v2 8/8] perf/tools/pmu-events/powerpc: Add hv_24x7 socket/chip level metric events
From: Kajol Jain @ 2020-02-21 6:10 UTC (permalink / raw)
To: acme, linuxppc-dev, mpe, suka
Cc: mark.rutland, ravi.bangoria, maddy, tglx, jmario, peterz, gregkh,
mpetlan, alexander.shishkin, linux-perf-users, ak, yao.jin, anju,
mamatha4, kjain, jolsa, namhyung, mingo, kan.liang
In-Reply-To: <20200221061022.3047-1-kjain@linux.ibm.com>
The hv_24×7 feature in IBM® POWER9™ processor-based servers provide the
facility to continuously collect large numbers of hardware performance
metrics efficiently and accurately.
This patch adds hv_24x7 metric file for different Socket/chip
resources.
Result:
power9 platform:
command:# ./perf stat --metric-only -M Memory_RD_BW_Chip -C 0
-I 1000 sleep 1
time MB Memory_RD_BW_Chip_0 MB Memory_RD_BW_Chip_1 MB
1.000192635 0.4 0.0
1.001695883 0.0 0.0
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
.../arch/powerpc/power9/nest_metrics.json | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
diff --git a/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json b/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
new file mode 100644
index 000000000000..ac38f5540ac6
--- /dev/null
+++ b/tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
@@ -0,0 +1,19 @@
+[
+ {
+ "MetricExpr": "(hv_24x7@PM_MCS01_128B_RD_DISP_PORT01\\,chip\\=?@ + hv_24x7@PM_MCS01_128B_RD_DISP_PORT23\\,chip\\=?@ + hv_24x7@PM_MCS23_128B_RD_DISP_PORT01\\,chip\\=?@ + hv_24x7@PM_MCS23_128B_RD_DISP_PORT23\\,chip\\=?@)",
+ "MetricName": "Memory_RD_BW_Chip",
+ "MetricGroup": "Memory_BW",
+ "ScaleUnit": "1.6e-2MB"
+ },
+ {
+ "MetricExpr": "(hv_24x7@PM_MCS01_128B_WR_DISP_PORT01\\,chip\\=?@ + hv_24x7@PM_MCS01_128B_WR_DISP_PORT23\\,chip\\=?@ + hv_24x7@PM_MCS23_128B_WR_DISP_PORT01\\,chip\\=?@ + hv_24x7@PM_MCS23_128B_WR_DISP_PORT23\\,chip\\=?@ )",
+ "MetricName": "Memory_WR_BW_Chip",
+ "MetricGroup": "Memory_BW",
+ "ScaleUnit": "1.6e-2MB"
+ },
+ {
+ "MetricExpr": "(hv_24x7@PM_PB_CYC\\,chip\\=?@ )",
+ "MetricName": "PowerBUS_Frequency",
+ "ScaleUnit": "2.5e-7GHz"
+ }
+]
--
2.18.1
^ permalink raw reply related
* [PATCH v2 7/8] tools/perf: Enable Hz/hz prinitg for --metric-only option
From: Kajol Jain @ 2020-02-21 6:10 UTC (permalink / raw)
To: acme, linuxppc-dev, mpe, suka
Cc: mark.rutland, ravi.bangoria, maddy, tglx, jmario, peterz, gregkh,
mpetlan, alexander.shishkin, linux-perf-users, ak, yao.jin, anju,
mamatha4, kjain, jolsa, namhyung, mingo, kan.liang
In-Reply-To: <20200221061022.3047-1-kjain@linux.ibm.com>
Commit 54b5091606c18 ("perf stat: Implement --metric-only mode")
added function 'valid_only_metric()' which drops "Hz" or "hz",
if it is part of "ScaleUnit". This patch enable it since hv_24x7
supports couple of frequency events.
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
tools/perf/util/stat-display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
index bc31fccc0057..22dcdfbb9e10 100644
--- a/tools/perf/util/stat-display.c
+++ b/tools/perf/util/stat-display.c
@@ -236,8 +236,6 @@ static bool valid_only_metric(const char *unit)
if (!unit)
return false;
if (strstr(unit, "/sec") ||
- strstr(unit, "hz") ||
- strstr(unit, "Hz") ||
strstr(unit, "CPUs utilized"))
return false;
return true;
--
2.18.1
^ permalink raw reply related
* [PATCH v2 6/8] perf/tools: Enhance JSON/metric infrastructure to handle "?"
From: Kajol Jain @ 2020-02-21 6:10 UTC (permalink / raw)
To: acme, linuxppc-dev, mpe, suka
Cc: mark.rutland, ravi.bangoria, maddy, tglx, jmario, peterz, gregkh,
mpetlan, alexander.shishkin, linux-perf-users, ak, yao.jin, anju,
mamatha4, kjain, jolsa, namhyung, mingo, kan.liang
In-Reply-To: <20200221061022.3047-1-kjain@linux.ibm.com>
Patch enhances current metric infrastructure to handle "?" in the metric
expression. The "?" can be use for parameters whose value not known while
creating metric events and which can be replace later at runtime to
the proper value. It also add flexibility to create multiple events out
of single metric event added in json file.
Patch adds function 'arch_get_runtimeparam' which is a arch specific
function, returns the count of metric events need to be created.
By default it return 1.
One loop is added in function 'metricgroup__add_metric', which create
multiple events at run time depend on return value of
'arch_get_runtimeparam' and merge that event in 'group_list'.
This infrastructure needed for hv_24x7 socket/chip level events.
"hv_24x7" chip level events needs specific chip-id to which the
data is requested. Function 'arch_get_runtimeparam' implemented
in header.c which extract number of sockets from sysfs file
"sockets" under "/sys/devices/hv_24x7/interface/".
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
| 40 +++++++++
tools/perf/util/expr.h | 1 +
tools/perf/util/expr.y | 17 +++-
tools/perf/util/metricgroup.c | 112 ++++++++++++++++----------
tools/perf/util/metricgroup.h | 1 +
tools/perf/util/stat-shadow.c | 5 ++
6 files changed, 134 insertions(+), 42 deletions(-)
--git a/tools/perf/arch/powerpc/util/header.c b/tools/perf/arch/powerpc/util/header.c
index 3b4cdfc5efd6..28425edb901c 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -7,6 +7,11 @@
#include <string.h>
#include <linux/stringify.h>
#include "header.h"
+#include "metricgroup.h"
+#include "evlist.h"
+#include <dirent.h>
+#include "pmu.h"
+#include <api/fs/fs.h>
#define mfspr(rn) ({unsigned long rval; \
asm volatile("mfspr %0," __stringify(rn) \
@@ -16,6 +21,8 @@
#define PVR_VER(pvr) (((pvr) >> 16) & 0xFFFF) /* Version field */
#define PVR_REV(pvr) (((pvr) >> 0) & 0xFFFF) /* Revison field */
+#define SOCKETS_INFO_FILE_PATH "/devices/hv_24x7/interface/"
+
int
get_cpuid(char *buffer, size_t sz)
{
@@ -44,3 +51,36 @@ get_cpuid_str(struct perf_pmu *pmu __maybe_unused)
return bufp;
}
+
+int arch_get_runtimeparam(void)
+{
+ int count = 0;
+ DIR *dir;
+ char path[PATH_MAX];
+ const char *sysfs = sysfs__mountpoint();
+ char filename[] = "sockets";
+ FILE *file;
+ char buf[16], *num;
+ int data;
+
+ if (!sysfs)
+ goto out;
+ snprintf(path, PATH_MAX,
+ "%s" SOCKETS_INFO_FILE_PATH, sysfs);
+ dir = opendir(path);
+ if (!dir)
+ goto out;
+ strcat(path, filename);
+ file = fopen(path, "r");
+ if (!file)
+ goto out;
+
+ data = fread(buf, 1, sizeof(buf), file);
+ if (data == 0)
+ goto out;
+ count = strtol(buf, &num, 10);
+out:
+ if (!count)
+ count = 1;
+ return count;
+}
diff --git a/tools/perf/util/expr.h b/tools/perf/util/expr.h
index 046160831f90..85ebea68b0c5 100644
--- a/tools/perf/util/expr.h
+++ b/tools/perf/util/expr.h
@@ -15,6 +15,7 @@ struct parse_ctx {
struct parse_id ids[MAX_PARSE_ID];
};
+extern int expr__runtimeparam;
void expr__ctx_init(struct parse_ctx *ctx);
void expr__add_id(struct parse_ctx *ctx, const char *id, double val);
#ifndef IN_EXPR_Y
diff --git a/tools/perf/util/expr.y b/tools/perf/util/expr.y
index 7d226241f1d7..8d1d51451873 100644
--- a/tools/perf/util/expr.y
+++ b/tools/perf/util/expr.y
@@ -37,6 +37,8 @@
%type <num> expr if_expr
%{
+int expr__runtimeparam;
+
static int expr__lex(YYSTYPE *res, const char **pp);
static void expr__error(double *final_val __maybe_unused,
@@ -102,7 +104,7 @@ static int expr__symbol(YYSTYPE *res, const char *p, const char **pp)
if (*p == '#')
*dst++ = *p++;
- while (isalnum(*p) || *p == '_' || *p == '.' || *p == ':' || *p == '@' || *p == '\\') {
+ while (isalnum(*p) || *p == '_' || *p == '.' || *p == ':' || *p == '@' || *p == '\\' || *p == '?') {
if (p - s >= MAXIDLEN)
return -1;
/*
@@ -113,6 +115,19 @@ static int expr__symbol(YYSTYPE *res, const char *p, const char **pp)
*dst++ = '/';
else if (*p == '\\')
*dst++ = *++p;
+ else if (*p == '?') {
+ int size = snprintf(NULL, 0, "%d", expr__runtimeparam);
+ char * paramval = (char *)malloc(size);
+ int i = 0;
+ if(!paramval)
+ *dst++ = '0';
+ else {
+ sprintf(paramval, "%d", expr__runtimeparam);
+ while(i < size)
+ *dst++ = paramval[i++];
+ free(paramval);
+ }
+ }
else
*dst++ = *p;
p++;
diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 02aee946b6c1..f629828cc0de 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -399,6 +399,11 @@ void metricgroup__print(bool metrics, bool metricgroups, char *filter,
strlist__delete(metriclist);
}
+int __weak arch_get_runtimeparam(void)
+{
+ return 1;
+}
+
static int metricgroup__add_metric(const char *metric, struct strbuf *events,
struct list_head *group_list)
{
@@ -419,52 +424,77 @@ static int metricgroup__add_metric(const char *metric, struct strbuf *events,
continue;
if (match_metric(pe->metric_group, metric) ||
match_metric(pe->metric_name, metric)) {
- const char **ids;
- int idnum;
- struct egroup *eg;
- bool no_group = false;
+ int k, count;
+
+ if (strstr(pe->metric_expr, "?"))
+ count = arch_get_runtimeparam();
+ else
+ count = 1;
+
+ /* This loop is added to create multiple
+ * events depend on count value and add
+ * those events to group_list.
+ */
+ for (k = 0; k < count; k++) {
+ const char **ids;
+ int idnum;
+ struct egroup *eg;
+ bool no_group = false;
+ char value[PATH_MAX];
+
+ pr_debug("metric expr %s for %s\n",
+ pe->metric_expr, pe->metric_name);
+ expr__runtimeparam = k;
+ if (expr__find_other(pe->metric_expr, NULL,
+ &ids, &idnum) < 0)
+ continue;
+ if (events->len > 0)
+ strbuf_addf(events, ",");
+ for (j = 0; j < idnum; j++) {
+ pr_debug("found event %s\n", ids[j]);
+ /*
+ * Duration time maps to a software
+ * event and can make groups not count.
+ * Always use it outside a group.
+ */
+ if (!strcmp(ids[j], "duration_time")) {
+ if (j > 0)
+ strbuf_addf(events,
+ "}:W,");
+ strbuf_addf(events,
+ "duration_time");
+ no_group = true;
+ continue;
+ }
+ strbuf_addf(events, "%s%s",
+ j == 0 || no_group ? "{" :
+ ",", ids[j]);
+ no_group = false;
+ }
+ if (!no_group)
+ strbuf_addf(events, "}:W");
- pr_debug("metric expr %s for %s\n", pe->metric_expr, pe->metric_name);
+ eg = malloc(sizeof(struct egroup));
+ if (!eg) {
+ ret = -ENOMEM;
+ break;
+ }
+ eg->ids = ids;
+ eg->idnum = idnum;
- if (expr__find_other(pe->metric_expr,
- NULL, &ids, &idnum) < 0)
- continue;
- if (events->len > 0)
- strbuf_addf(events, ",");
- for (j = 0; j < idnum; j++) {
- pr_debug("found event %s\n", ids[j]);
- /*
- * Duration time maps to a software event and can make
- * groups not count. Always use it outside a
- * group.
- */
- if (!strcmp(ids[j], "duration_time")) {
- if (j > 0)
- strbuf_addf(events, "}:W,");
- strbuf_addf(events, "duration_time");
- no_group = true;
- continue;
+ if (strstr(pe->metric_expr, "?")) {
+ sprintf(value, "%s%c%d",
+ pe->metric_name, '_', k);
+ } else {
+ strcpy(value, pe->metric_name);
}
- strbuf_addf(events, "%s%s",
- j == 0 || no_group ? "{" : ",",
- ids[j]);
- no_group = false;
- }
- if (!no_group)
- strbuf_addf(events, "}:W");
- eg = malloc(sizeof(struct egroup));
- if (!eg) {
- ret = -ENOMEM;
- break;
+ eg->metric_name = strdup(value);
+ eg->metric_expr = pe->metric_expr;
+ eg->metric_unit = pe->unit;
+ list_add_tail(&eg->nd, group_list);
+ ret = 0;
}
- eg->ids = ids;
- eg->idnum = idnum;
- eg->metric_name = pe->metric_name;
- eg->metric_expr = pe->metric_expr;
- eg->metric_unit = pe->unit;
- list_add_tail(&eg->nd, group_list);
- ret = 0;
}
}
return ret;
diff --git a/tools/perf/util/metricgroup.h b/tools/perf/util/metricgroup.h
index 475c7f912864..81224ba1270d 100644
--- a/tools/perf/util/metricgroup.h
+++ b/tools/perf/util/metricgroup.h
@@ -34,4 +34,5 @@ int metricgroup__parse_groups(const struct option *opt,
void metricgroup__print(bool metrics, bool groups, char *filter,
bool raw, bool details);
bool metricgroup__has_metric(const char *metric);
+int arch_get_runtimeparam(void);
#endif
diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 2c41d47f6f83..147a39b1ff5b 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -780,7 +780,12 @@ static void generic_metric(struct perf_stat_config *config,
if (!metric_events[i]) {
const char *p = metric_expr;
+ if (strstr(p, "?")) {
+ char *tmp = strrchr(metric_name, '_');
+ tmp++;
+ expr__runtimeparam = strtol(tmp, &tmp, 10);
+ }
if (expr__parse(&ratio, &pctx, &p) == 0) {
char *unit;
char metric_bf[64];
--
2.18.1
^ permalink raw reply related
* [PATCH v2 5/8] powerpc/hv-24x7: Update post_mobility_fixup() to handle migration
From: Kajol Jain @ 2020-02-21 6:10 UTC (permalink / raw)
To: acme, linuxppc-dev, mpe, suka
Cc: mark.rutland, ravi.bangoria, maddy, tglx, jmario, peterz, gregkh,
mpetlan, alexander.shishkin, linux-perf-users, ak, yao.jin, anju,
mamatha4, kjain, jolsa, namhyung, mingo, kan.liang
In-Reply-To: <20200221061022.3047-1-kjain@linux.ibm.com>
Function 'read_sys_info_pseries()' is added to get system parameter
values like number of sockets and chips per socket.
and it gets these details via rtas_call with token
"PROCESSOR_MODULE_INFO".
Incase lpar migrate from one system to another, system
parameter details like chips per sockets or number of sockets might
change. So, it needs to be re-initialized otherwise, these values
corresponds to previous system values.
This patch adds a call to 'read_sys_info_pseries()' from
'post-mobility_fixup()' to re-init the physsockets and physchips values.
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/platforms/pseries/mobility.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index b571285f6c14..226accd6218b 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -371,6 +371,18 @@ void post_mobility_fixup(void)
/* Possibly switch to a new RFI flush type */
pseries_setup_rfi_flush();
+ /*
+ * Incase lpar migrate from one system to another, system
+ * parameter details like chips per sockets and number of sockets
+ * might change. So, it needs to be re-initialized otherwise these
+ * values corresponds to previous system.
+ * Here, adding a call to read_sys_info_pseries() declared in
+ * platforms/pseries/pseries.h to re-init the physsockets and
+ * physchips value.
+ */
+ if (IS_ENABLED(CONFIG_HV_PERF_CTRS) && IS_ENABLED(CONFIG_PPC_RTAS))
+ read_sys_info_pseries();
+
return;
}
--
2.18.1
^ permalink raw reply related
* [PATCH v2 4/8] Documentation/ABI: Add ABI documentation for chips and sockets
From: Kajol Jain @ 2020-02-21 6:10 UTC (permalink / raw)
To: acme, linuxppc-dev, mpe, suka
Cc: mark.rutland, ravi.bangoria, maddy, tglx, jmario, peterz, gregkh,
mpetlan, alexander.shishkin, linux-perf-users, ak, yao.jin, anju,
mamatha4, kjain, jolsa, namhyung, mingo, kan.liang
In-Reply-To: <20200221061022.3047-1-kjain@linux.ibm.com>
Add documentation for the following sysfs files:
/sys/devices/hv_24x7/interface/chips,
/sys/devices/hv_24x7/interface/sockets
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
.../testing/sysfs-bus-event_source-devices-hv_24x7 | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
index ec27c6c9e737..e26cb1770c61 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
@@ -22,6 +22,20 @@ Description:
Exposes the "version" field of the 24x7 catalog. This is also
extractable from the provided binary "catalog" sysfs entry.
+What: /sys/devices/hv_24x7/interface/sockets
+Date: December 2019
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: read only
+ This sysfs interface exposes the number of sockets present in the
+ system.
+
+What: /sys/devices/hv_24x7/interface/chips
+Date: December 2019
+Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
+Description: read only
+ This sysfs interface exposes the number of chips per socket
+ present in the system.
+
What: /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name>
Date: February 2014
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
--
2.18.1
^ permalink raw reply related
* [PATCH v2 3/8] powerpc/hv-24x7: Add sysfs files inside hv-24x7 device to show processor details
From: Kajol Jain @ 2020-02-21 6:10 UTC (permalink / raw)
To: acme, linuxppc-dev, mpe, suka
Cc: mark.rutland, ravi.bangoria, maddy, tglx, jmario, peterz, gregkh,
mpetlan, alexander.shishkin, linux-perf-users, ak, yao.jin, anju,
mamatha4, kjain, jolsa, namhyung, mingo, kan.liang
In-Reply-To: <20200221061022.3047-1-kjain@linux.ibm.com>
To expose the system dependent parameter like total number of
sockets and numbers of chips per socket, patch adds two sysfs files.
"sockets" and "chips" are added to /sys/devices/hv_24x7/interface/
of the "hv_24x7" pmu.
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/hv-24x7.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 4248a9d1e2ed..9e486ec7269f 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -454,6 +454,20 @@ static ssize_t device_show_string(struct device *dev,
return sprintf(buf, "%s\n", (char *)d->var);
}
+#ifdef CONFIG_PPC_RTAS
+static ssize_t sockets_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", physsockets);
+}
+
+static ssize_t chips_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%d\n", physchips);
+}
+#endif
+
static struct attribute *device_str_attr_create_(char *name, char *str)
{
struct dev_ext_attribute *attr = kzalloc(sizeof(*attr), GFP_KERNEL);
@@ -1100,6 +1114,10 @@ PAGE_0_ATTR(catalog_len, "%lld\n",
(unsigned long long)be32_to_cpu(page_0->length) * 4096);
static BIN_ATTR_RO(catalog, 0/* real length varies */);
static DEVICE_ATTR_RO(domains);
+#ifdef CONFIG_PPC_RTAS
+static DEVICE_ATTR_RO(sockets);
+static DEVICE_ATTR_RO(chips);
+#endif
static struct bin_attribute *if_bin_attrs[] = {
&bin_attr_catalog,
@@ -1110,6 +1128,10 @@ static struct attribute *if_attrs[] = {
&dev_attr_catalog_len.attr,
&dev_attr_catalog_version.attr,
&dev_attr_domains.attr,
+#ifdef CONFIG_PPC_RTAS
+ &dev_attr_sockets.attr,
+ &dev_attr_chips.attr,
+#endif
NULL,
};
--
2.18.1
^ permalink raw reply related
* [PATCH v2 2/8] powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details
From: Kajol Jain @ 2020-02-21 6:10 UTC (permalink / raw)
To: acme, linuxppc-dev, mpe, suka
Cc: mark.rutland, ravi.bangoria, maddy, tglx, jmario, peterz, gregkh,
mpetlan, alexander.shishkin, linux-perf-users, ak, yao.jin, anju,
mamatha4, kjain, jolsa, namhyung, mingo, kan.liang
In-Reply-To: <20200221061022.3047-1-kjain@linux.ibm.com>
For hv_24x7 socket/chip level events, specific chip-id to which
the data requested should be added as part of pmu events.
But number of chips/socket in the system details are not exposed.
Patch implements read_sys_info_pseries() to get system
parameter values like number of sockets and chips per socket.
Rtas_call with token "PROCESSOR_MODULE_INFO"
is used to get these values.
Sub-sequent patch exports these values via sysfs.
Patch also make these parameters default to 1.
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/hv-24x7.c | 72 ++++++++++++++++++++++++
arch/powerpc/platforms/pseries/pseries.h | 3 +
2 files changed, 75 insertions(+)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 6dbbf70232aa..4248a9d1e2ed 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -20,6 +20,11 @@
#include <asm/io.h>
#include <linux/byteorder/generic.h>
+#ifdef CONFIG_PPC_RTAS
+#include <asm/rtas.h>
+#include <../../platforms/pseries/pseries.h>
+#endif
+
#include "hv-24x7.h"
#include "hv-24x7-catalog.h"
#include "hv-common.h"
@@ -57,6 +62,69 @@ static bool is_physical_domain(unsigned domain)
}
}
+#ifdef CONFIG_PPC_RTAS
+#define PROCESSOR_MODULE_INFO 43
+#define PROCESSOR_MAX_LENGTH (8 * 1024)
+
+static int strbe16toh(const char *buf, int offset)
+{
+ return (buf[offset] << 8) + buf[offset + 1];
+}
+
+static u32 physsockets; /* Physical sockets */
+static u32 physchips; /* Physical chips */
+
+/*
+ * Function read_sys_info_pseries() make a rtas_call which require
+ * data buffer of size 8K. As standard 'rtas_data_buf' is of size
+ * 4K, we are adding new local buffer 'rtas_local_data_buf'.
+ */
+char rtas_local_data_buf[PROCESSOR_MAX_LENGTH] __cacheline_aligned;
+
+/*
+ * read_sys_info_pseries()
+ * Retrieve the number of sockets and chips per socket details
+ * through the get-system-parameter rtas call.
+ */
+void read_sys_info_pseries(void)
+{
+ int call_status, len, ntypes;
+
+ /*
+ * Making system parameter: chips and sockets default to 1.
+ */
+ physsockets = 1;
+ physchips = 1;
+ memset(rtas_local_data_buf, 0, PROCESSOR_MAX_LENGTH);
+ spin_lock(&rtas_data_buf_lock);
+
+ call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
+ NULL,
+ PROCESSOR_MODULE_INFO,
+ __pa(rtas_local_data_buf),
+ PROCESSOR_MAX_LENGTH);
+
+ spin_unlock(&rtas_data_buf_lock);
+
+ if (call_status != 0) {
+ pr_info("%s %s Error calling get-system-parameter (0x%x)\n",
+ __FILE__, __func__, call_status);
+ } else {
+ rtas_local_data_buf[PROCESSOR_MAX_LENGTH - 1] = '\0';
+ len = strbe16toh(rtas_local_data_buf, 0);
+ if (len < 6)
+ return;
+
+ ntypes = strbe16toh(rtas_local_data_buf, 2);
+
+ if (!ntypes)
+ return;
+ physsockets = strbe16toh(rtas_local_data_buf, 4);
+ physchips = strbe16toh(rtas_local_data_buf, 6);
+ }
+}
+#endif /* CONFIG_PPC_RTAS */
+
/* Domains for which more than one result element are returned for each event. */
static bool domain_needs_aggregation(unsigned int domain)
{
@@ -1615,6 +1683,10 @@ static int hv_24x7_init(void)
if (r)
return r;
+#ifdef CONFIG_PPC_RTAS
+ read_sys_info_pseries();
+#endif
+
return 0;
}
diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
index 13fa370a87e4..1727559ce304 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -19,6 +19,9 @@ extern void request_event_sources_irqs(struct device_node *np,
struct pt_regs;
extern int pSeries_system_reset_exception(struct pt_regs *regs);
+#ifdef CONFIG_PPC_RTAS
+extern void read_sys_info_pseries(void);
+#endif
extern int pSeries_machine_check_exception(struct pt_regs *regs);
extern long pseries_machine_check_realmode(struct pt_regs *regs);
--
2.18.1
^ permalink raw reply related
* [PATCH v2 1/8] powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run
From: Kajol Jain @ 2020-02-21 6:10 UTC (permalink / raw)
To: acme, linuxppc-dev, mpe, suka
Cc: mark.rutland, ravi.bangoria, maddy, tglx, jmario, peterz, gregkh,
mpetlan, alexander.shishkin, linux-perf-users, ak, yao.jin, anju,
mamatha4, kjain, jolsa, namhyung, mingo, kan.liang
In-Reply-To: <20200221061022.3047-1-kjain@linux.ibm.com>
Commit 2b206ee6b0df ("powerpc/perf/hv-24x7: Display change in counter
values")' added to print _change_ in the counter value rather then raw
value for 24x7 counters. Incase of transactions, the event count
is set to 0 at the beginning of the transaction. It also sets
the event's prev_count to the raw value at the time of initialization.
Because of setting event count to 0, we are seeing some weird behaviour,
whenever we run multiple 24x7 events at a time.
For example:
command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/,
hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}"
-C 0 -I 1000 sleep 100
1.000121704 120 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
1.000121704 5 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
2.000357733 8 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
2.000357733 10 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
3.000495215 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
3.000495215 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
4.000641884 56 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
4.000641884 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
5.000791887 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
Getting these large values in case we do -I.
As we are setting event_count to 0, for interval case, overall event_count is not
coming in incremental order. As we may can get new delta lesser then previous count.
Because of which when we print intervals, we are getting negative value which create
these large values.
This patch rather then setting event_count to 0, it change local64_set to
local64_add in function 'h_24x7_event_read'.
With this patch
In power9 platform
command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/,
hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}"
-C 0 -I 1000 sleep 100
1.000117685 93 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
1.000117685 1 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
2.000349331 98 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
2.000349331 2 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
3.000495900 131 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
3.000495900 4 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
4.000645920 204 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
4.000645920 61 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/
4.284169997 22 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/hv-24x7.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
index 573e0b309c0c..6dbbf70232aa 100644
--- a/arch/powerpc/perf/hv-24x7.c
+++ b/arch/powerpc/perf/hv-24x7.c
@@ -1409,7 +1409,7 @@ static void h_24x7_event_read(struct perf_event *event)
* that would require issuing a hcall, which would then
* defeat the purpose of using the txn interface.
*/
- local64_set(&event->count, 0);
+ local64_add(0, &event->count);
}
put_cpu_var(hv_24x7_reqb);
--
2.18.1
^ permalink raw reply related
* [PATCH v2 0/8] powerpc/perf: Add json file metric support for the hv_24x7 socket/chip level events
From: Kajol Jain @ 2020-02-21 6:10 UTC (permalink / raw)
To: acme, linuxppc-dev, mpe, suka
Cc: mark.rutland, ravi.bangoria, maddy, tglx, jmario, peterz, gregkh,
mpetlan, alexander.shishkin, linux-perf-users, ak, yao.jin, anju,
mamatha4, kjain, jolsa, namhyung, mingo, kan.liang
The hv_24×7 feature in IBM® POWER9™ processor-based servers provide the
facility to continuously collect large numbers of hardware performance
metrics efficiently and accurately.
First patch of the patchset fix inconsistent results we are getting when
we run multiple 24x7 events.
Patchset adds json file metric support for the hv_24x7 socket/chip level
events. "hv_24x7" pmu interface events needs system dependent parameter
like socket/chip/core. For example, hv_24x7 chip level events needs
specific chip-id to which the data is requested should be added as part
of pmu events.
So to enable JSON file support to "hv_24x7" interface, patchset expose
total number of sockets and chips per-socket details in sysfs
files (sockets, chips) under "/sys/devices/hv_24x7/interface/".
To get sockets and number of chips per sockets, patchset adds a rtas call
with token "PROCESSOR_MODULE_INFO" to get these details. Patchset also
handles partition migration case to re-init these system depended
parameters by adding proper calls in post_mobility_fixup() (mobility.c).
Patch 6 & 8 of the patchset handles perf tool plumbing needed to replace
the "?" character in the metric expression to proper value and hv_24x7
json metric file for different Socket/chip resources.
Patch set also enable Hz/hz prinitg for --metric-only option to print
metric data for bus frequency.
Changelog:
v1 -> v2
- Rename hv-24x7 metric json file as nest_metrics.json
Kajol Jain (8):
powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple
hv-24x7 events run
powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor
details
powerpc/hv-24x7: Add sysfs files inside hv-24x7 device to show
processor details
Documentation/ABI: Add ABI documentation for chips and sockets
powerpc/hv-24x7: Update post_mobility_fixup() to handle migration
perf/tools: Enhance JSON/metric infrastructure to handle "?"
tools/perf: Enable Hz/hz prinitg for --metric-only option
perf/tools/pmu-events/powerpc: Add hv_24x7 socket/chip level metric
events
.../sysfs-bus-event_source-devices-hv_24x7 | 14 +++
arch/powerpc/perf/hv-24x7.c | 96 ++++++++++++++-
arch/powerpc/platforms/pseries/mobility.c | 12 ++
arch/powerpc/platforms/pseries/pseries.h | 3 +
tools/perf/arch/powerpc/util/header.c | 40 +++++++
.../arch/powerpc/power9/nest_metrics.json | 19 +++
tools/perf/util/expr.h | 1 +
tools/perf/util/expr.y | 17 ++-
tools/perf/util/metricgroup.c | 112 +++++++++++-------
tools/perf/util/metricgroup.h | 1 +
tools/perf/util/stat-display.c | 2 -
tools/perf/util/stat-shadow.c | 5 +
12 files changed, 277 insertions(+), 45 deletions(-)
create mode 100644 tools/perf/pmu-events/arch/powerpc/power9/nest_metrics.json
--
2.18.1
^ permalink raw reply
* Re: [PATCH v3 04/27] ocxl: Remove unnecessary externs
From: Andrew Donnellan @ 2020-02-21 6:06 UTC (permalink / raw)
To: Alastair D'Silva, alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Arnd Bergmann, Greg Kurz, Nicholas Piggin,
Cédric Le Goater, Dan Williams, Hari Bathini, linux-mm,
Greg Kroah-Hartman, linux-kernel, Vishal Verma, Frederic Barrat,
Paul Mackerras, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-5-alastair@au1.ibm.com>
On 21/2/20 2:26 pm, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Function declarations don't need externs, remove the existing ones
> so they are consistent with newer code
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH v3 27/27] MAINTAINERS: Add myself & nvdimm/ocxl to ocxl
From: Andrew Donnellan @ 2020-02-21 5:35 UTC (permalink / raw)
To: Alastair D'Silva, alastair
Cc: Madhavan Srinivasan, Alexey Kardashevskiy, Masahiro Yamada,
Oliver O'Halloran, Mauro Carvalho Chehab, Ira Weiny,
Thomas Gleixner, Rob Herring, Dave Jiang, linux-nvdimm,
Aneesh Kumar K . V, Krzysztof Kozlowski, Anju T Sudhakar,
Mahesh Salgaonkar, Arnd Bergmann, Greg Kurz, Nicholas Piggin,
Cédric Le Goater, Dan Williams, Hari Bathini, linux-mm,
Greg Kroah-Hartman, linux-kernel, Vishal Verma, Frederic Barrat,
Paul Mackerras, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200221032720.33893-28-alastair@au1.ibm.com>
On 21/2/20 2:27 pm, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> The OpenCAPI Persistent Memory driver will be maintained as part ofi
> the ppc tree.
>
> I'm also adding myself as an author of the driver & contributor to
> the generic ocxl driver.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
You need to update the title of this patch :)
> ---
> MAINTAINERS | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f8670989ec91..3fb9a9f576a7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12064,13 +12064,16 @@ F: tools/objtool/
> OCXL (Open Coherent Accelerator Processor Interface OpenCAPI) DRIVER
> M: Frederic Barrat <fbarrat@linux.ibm.com>
> M: Andrew Donnellan <ajd@linux.ibm.com>
> +M: Alastair D'Silva <alastair@d-silva.org>
> L: linuxppc-dev@lists.ozlabs.org
> S: Supported
> F: arch/powerpc/platforms/powernv/ocxl.c
> +F: arch/powerpc/platforms/powernv/pmem/*
> F: arch/powerpc/include/asm/pnv-ocxl.h
> F: drivers/misc/ocxl/
> F: include/misc/ocxl*
> F: include/uapi/misc/ocxl.h
> +F: include/uapi/nvdimm/ocxl-pmem.h
> F: Documentation/userspace-api/accelerators/ocxl.rst
Should this be part of the ocxl entry or a separate entry? I guess I
don't care too much either way.
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH v2 5/5] Documentation: Document sysfs interfaces purr, spurr, idle_purr, idle_spurr
From: Gautham R. Shenoy @ 2020-02-21 5:18 UTC (permalink / raw)
To: Nathan Lynch, Michael Ellerman, Vaidyanathan Srinivasan,
Kamalesh Babulal, Naveen N. Rao, Tyrel Datwyler
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1582262314-8319-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
Add documentation for the following sysfs interfaces:
/sys/devices/system/cpu/cpuX/purr
/sys/devices/system/cpu/cpuX/spurr
/sys/devices/system/cpu/cpuX/idle_purr
/sys/devices/system/cpu/cpuX/idle_spurr
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 2e0e3b4..799dc737a 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -580,3 +580,42 @@ Description: Secure Virtual Machine
If 1, it means the system is using the Protected Execution
Facility in POWER9 and newer processors. i.e., it is a Secure
Virtual Machine.
+
+What: /sys/devices/system/cpu/cpuX/purr
+Date: Apr 2005
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: PURR ticks for this CPU since the system boot.
+
+ The Processor Utilization Resources Register (PURR) is
+ a 64-bit counter which provides an estimate of the
+ resources used by the CPU thread. The contents of this
+ register increases monotonically. This sysfs interface
+ exposes the number of PURR ticks for cpuX.
+
+What: /sys/devices/system/cpu/cpuX/spurr
+Date: Dec 2006
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: SPURR ticks for this CPU since the system boot.
+
+ The Scaled Processor Utilization Resources Register
+ (SPURR) is a 64-bit counter that provides a frequency
+ invariant estimate of the resources used by the CPU
+ thread. The contents of this register increases
+ monotonically. This sysfs interface exposes the number
+ of SPURR ticks for cpuX.
+
+What: /sys/devices/system/cpu/cpuX/idle_purr
+Date: Nov 2019
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: PURR ticks for cpuX when it was idle.
+
+ This sysfs interface exposes the number of PURR ticks
+ for cpuX when it was idle.
+
+What: /sys/devices/system/cpu/cpuX/spurr
+Date: Nov 2019
+Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
+Description: SPURR ticks for cpuX when it was idle.
+
+ This sysfs interface exposes the number of SPURR ticks
+ for cpuX when it was idle.
--
1.9.4
^ permalink raw reply related
* [PATCH v2 3/5] powerpc/pseries: Account for SPURR ticks on idle CPUs
From: Gautham R. Shenoy @ 2020-02-21 5:18 UTC (permalink / raw)
To: Nathan Lynch, Michael Ellerman, Vaidyanathan Srinivasan,
Kamalesh Babulal, Naveen N. Rao, Tyrel Datwyler
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1582262314-8319-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
On Pseries LPARs, to calculate utilization, we need to know the
[S]PURR ticks when the CPUs were busy or idle.
Via idle_loop_prolog(), idle_loop_epilog(), we track the idle PURR
ticks in the VPA variable "wait_state_cycles". This patch extends the
support to account for the idle SPURR ticks. It also provides an
accessor function to accurately reads idle SPURR ticks.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/idle.h | 33 +++++++++++++++++++++++++++++++++
arch/powerpc/platforms/pseries/setup.c | 2 ++
2 files changed, 35 insertions(+)
diff --git a/arch/powerpc/include/asm/idle.h b/arch/powerpc/include/asm/idle.h
index 126a217..db82fc1 100644
--- a/arch/powerpc/include/asm/idle.h
+++ b/arch/powerpc/include/asm/idle.h
@@ -2,13 +2,20 @@
#define _ASM_POWERPC_IDLE_H
#include <asm/runlatch.h>
+DECLARE_PER_CPU(u64, idle_spurr_cycles);
DECLARE_PER_CPU(u64, idle_entry_purr_snap);
+DECLARE_PER_CPU(u64, idle_entry_spurr_snap);
static inline void snapshot_purr_idle_entry(void)
{
*this_cpu_ptr(&idle_entry_purr_snap) = mfspr(SPRN_PURR);
}
+static inline void snapshot_spurr_idle_entry(void)
+{
+ *this_cpu_ptr(&idle_entry_spurr_snap) = mfspr(SPRN_SPURR);
+}
+
static inline void update_idle_purr_accounting(void)
{
u64 wait_cycles;
@@ -19,10 +26,19 @@ static inline void update_idle_purr_accounting(void)
get_lppaca()->wait_state_cycles = cpu_to_be64(wait_cycles);
}
+static inline void update_idle_spurr_accounting(void)
+{
+ u64 *idle_spurr_cycles_ptr = this_cpu_ptr(&idle_spurr_cycles);
+ u64 in_spurr = *this_cpu_ptr(&idle_entry_spurr_snap);
+
+ *idle_spurr_cycles_ptr += mfspr(SPRN_SPURR) - in_spurr;
+}
+
static inline void idle_loop_prolog(void)
{
ppc64_runlatch_off();
snapshot_purr_idle_entry();
+ snapshot_spurr_idle_entry();
/*
* Indicate to the HV that we are idle. Now would be
* a good time to find other work to dispatch.
@@ -33,6 +49,7 @@ static inline void idle_loop_prolog(void)
static inline void idle_loop_epilog(void)
{
update_idle_purr_accounting();
+ update_idle_spurr_accounting();
get_lppaca()->idle = 0;
ppc64_runlatch_on();
}
@@ -52,4 +69,20 @@ static inline u64 read_this_idle_purr(void)
return be64_to_cpu(get_lppaca()->wait_state_cycles);
}
+
+static inline u64 read_this_idle_spurr(void)
+{
+ /*
+ * If we are reading from an idle context, update the
+ * idle-spurr cycles corresponding to the last idle period.
+ * Since the idle context is not yet over, take a fresh
+ * snapshot of the idle-spurr.
+ */
+ if (get_lppaca()->idle == 1) {
+ update_idle_spurr_accounting();
+ snapshot_spurr_idle_entry();
+ }
+
+ return *this_cpu_ptr(&idle_spurr_cycles);
+}
#endif
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index e9f2cefa..5ef5c82 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -318,7 +318,9 @@ static int alloc_dispatch_log_kmem_cache(void)
}
machine_early_initcall(pseries, alloc_dispatch_log_kmem_cache);
+DEFINE_PER_CPU(u64, idle_spurr_cycles);
DEFINE_PER_CPU(u64, idle_entry_purr_snap);
+DEFINE_PER_CPU(u64, idle_entry_spurr_snap);
static void pseries_lpar_idle(void)
{
/*
--
1.9.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox