kernel/git/stable/linux.git/arch/powerpc/perf, branch linux-6.0.y

powerpc/hv-gpci: Fix hv_gpci event list

2022-12-31T12:26:34+00:00

[ Upstream commit 03f7c1d2a49acd30e38789cd809d3300721e9b0e ] Based on getPerfCountInfo v1.018 documentation, some of the hv_gpci events were deprecated for platform firmware that supports counter_info_version 0x8 or above. Fix the hv_gpci event list by adding a new attribute group called "hv_gpci_event_attrs_v6" and a "ENABLE_EVENTS_COUNTERINFO_V6" macro to enable these events for platform firmware that supports counter_info_version 0x6 or below. And assigning the hv_gpci event list based on output counter info version of underlying plaform. Fixes: 97bf2640184f ("powerpc/perf/hv-gpci: add the remaining gpci requests") Signed-off-by: Kajol Jain Reviewed-by: Madhavan Srinivasan Reviewed-by: Athira Rajeev Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221130174513.87501-1-kjain@linux.ibm.com Signed-off-by: Sasha Levin

powerpc/perf: callchain validate kernel stack pointer bounds

2022-12-31T12:26:34+00:00

[ Upstream commit 32c5209214bd8d4f8c4e9d9b630ef4c671f58e79 ] The interrupt frame detection and loads from the hypothetical pt_regs are not bounds-checked. The next-frame validation only bounds-checks STACK_FRAME_OVERHEAD, which does not include the pt_regs. Add another test for this. The user could set r1 to be equal to the address matching the first interrupt frame - STACK_INT_FRAME_SIZE, which is in the previous page due to the kernel redzone, and induce the kernel to load the marker from there. Possibly this could cause a crash at least. If the user could induce the previous page to contain a valid marker, then it might be able to direct perf to read specific memory addresses in a way that could be transmitted back to the user in the perf data. Fixes: 20002ded4d93 ("perf_counter: powerpc: Add callchain support") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221127124942.1665522-4-npiggin@gmail.com Signed-off-by: Sasha Levin

powerpc/perf: Include caps feature for power10 DD1 version

2022-08-01T12:21:18+00:00

Commit 6320e693d98c ("powerpc/perf: Add support for caps under sysfs in powerpc") added support for caps under sysfs in powerpc. This added caps directory to: /sys/bus/event_source/devices/cpu/ for power8, power9, power10 and generic compat PMU in respective PMU driver code. For power10, it is added under "power10_pmu_attr_groups". But for DD1 version, attr_groups are defined under dd1 array: "power10_pmu_attr_groups_dd1". Since caps is not added for DD1, it fails to include "cpu/caps" in DD1 model. The issue was observed while booting power10 pseries with qemu version 6, but not observed with qemu version 7. This is because qemu version 7 uses a DD 2.0 CPU model. Below is the trace log: Can't update unknown attr grp name: cpu/caps^M ------------[ cut here ]------------^M Failed to register pmu: cpu, reason -22^M WARNING: CPU: 1 PID: 1 at kernel/events/core.c:13427 perf_event_sysfs_init+0xbc/0x108^M Modules linked in:^M CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00111-g6320e693d98c #148^M NIP: c0000000020391f4 LR: c0000000020391f0 CTR: c0000000008c9c30^M REGS: c0000000044c38c0 TRAP: 0700 Not tainted (5.19.0-rc2-00111-g6320e693d98c)^M MSR: 8000000002029033 CR: 48000281 XER: 20040000^M CFAR: c00000000013feac IRQMASK: 0 ^M GPR00: c0000000020391f0 c0000000044c3b60 c00000000283db00 0000000000000027 ^M GPR04: 80000000ffffe0a8 0000000000000000 0000000000000004 00000000fdcd0000 ^M GPR08: 0000000000000027 c0000000ffe07e08 0000000000000001 0000000000000000 ^M GPR12: c00000000035dd90 c0000000fffff300 c000000000012478 0000000000000000 ^M GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ^M GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 ^M GPR24: c000000002003480 0000000000000007 c0000000012a78d0 c000000001170a80 ^M GPR28: c0000000026c4df8 c0000000026c4e68 0000000000000000 c0000000025a8628 ^M NIP [c0000000020391f4] perf_event_sysfs_init+0xbc/0x108^M LR [c0000000020391f0] perf_event_sysfs_init+0xb8/0x108^M Call Trace:^M [c0000000044c3b60] [c0000000020391f0] perf_event_sysfs_init+0xb8/0x108 (unreliable)^M [c0000000044c3bf0] [c000000000011ec4] do_one_initcall+0x64/0x2d0^M [c0000000044c3cd0] [c0000000020049fc] kernel_init_freeable+0x338/0x3e0^M [c0000000044c3db0] [c0000000000124a0] kernel_init+0x30/0x1a0^M [c0000000044c3e10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64^M Instruction dump:^M 813f0038 2c090000 4180002c 7fe3fb78 4a3280c5 2c030000 7c651b78 41820018 ^M e89f0030 7f63db78 4a106c59 60000000 <0fe00000> ebff0000 4bffffb4 39200001 ^M ---[ end trace 0000000000000000 ]---^M Fix it by adding caps for dd1 attr_groups in power10 PMU driver. Fixes: 6320e693d98c ("powerpc/perf: Add support for caps under sysfs in powerpc") Signed-off-by: Athira Rajeev [mpe: Update change log to mention qemu 7 DD2.0 CPU model] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220728163746.85062-1-atrajeev@linux.vnet.ibm.com

