summaryrefslogtreecommitdiff
path: root/drivers/perf
AgeCommit message (Collapse)Author
2025-03-13Merge branch 'perf/m1-guest-events' of ↵Will Deacon
git://git.kernel.org/pub/scm/linux/kernel/git/oupton/linux into for-next/perf Pull Apple-M1 PMU driver changes from Oliver Upton, which form a prefix of the series in the KVM/Arm tree that allows the PMU to be virtualised. Sort of, anyway. * 'perf/m1-guest-events' of git://git.kernel.org/pub/scm/linux/kernel/git/oupton/linux: drivers/perf: apple_m1: Support host/guest event filtering drivers/perf: apple_m1: Refactor event select/filter configuration
2025-03-11drivers/perf: apple_m1: Provide helper for mapping PMUv3 eventsOliver Upton
Apple M* parts carry some IMP DEF traps for guest accesses to PMUv3 registers, even though the underlying hardware doesn't implement PMUv3. This means it is possible to virtualize PMUv3 for KVM guests. Add a helper for mapping common PMUv3 event IDs onto hardware event IDs, keeping the implementation-specific crud in the PMU driver rather than KVM proper. Populate the pmceid_bitmap based on the supported events so KVM can provide synthetic PMCEID* values to the guest. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-13-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11drivers/perf: apple_m1: Support host/guest event filteringOliver Upton
The PMU appears to have a separate register for filtering 'guest' exception levels (i.e. EL1 and !ELIsInHost(EL0)) which has the same layout as PMCR1_EL1. Conveniently, there exists a VHE register alias (PMCR1_EL12) that can be used to configure it. Support guest events by programming the EL12 register with the intended guest kernel/userspace filters. Limit support for guest events to VHE (i.e. kernel running at EL2), as it avoids involving KVM to context switch PMU registers. VHE is the only supported mode on M* parts anyway, so this isn't an actual feature limitation. Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-3-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-11drivers/perf: apple_m1: Refactor event select/filter configurationOliver Upton
Supporting guest mode events will necessitate programming two event filters. Prepare by splitting up the programming of the event selector + event filter into separate headers. Opportunistically replace RMW patterns with sysreg_clear_set_s(). Tested-by: Janne Grunau <j@jannau.net> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250305202641.428114-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-03-03perf/dwc_pcie: Move common DWC struct definitions to 'pcie-dwc.h'Manivannan Sadhasivam
Move the common DWC struct definitions, which are shared across all the DesginWare PCIe IPs, to a new header file called 'pcie-dwc.h', so that other users e.g., debugfs, perf and sysfs can make use of them. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Shradha Todi <shradha.t@samsung.com> Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Tested-by: Hrishikesh Deleep <hrishikesh.d@samsung.com> Link: https://lore.kernel.org/r/20250221131548.59616-2-shradha.t@samsung.com [kwilczynski: commit log, tidy up the new header file] Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
2025-03-01perf/dwc_pcie: fix duplicate pci_dev devicesYunhui Cui
During platform_device_register, wrongly using struct device pci_dev as platform_data caused a kmemdup copy of pci_dev. Worse still, accessing the duplicated device leads to list corruption as its mutex content (e.g., list, magic) remains the same as the original. Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com> Link: https://lore.kernel.org/r/20250220121716.50324-3-cuiyunhui@bytedance.com Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf/dwc_pcie: fix some unreleased resourcesYunhui Cui
Release leaked resources, such as plat_dev and dev_info. Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com> Link: https://lore.kernel.org/r/20250220121716.50324-2-cuiyunhui@bytedance.com Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf/arm-cmn: Minor event type housekeepingRobin Murphy
While handling RN-D nodes under the functionally-identical RN-I type works fine for perf tool users using the "rnid_" event aliases, and that is the documented and expected ABI, there's little reason not to be permissive and accept the actual RN-D type as an additional encoding for the same events as well. This may be convenient for other tooling generating event configs directly from its own topology data. In the RN-I event mood, it also seems as good a time as any to clean up a forgotten macro for CCLA_RNI events which ended up being unnecessary. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Link: https://lore.kernel.org/r/ef46a47fc4ab909093f14b2b4289a4835836ab6c.1738851844.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: apple_m1: Don't disable counter in m1_pmu_enable_event()Rob Herring (Arm)
Currently m1_pmu_enable_event() starts by disabling the event counter it has been asked to enable. This should not be necessary as the counter (and the PMU as a whole) should not be active when m1_pmu_enable_event() is called. Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-6-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: arm_v7_pmu: Don't disable counter in ↵Rob Herring (Arm)
(armv7|krait_|scorpion_)pmu_enable_event() Currently (armv7|krait_|scorpion_)pmu_enable_event() start by disabling the event counter it has been asked to enable. This should not be necessary as the counter (and the PMU as a whole) should not be active when *_enable_event() is called. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-5-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: arm_v7_pmu: Drop obvious comments for enabling/disabling counters and ↵Rob Herring (Arm)
interrupts The function calls for enabling/disabling counters and interrupts are pretty obvious as to what they are doing, and the comments don't add any additional value. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-4-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: arm_pmuv3: Don't disable counter in armv8pmu_enable_event()Mark Rutland
Currently armv8pmu_enable_event() starts by disabling the event counter it has been asked to enable. This should not be necessary as the counter (and the PMU as a whole) should not be active when armv8pmu_enable_event() is called. Remove the redundant call to armv8pmu_disable_event_counter(). At the same time, remove the comment immeditately above as everything it says is obvious from the function names below. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-3-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: arm_pmu: Don't disable counter in armpmu_add()Mark Rutland
Currently armpmu_add() tries to handle a newly-allocated counter having a stale associated event, but this should not be possible, and if this were to happen the current mitigation is insufficient and potentially expensive. It would be better to warn if we encounter the impossible case. Calls to pmu::add() and pmu::del() are serialized by the core perf code, and armpmu_del() clears the relevant slot in pmu_hw_events::events[] before clearing the bit in pmu_hw_events::used_mask such that the counter can be reallocated. Thus when armpmu_add() allocates a counter index from pmu_hw_events::used_mask, it should not be possible to observe a stale even in pmu_hw_events::events[] unless either pmu_hw_events::used_mask or pmu_hw_events::events[] have been corrupted. If this were to happen, we'd end up with two events with the same event->hw.idx, which would clash with each other during reprogramming, deletion, etc, and produce bogus results. Add a WARN_ON_ONCE() for this case so that we can detect if this ever occurs in practice. That possiblity aside, there's no need to call arm_pmu::disable(event) for the new event. The PMU reset code initialises the counter in a disabled state, and armpmu_del() will disable the counter before it can be reused. Remove the redundant disable. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-2-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-03-01perf: arm_pmuv3: Call kvm_vcpu_pmu_resync_el0() before enabling countersRob Herring (Arm)
Counting events related to setup of the PMU is not desired, but kvm_vcpu_pmu_resync_el0() is called just after the PMU counters have been enabled. Move the call to before enabling the counters. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Tested-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-1-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-02-28perf: arm_pmuv3: Add support for ARM Rainier PMUVincenzo Frascino
Add support for the ARM Rainier CPU core PMU. Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250221180349.1413089-7-vincenzo.frascino@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-02-26perf: Remove unnecessary parameter of security checkLuo Gengkun
It seems that the attr parameter was never been used in security checks since it was first introduced by: commit da97e18458fb ("perf_event: Add support for LSM and SELinux checks") so remove it. Signed-off-by: Luo Gengkun <luogengkun@huaweicloud.com> Reviewed-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Paul Moore <paul@paul-moore.com>
2025-02-18drivers: perf: Switch to use hrtimer_setup()Nam Cao
hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/all/471ea3b829d14a4b4c3c7814dbe1ed13b15d47b8.1738746904.git.namcao@linutronix.de
2025-01-28treewide: const qualify ctl_tables where applicableJoel Granados
Add the const qualifier to all the ctl_tables in the tree except for watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls, loadpin_sysctl_table and the ones calling register_net_sysctl (./net, drivers/inifiniband dirs). These are special cases as they use a registration function with a non-const qualified ctl_table argument or modify the arrays before passing them on to the registration function. Constifying ctl_table structs will prevent the modification of proc_handler function pointers as the arrays would reside in .rodata. This is made possible after commit 78eb4ea25cd5 ("sysctl: treewide: constify the ctl_table argument of proc_handlers") constified all the proc_handlers. Created this by running an spatch followed by a sed command: Spatch: virtual patch @ depends on !(file in "net") disable optional_qualifier @ identifier table_name != { watchdog_hardlockup_sysctl, iwcm_ctl_table, ucma_ctl_table, memory_allocation_profiling_sysctls, loadpin_sysctl_table }; @@ + const struct ctl_table table_name [] = { ... }; sed: sed --in-place \ -e "s/struct ctl_table .table = &uts_kern/const struct ctl_table *table = \&uts_kern/" \ kernel/utsname_sysctl.c Reviewed-by: Song Liu <song@kernel.org> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> # for kernel/trace/ Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI Reviewed-by: Darrick J. Wong <djwong@kernel.org> # xfs Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Corey Minyard <cminyard@mvista.com> Acked-by: Wei Liu <wei.liu@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Bill O'Donnell <bodonnel@redhat.com> Acked-by: Baoquan He <bhe@redhat.com> Acked-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Acked-by: Anna Schumaker <anna.schumaker@oracle.com> Signed-off-by: Joel Granados <joel.granados@kernel.org>
2025-01-20Merge tag 'arm64-upstream' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 updates from Will Deacon: "We've got a little less than normal thanks to the holidays in December, but there's the usual summary below. The highlight is probably the 52-bit physical addressing (LPA2) clean-up from Ard. Confidential Computing: - Register a platform device when running in CCA realm mode to enable automatic loading of dependent modules CPU Features: - Update a bunch of system register definitions to pick up new field encodings from the architectural documentation - Add hwcaps and selftests for the new (2024) dpISA extensions Documentation: - Update EL3 (firmware) requirements for booting Linux on modern arm64 designs - Remove stale information about the kernel virtual memory map Miscellaneous: - Minor cleanups and typo fixes Memory management: - Fix vmemmap_check_pmd() to look at the PMD type bits - LPA2 (52-bit physical addressing) cleanups and minor fixes - Adjust physical address space depending upon whether or not LPA2 is enabled Perf and PMUs: - Add port filtering support for NVIDIA's NVLINK-C2C Coresight PMU - Extend AXI filtering support for the DDR PMU on NXP IMX SoCs - Fix Designware PCIe PMU event numbering - Add generic branch events for the Apple M1 CPU PMU - Add support for Marvell Odyssey DDR and LLC-TAD PMUs - Cleanups to the Hisilicon DDRC and Uncore PMU code - Advertise discard mode for the SPE PMU - Add the perf users mailing list to our MAINTAINERS entry" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (64 commits) Documentation: arm64: Remove stale and redundant virtual memory diagrams perf docs: arm_spe: Document new discard mode perf: arm_spe: Add format option for discard mode MAINTAINERS: Add perf list for drivers/perf/ arm64: Remove duplicate included header drivers/perf: apple_m1: Map generic branch events arm64: rsi: Add automatic arm-cca-guest module loading kselftest/arm64: Add 2024 dpISA extensions to hwcap test KVM: arm64: Allow control of dpISA extensions in ID_AA64ISAR3_EL1 arm64/hwcap: Describe 2024 dpISA extensions to userspace arm64/sysreg: Update ID_AA64SMFR0_EL1 to DDI0601 2024-12 arm64: Filter out SVE hwcaps when FEAT_SVE isn't implemented drivers/perf: hisi: Set correct IRQ affinity for PMUs with no association arm64/sme: Move storage of reg_smidr to __cpuinfo_store_cpu() arm64: mm: Test for pmd_sect() in vmemmap_check_pmd() arm64/mm: Replace open encodings with PXD_TABLE_BIT arm64/mm: Rename pte_mkpresent() as pte_mkvalid() arm64/sysreg: Update ID_AA64ISAR2_EL1 to DDI0601 2024-09 arm64/sysreg: Update ID_AA64ZFR0_EL1 to DDI0601 2024-09 arm64/sysreg: Update ID_AA64FPFR0_EL1 to DDI0601 2024-09 ...
2025-01-10perf: arm_spe: Add format option for discard modeJames Clark
FEAT_SPEv1p2 (optional from Armv8.6) adds a discard mode that allows all SPE data to be discarded rather than written to memory. Add a format bit for this mode. If the mode isn't supported, the format bit isn't published and attempts to use it will result in -EOPNOTSUPP. Allocating an aux buffer is still allowed even though it won't be written to so that old tools continue to work, but updated tools can choose to skip this step. Signed-off-by: James Clark <james.clark@linaro.org> Reviewd-by: Yeoreum Yun <yeoreum.yun@arm.com> Link: https://lore.kernel.org/r/20250108142904.401139-2-james.clark@linaro.org Signed-off-by: Will Deacon <will@kernel.org>
2025-01-10drivers/perf: apple_m1: Map generic branch eventsOliver Upton
Map the generic perf events for branch prediction stats to the corresponding hardware events. Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Tested-by: Janne Grunau <j@jannau.net> Link: https://lore.kernel.org/r/20241217212048.3709204-4-oliver.upton@linux.dev Signed-off-by: Will Deacon <will@kernel.org>
2025-01-09Merge patch series "SBI PMU event related fixes"Palmer Dabbelt
Atish Patra <atishp@rivosinc.com> says: Here are two minor improvement/fixes in the PMU event path. The first patch was part of the series[1]. The 2nd patch was suggested during the series review. While the series can only be merged once SBI v3.0 is frozen, these two patches can be independent of SBI v3.0 and can be merged sooner. Hence, these two patches are sent as a separate series. * b4-shazam-merge: drivers/perf: riscv: Do not allow invalid raw event config drivers/perf: riscv: Return error for default case drivers/perf: riscv: Fix Platform firmware event data Link: https://lore.kernel.org/r/20241212-pmu_event_fixes_v2-v2-0-813e8a4f5962@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-09drivers/perf: riscv: Do not allow invalid raw event configAtish Patra
The SBI specification allows only lower 48bits of hpmeventX to be configured via SBI PMU. Currently, the driver masks of the higher bits but doesn't return an error. This will lead to an additional SBI call for config matching which should return for an invalid event error in most of the cases. However, if a platform(i.e Rocket and sifive cores) implements a bitmap of all bits in the event encoding this will lead to an incorrect event being programmed leading to user confusion. Report the error to the user if higher bits are set during the event mapping itself to avoid the confusion and save an additional SBI call. Suggested-by: Samuel Holland <samuel.holland@sifive.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20241212-pmu_event_fixes_v2-v2-3-813e8a4f5962@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-09drivers/perf: riscv: Return error for default caseAtish Patra
If the upper two bits has an invalid valid (0x1), the event mapping is not reliable as it returns an uninitialized variable. Return appropriate value for the default case. Fixes: f0c9363db2dd ("perf/riscv-sbi: Add platform specific firmware event handling") Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20241212-pmu_event_fixes_v2-v2-2-813e8a4f5962@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-09drivers/perf: riscv: Fix Platform firmware event dataAtish Patra
Platform firmware event data field is allowed to be 62 bits for Linux as uppper most two bits are reserved to indicate SBI fw or platform specific firmware events. However, the event data field is masked as per the hardware raw event mask which is not correct. Fix the platform firmware event data field with proper mask. Fixes: f0c9363db2dd ("perf/riscv-sbi: Add platform specific firmware event handling") Signed-off-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20241212-pmu_event_fixes_v2-v2-1-813e8a4f5962@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-07drivers/perf: hisi: Set correct IRQ affinity for PMUs with no associationYicong Yang
For PMUs with no association, the hisi_pmu->on_cpu is initialized according to the NUMA locality but use a wrong CPU for the interrupt affinity. The CPU selected from cpumask_local_spread() can be different from the CPU by the cpuhp callback. Fix this by setting the IRQ affinity to hisi_pmu->on_cpu. Fixes: 6cd137088fdf ("drivers/perf: hisi: Refactor the detection of associated CPUs") Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20241223125134.57885-1-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-19perf: imx9_perf: Introduce AXI filter version to refactor the driver and ↵Xu Yang
better extension The imx93 is the first supported DDR PMU that supports read transaction, write transaction and read beats events which corresponding respecitively to counter 2, 3 and 4. However, transaction-based AXI match has low accuracy when get total bits compared to beats-based. And imx93 doesn't assign AXI_ID to each master. So axi filter is not used widely on imx93. This could be regards as AXI filter version 1. To improve the AXI filter capability, imx95 supports 1 read beats and 3 write beats event which corresponding respecitively to counter 2-5. imx95 also detailed AXI_ID allocation so that most of the master could be count individually. This could be regards as AXI filter version 2. This will introduce AXI filter version to refactor the driver and support better extension, such as coming imx943. This is also a potential fix on imx91 when configure axi filter. Fixes: 44798fe136dc ("perf: imx_perf: add support for i.MX91 platform") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20241212065708.1353513-1-xu.yang_2@nxp.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-19perf/arm-cmn: Permit more exhaustive groupsRobin Murphy
The group validation logic still somewhat assumes the original CMN-600 case of events counting globally, such that if one tries to group 9 events where the first 8 target a single DTC domain, the 9th will be rejected because *a* DTC domain is full, even though it might only target other non-overlapping domains and thus still be schedulable. Improve matters by only counting the DTCs that the new event actually needs (as arm_cmn_val_add_event() was already clever enough to do). Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-and-tested-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Link: https://lore.kernel.org/r/bdfd1e58dac449e407c5cacfd6bf8577dc0a5899.1733943898.git.robin.murphy@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-11perf/dwc_pcie: Qualify RAS DES VSEC Capability by Vendor, RevisionBjorn Helgaas
PCI Vendor-Specific (VSEC) Capabilities are defined by each vendor. Devices from different vendors may advertise a VSEC Capability with the DWC RAS DES functionality, but the vendors may assign different VSEC IDs. Search for the DWC RAS DES Capability using the VSEC ID and VSEC Rev chosen by the vendor. This does not fix a current problem because Alibaba, Ampere, and Qualcomm all assigned the same VSEC ID and VSEC Rev for the DWC RAS DES Capability. The potential issue is that we may add support for a device from another vendor, where the vendor has already assigned DWC_PCIE_VSEC_RAS_DES_ID (0x02) for an unrelated VSEC. In that event, dwc_pcie_des_cap() would find the unrelated VSEC and mistakenly assume it was a DWC RAS DES Capability. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-and-tested-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Reviewed-and-tested-by: Shuai Xue <xueshuai@linux.alibaba.com> Link: https://lore.kernel.org/r/20241209222938.3219364-1-helgaas@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2024-12-10drivers/perf: hisi: Delete redundant blank line of DDRC PMUJunhao He
Do not add blank line at the end of a code block defined by braces. Signed-off-by: Junhao He <hejunhao3@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241210141525.37788-11-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-10drivers/perf: hisi: Fix incorrect variable name "hha_pmu" in DDRC PMU driverJunhao He
In the callback function write_evtype(), the variable name of struct hisi_pmu should be "ddrc_pmu" instead of "hha_pmu". Signed-off-by: Junhao He <hejunhao3@huawei.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241210141525.37788-10-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-10drivers/perf: hisi: Export associated CPUs of each PMU through sysfsYicong Yang
Although the event of the uncore PMU can only be opened on a single CPU, some PMU does have the affinity on a range of CPUs. For example the L3C PMU is associated to the CPUs sharing the L3T it monitors. Users may infer this affinity by the PMU name which may have SCCL ID and CCL ID encoded (for L3C etc), but it's not that straightforward. So export this information by adding an "associated_cpus" sysfs attribute then user can get this directly. Reviewed-by: Jonathan Cameron <Joanthan.Cameron@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241210141525.37788-9-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-10drivers/perf: hisi: Provide a generic implementation of cpumask/identifierYicong Yang
Each type of HiSilicon Uncore PMU has the following sysfs attributes: - format: bitmask in perf_event_attr::config[012] of corresponding attribute - event: events name and corresponding event code - cpumask: range of CPUs the events can be opened on - identifier: the version of this PMU Different types of PMU have different implementations of the "format" and "event" but all share the same implementation of the "cpumask" and "identifier". Thus we can move cpumask and identifier to the hisi_uncore_pmu framework and drivers can use the generic implementation. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241210141525.37788-8-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-10drivers/perf: hisi: Add a common function to retrieve topology from firmwareYicong Yang
Currently each type of uncore PMU driver uses almost the same routine and the same firmware interface (or properties) to retrieve the topology information, then reset the unused IDs to -1. Extract the common parts to the framework in hisi_uncore_pmu_init_topology(). Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241210141525.37788-7-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-10drivers/perf: hisi: Extract topology information to a separate structureYicong Yang
HiSilicon Uncore PMUs are identified by the IDs of the topology element on which the PMUs are located. Add a new separate struct hisi_pmu_toplogy to encapsulate this information. Add additional documentation on the meaning of each ID. - make sccl_id and sicl_id into a union since they're exclusive. It can also be accessed by scl_id if the SICL/SCCL distinction is not relevant - make index_id and sub_id signed so -1 may be used to indicate the PMU doesn't have this topology element or it could not be retrieved. This patch should have no functional changes. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241210141525.37788-6-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-10drivers/perf: hisi: Refactor the detection of associated CPUsYicong Yang
There are two type of PMUs supported currently: 1) PMUs locate on SCCL (Super CPU Cluster [1]), associated with certain CCL (CPU cluster [1])(e.g. L3C PMU) or not (e.g. DDRC PMU) 2) PMUs locate on the SICL (Super IO Cluster [1]), which has no association with certain CPU topology (e.g. CPA PMU) Currently the associated CPUs of the PMU is detected in the cpuhp online callback as below: - for type 1) the CPUs match PMU's sccl_id and ccl_id - for type 2) PMU's sccl_id is -1 and all online CPUs will be associated Since uncore PMUs are not bound to certain CPU context and event could be counting started by any online CPU, the associated CPUs are just a preference. Below disadvantages are observed in current implementation: - the PMU cannot be used if its associated CPUs are offline - SICL PMUs are associated to all the online CPUs implicitly without the consideration of locality So refactor the way we detect the associated CPUs in below aspects: - add a clear definition of hisi_pmu::associated_cpus - initialize hisi_pmu::on_cpu based on locality if no associated CPU found, otherwise update it from associated CPUs - drop the detection with a sccl_id of -1 for SICL PMUs [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/perf/hisi-pmu.rst?h=v6.12-rc1 Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241210141525.37788-5-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-10drivers/perf: hisi: Migrate to one online CPU if no associated one onlineYicong Yang
If the selected CPU hisi_pmu::on_cpu goes offline, driver will select a new online CPU from hisi_pmu::associated_cpus, or if no online CPU found the PMU context won't be migrated. However for uncore PMUs the associated CPUs are just a peference and it also works to schedule the events on any online CPUs. So add a fallback to choose an online CPU if no associated CPUs found. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241210141525.37788-4-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-10drivers/perf: hisi: Don't update the associated_cpus on CPU offlineYicong Yang
Event will be scheduled on CPU of hisi_pmu::on_cpu which is selected from the intersection of hisi_pmu::associated_cpus and online CPUs. So the associated_cpus don't need to be maintained with online CPUs. This will save one update operation if one associated CPU is offlined. Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241210141525.37788-3-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-10drivers/perf: hisi: Define a symbol namespace for HiSilicon Uncore PMUsYicong Yang
The HiSilicon Uncore PMU framework implements some common functions and exported them to the drivers. Use a specific HISI_PMU namespace for the exported symbols to avoid pollute the generic ones. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20241210141525.37788-2-yangyicong@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09perf/marvell: Odyssey LLC-TAD performance monitor supportGowthami Thiagarajan
Each TAD provides eight 64-bit counters for monitoring cache behavior.The driver always configures the same counter for all the TADs. The user would end up effectively reserving one of eight counters in every TAD to look across all TADs. The occurrences of events are aggregated and presented to the user at the end of running the workload. The driver does not provide a way for the user to partition TADs so that different TADs are used for different applications. The performance events reflect various internal or interface activities. By combining the values from multiple performance counters, cache performance can be measured in terms such as: cache miss rate, cache allocations, interface retry rate, internal resource occupancy, etc. Each supported counter's event and formatting information is exposed to sysfs at /sys/devices/tad/. Use perf tool stat command to measure the pmu events. For instance: perf stat -e tad_hit_ltg,tad_hit_dtg <workload> Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com> Link: https://lore.kernel.org/r/20241108040619.753343-6-gthiagarajan@marvell.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09perf/marvell: Refactor to extract platform dataGowthami Thiagarajan
Refactor the Marvell TAD PMU driver to add versioning to the existing driver. Make no functional changes, the behavior and performance of the driver remain unchanged. Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com> Link: https://lore.kernel.org/r/20241108040619.753343-5-gthiagarajan@marvell.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09perf/marvell: Odyssey DDR Performance monitor supportGowthami Thiagarajan
Odyssey DRAM Subsystem supports eight counters for monitoring performance and software can program those counters to monitor any of the defined performance events. Supported performance events include those counted at the interface between the DDR controller and the PHY, interface between the DDR Controller and the CHI interconnect, or within the DDR Controller. Additionally DSS also supports two fixed performance event counters, one for ddr reads and the other for ddr writes. Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com> Link: https://lore.kernel.org/r/20241108040619.753343-4-gthiagarajan@marvell.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09perf/marvell: Refactor to extract PMU operationsGowthami Thiagarajan
Introduce a refactor to the Marvell DDR PMU driver to extract PMU operations ("pmu ops") from the existing driver. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@Huawei.com> Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com> Link: https://lore.kernel.org/r/20241108040619.753343-3-gthiagarajan@marvell.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09perf/marvell: Refactor to extract platform dataGowthami Thiagarajan
Introduce a refactor to the Marvell DDR pmu driver to extract platform data ("pdata") from the existing driver. Prepare for the upcoming support of the next version of the Performance Monitoring Unit (PMU) in this driver. Make no functional changes, this refactor solely improves code organization and prepares for future enhancements. While at it, fix a typo. Signed-off-by: Gowthami Thiagarajan <gthiagarajan@marvell.com> Link: https://lore.kernel.org/r/20241108040619.753343-2-gthiagarajan@marvell.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09perf/dwc_pcie: Fix the event numbersIlkka Koskinen
According to Databook, L1 aux is event number 0x08 and TX L0s and RX L0S is 0x09. Fix the event numbers for the two events. Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com> Link: https://lore.kernel.org/r/20241205061914.5568-2-ilkka@os.amperecomputing.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09perf: arm_cspmu: nvidia: monitor all ports by defaultBesar Wicaksono
Some NVIDIA PMUs like the NVLINK-C2C, CNVLINK, and PCIE PMU provide port filtering. If the port filter is set to zero, the counter of these PMUs will not capture any event. To avoid meaningless experiment, the driver sets the port filter value to a default non-zero value. Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Link: https://lore.kernel.org/r/20241031142118.1865965-5-bwicaksono@nvidia.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09perf: arm_cspmu: nvidia: enable NVLINK-C2C port filteringBesar Wicaksono
Enable NVLINK-C2C port filtering to distinguish traffic from different GPUs connected to NVLINK-C2C. Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Link: https://lore.kernel.org/r/20241031142118.1865965-4-bwicaksono@nvidia.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-09perf: arm_cspmu: nvidia: remove unsupported SCF eventsBesar Wicaksono
Remove unsupported events under SCF PMU. Signed-off-by: Besar Wicaksono <bwicaksono@nvidia.com> Link: https://lore.kernel.org/r/20241031142118.1865965-2-bwicaksono@nvidia.com Signed-off-by: Will Deacon <will@kernel.org>
2024-12-02module: Convert symbol namespace to string literalPeter Zijlstra
Clean up the existing export namespace code along the same lines of commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo) to __section("foo")") and for the same reason, it is not desired for the namespace argument to be a macro expansion itself. Scripted using git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file; do awk -i inplace ' /^#define EXPORT_SYMBOL_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /^#define MODULE_IMPORT_NS/ { gsub(/__stringify\(ns\)/, "ns"); print; next; } /MODULE_IMPORT_NS/ { $0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g"); } /EXPORT_SYMBOL_NS/ { if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) { if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ && $0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ && $0 !~ /^my/) { getline line; gsub(/[[:space:]]*\\$/, ""); gsub(/[[:space:]]/, "", line); $0 = $0 " " line; } $0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/, "\\1(\\2, \"\\3\")", "g"); } } { print }' $file; done Requested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc Acked-by: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-30Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Deselect ARCH_CORRECT_STACKTRACE_ON_KRETPROBE so that tests depending on it don't run (and fail) on arm64 - Fix lockdep assert in the Arm SMMUv3 PMU driver - Fix the port and device ID bits setting in the Arm CMN perf driver * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: perf/arm-cmn: Ensure port and device id bits are set properly perf/arm-smmuv3: Fix lockdep assert in ->event_init() arm64: disable ARCH_CORRECT_STACKTRACE_ON_KRETPROBE tests
generated by cgit v1.2.3 (git 2.0.4) at 2026-03-26 17:49:32 +0000