powerpc/perf: Use PVR rather than oprofile field to determine CPU version

2022-07-27T11:36:05+00:00

Currently the perf CPU backend drivers detect what CPU they're on using cur_cpu_spec->oprofile_cpu_type. Although that works, it's a bit crufty to be using oprofile related fields, especially seeing as oprofile is more or less unused these days. It also means perf is reliant on the fragile logic in setup_cpu_spec() which detects when we're using a logical PVR and copies back the PMU related fields from the raw CPU entry. So lets check the PVR directly. Suggested-by: Michael Ellerman Signed-off-by: Rashmica Gupta Signed-off-by: Christophe Leroy Reviewed-by: Madhavan Srinivasan [chleroy: Added power10 and fixed checkpatch issues] Reviewed-and-tested-by: Athira Rajeev Reviewed-and-tested-By: Kajol Jain [For 24x7 side changes] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20c0ee7f99dbf0dbf8658df6b39f84753e6db1ef.1657204631.git.christophe.leroy@csgroup.eu

powerpc/perf: Add support for caps under sysfs in powerpc

2022-07-18T00:39:54+00:00

Add caps support under "/sys/bus/event_source/devices//" for powerpc. This directory can be used to expose some of the specific features that powerpc PMU supports to the user. Example: pmu_name. The name of PMU registered will depend on platform, say power9 or power10 or it could be Generic Compat PMU. Currently the only way to know which is the registered PMU is from the dmesg logs. But clearing the dmesg will make it difficult to know exact PMU backend used. And even extracting from dmesg will be complicated, as we need to parse the dmesg logs and add filters for pmu name. Whereas by exposing it via caps will make it easy as we just need to directly read it from the sysfs. Add a caps directory to /sys/bus/event_source/devices/cpu/ for power8, power9, power10 and generic compat PMU in respective PMU driver code. Update the pmu_name file under caps folder in core-book3s using "attr_update". The information exposed currently: - pmu_name : Underlying PMU name from the driver Example result with power9 pmu: # ls /sys/bus/event_source/devices/cpu/caps pmu_name # cat /sys/bus/event_source/devices/cpu/caps/pmu_name POWER9 Signed-off-by: Athira Rajeev Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220520084630.15181-1-atrajeev@linux.vnet.ibm.com

powerpc/perf: Give generic PMU a nice name

2022-07-18T00:36:25+00:00

When booting on a machine that uses the compat pmu driver we see this: [ 0.071192] GENERIC_COMPAT performance monitor hardware support registered Which is a bit shouty. Give it a nicer name. Signed-off-by: Joel Stanley Reviewed-by: Athira Rajeev Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220610044006.2095806-1-joel@jms.id.au

powerpc/perf: Update MMCR2 to support event exclude_idle

2022-06-29T09:42:41+00:00

struct perf_event_attr supports exclude counting of idle task. This is sent to kernel via perf_event_attr.exclude_idle and in perf tool, user can use ":I" event modifier to enable this for specific event. Monitor Mode Control Register 2 (MMCR2) SPR has control bits for each PMCs to freeze counting based on the Control Register CTRL[RUN] state. CTRL[RUN] is not set when idle task is running. Patch adds a check for event attr.exclude_idle to set MMCR2[FCnWAIT] bit. Signed-off-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210429050208.266619-1-maddy@linux.ibm.com

powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable

2022-06-28T13:41:15+00:00

commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") added a new function "pmi_irq_pending" in hw_irq.h. This function is to check if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown. During some of the perf runs, below warning is hit: WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Modules linked in: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function "any_pmc_overflown" checks the PMCs on active events in cpuhw->n_events. Code snippet: <<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>> Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from trace_printk: <<>> any_pmc_overflown: idx is 5: pmc value is 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt") Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function: perf_event_interrupt, already we ignore PMI's overflown when it is from an inactive PMC. 2) Fix 2: optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SPR read also. From point 1, we know that if PMI pending in Paca from inactive cases, that is going to be ignored during replay. Hence if there is pending PMI in Paca, just clear it irrespective of PMC overflown or not. In summary, remove the any_pmc_overflown check entirely in power_pmu_disable. ie If there is a pending PMI in Paca, clear it, since we are in pmu_disable. There could be cases where PMI is pending because of inactive PMC ( which later when replayed also will get ignored ), so WARN_ON could give false warning. Hence removing it. Fixes: 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") Signed-off-by: Athira Rajeev Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220522142256.24699-1-atrajeev@linux.vnet.ibm.com

powerpc/perf: Fix the threshold compare group constraint for power9

2022-05-22T05:58:30+00:00

Thresh compare bits for a event is used to program thresh compare field in Monitor Mode Control Register A (MMCRA: 9-18 bits for power9). When scheduling events as a group, all events in that group should match value in threshold bits (like thresh compare, thresh control, thresh select). Otherwise event open for the sibling events should fail. But in the current code, incase thresh compare bits are not valid, we are not failing in group_constraint function which can result in invalid group schduling. Fix the issue by returning -1 incase event is threshold and threshold compare value is not valid. Thresh control bits in the event code is used to program thresh_ctl field in Monitor Mode Control Register A (MMCRA: 48-55). In below example, the scheduling of group events PM_MRK_INST_CMPL (873534401e0) and PM_THRESH_MET (8734340101ec) is expected to fail as both event request different thresh control bits and invalid thresh compare value. Result before the patch changes: [command]# perf stat -e "{r8735340401e0,r8734340101ec}" sleep 1 Performance counter stats for 'sleep 1': 11,048 r8735340401e0 1,967 r8734340101ec 1.001354036 seconds time elapsed 0.001421000 seconds user 0.000000000 seconds sys Result after the patch changes: [command]# perf stat -e "{r8735340401e0,r8734340101ec}" sleep 1 Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (r8735340401e0). /bin/dmesg | grep -i perf may provide additional information. Fixes: 78a16d9fc1206 ("powerpc/perf: Avoid FAB_*_MATCH checks for power9") Signed-off-by: Kajol Jain Reviewed-by: Athira Rajeev Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220506061015.43916-2-kjain@linux.ibm.com

powerpc/perf: Fix the threshold compare group constraint for power10

2022-05-22T05:58:29+00:00

Thresh compare bits for a event is used to program thresh compare field in Monitor Mode Control Register A (MMCRA: 8-18 bits for power10). When scheduling events as a group, all events in that group should match value in threshold bits. Otherwise event open for the sibling events should fail. But in the current code, incase thresh compare bits are not valid, we are not failing in group_constraint function which can result in invalid group schduling. Fix the issue by returning -1 incase event is threshold and threshold compare value is not valid in group_constraint function. Patch also fixes the p10_thresh_cmp_val function to return -1, incase threshold bits are not valid and changes corresponding check in is_thresh_cmp_valid function to return false only when the thresh_cmp value is less then 0. Thresh control bits in the event code is used to program thresh_ctl field in Monitor Mode Control Register A (MMCRA: 48-55). In below example, the scheduling of group events PM_MRK_INST_CMPL (3534401e0) and PM_THRESH_MET (34340101ec) is expected to fail as both event request different thresh control bits. Result before the patch changes: [command]# perf stat -e "{r35340401e0,r34340101ec}" sleep 1 Performance counter stats for 'sleep 1': 8,482 r35340401e0 0 r34340101ec 1.001474838 seconds time elapsed 0.001145000 seconds user 0.000000000 seconds sys Result after the patch changes: [command]# perf stat -e "{r35340401e0,r34340101ec}" sleep 1 Performance counter stats for 'sleep 1': r35340401e0 r34340101ec 1.001499607 seconds time elapsed 0.000204000 seconds user 0.000760000 seconds sys Fixes: 82d2c16b350f7 ("powerpc/perf: Adds support for programming of Thresholding in P10") Signed-off-by: Kajol Jain Reviewed-by: Athira Rajeev Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220506061015.43916-1-kjain@linux.ibm.com