Conversation
commit d142df1 upstream. New CPU #defines encode vendor and family as well as model. Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lore.kernel.org/all/20240520224620.9480-32-tony.luck%40intel.com Conflicts: arch/x86/events/intel/core.c [jz: resolve context conflicts] Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 4e955c08d6dc76fb60cda9af955ddcebedaa7f69 upstream. Diamond Rapids (DMR) and Nova Lake (NVL) introduce an enhanced Off-Module Response (OMR) facility, replacing the Off-Core Response (OCR) Performance Monitoring of previous processors. Legacy microarchitectures used the OCR facility to evaluate off-core and multi-core off-module transactions. The newly named OMR facility improves OCR capabilities for scalable coverage of new memory systems in multi-core module systems. Similar to OCR, 4 additional off-module configuration MSRs (OFFMODULE_RSP_0 to OFFMODULE_RSP_3) are introduced to specify attributes of off-module transactions. When multiple identical OMR events are created, they need to occupy the same OFFMODULE_RSP_x MSR. To ensure these multiple identical OMR events can work simultaneously, the intel_alt_er() and intel_fixup_er() helpers are enhanced to rotate these OMR events across different OFFMODULE_RSP_* MSRs, similar to previous OCR events. For more details about OMR, please refer to section 16.1 "OFF-MODULE RESPONSE (OMR) FACILITY" in ISE documentation. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260114011750.350569-2-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit d2bdcde9626cbea0c44a6aaa33b440c8adf81e09 upstream. With the introduction of the OMR feature, the PEBS memory auxiliary info field for load and store latency events has been restructured for DMR. The memory auxiliary info field's bit[8] indicates whether a L2 cache miss occurred for a memory load or store instruction. If bit[8] is 0, it signifies no L2 cache miss, and bits[7:0] specify the exact cache data source (up to the L2 cache level). If bit[8] is 1, bits[7:0] represent the OMR encoding, indicating the specific L3 cache or memory region involved in the memory access. A significant enhancement is OMR encoding provides up to 8 fine-grained memory regions besides the cache region. A significant enhancement for OMR encoding is the ability to provide up to 8 fine-grained memory regions in addition to the cache region, offering more detailed insights into memory access regions. For detailed information on the memory auxiliary info encoding, please refer to section 16.2 "PEBS LOAD LATENCY AND STORE LATENCY FACILITY" in the ISE documentation. This patch ensures that the PEBS memory auxiliary info field is correctly interpreted and utilized in DMR. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260114011750.350569-3-dapeng1.mi@linux.intel.com Conflicts: arch/x86/events/intel/ds.c arch/x86/events/perf_event.h [jz: resolve context Conflicts] Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit d345b6bb886004ac1018da0348b5da7d9906071b upstream. This patch enables core PMU features for Diamond Rapids (Panther Cove microarchitecture), including Panther Cove specific counter and PEBS constraints, a new cache events ID table, and the model-specific OMR events extra registers table. For detailed information about counter constraints, please refer to section 16.3 "COUNTER RESTRICTIONS" in the ISE documentation. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260114011750.350569-4-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 8c74e4e3e0596950554962229582260f1501d899 upstream. Replace magic numbers in attr_rdpmc with macros to improve readability and make their meanings clearer for users. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260114011750.350569-7-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 59af95e028d4114991b9bd96a39ad855b399cc07 upstream. Starting with Panther Cove, the rdpmc user disable feature is supported. This feature allows the perf system to disable user space rdpmc reads at the counter level. Currently, when a global counter is active, any user with rdpmc rights can read it, even if perf access permissions forbid it (e.g., disallow reading ring 0 counters). The rdpmc user disable feature mitigates this security concern. Details: - A new RDPMC_USR_DISABLE bit (bit 37) in each EVNTSELx MSR indicates that the GP counter cannot be read by RDPMC in ring 3. - New RDPMC_USR_DISABLE bits in IA32_FIXED_CTR_CTRL MSR (bits 33, 37, 41, 45, etc.) for fixed counters 0, 1, 2, 3, etc. - When calling rdpmc instruction for counter x, the following pseudo code demonstrates how the counter value is obtained: If (!CPL0 && RDPMC_USR_DISABLE[x] == 1) ? 0 : counter_value; - RDPMC_USR_DISABLE is enumerated by CPUID.0x23.0.EBX[2]. This patch extends the current global user space rdpmc control logic via the sysfs interface (/sys/devices/cpu/rdpmc) as follows: - rdpmc = 0: Global user space rdpmc and counter-level user space rdpmc for all counters are both disabled. - rdpmc = 1: Global user space rdpmc is enabled during the mmap-enabled time window, and counter-level user space rdpmc is enabled only for non-system-wide events. This prevents counter data leaks as count data is cleared during context switches. - rdpmc = 2: Global user space rdpmc and counter-level user space rdpmc for all counters are enabled unconditionally. The new rdpmc settings only affect newly activated perf events; currently active perf events remain unaffected. This simplifies and cleans up the code. The default value of rdpmc remains unchanged at 1. For more details about rdpmc user disable, please refer to chapter 15 "RDPMC USER DISABLE" in ISE documentation. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260114011750.350569-8-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 1d07bbd7ea36ea0b8dfa8068dbe67eb3a32d9590 upstream.
When running the command:
'perf record -e "{instructions,instructions:p}" -j any,counter sleep 1',
a "shift-out-of-bounds" warning is reported on CWF.
UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15
shift exponent 64 is too large for 64-bit type 'long long unsigned int'
......
intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7
intel_pmu_lbr_save_brstack+0xc0/0x4c0
setup_arch_pebs_sample_data+0x114b/0x2400
The warning occurs because the second "instructions:p" event, which
involves branch counters sampling, is incorrectly programmed to fixed
counter 0 instead of the general-purpose (GP) counters 0-3 that support
branch counters sampling. Currently only GP counters 0-3 support branch
counters sampling on CWF, any event involving branch counters sampling
should be programed on GP counters 0-3. Since the counter index of fixed
counter 0 is 32, it leads to the "src" value in below code is right
shifted 64 bits and trigger the "shift-out-of-bounds" warning.
cnt = (src >> (order[j] * LBR_INFO_BR_CNTR_BITS)) & LBR_INFO_BR_CNTR_MASK;
The root cause is the loss of the branch counters constraint for the
new event in the branch counters sampling event group. Since it isn't
yet part of the sibling list. This results in the second
"instructions:p" event being programmed on fixed counter 0 incorrectly
instead of the appropriate GP counters 0-3.
To address this, we apply the missing branch counters constraint for
the last event in the group. Additionally, we introduce a new function,
`intel_set_branch_counter_constr()`, to apply the branch counters
constraint and avoid code duplication.
Fixes: 3374491 ("perf/x86/intel: Support branch counters logging")
Reported-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260228053320.140406-2-dapeng1.mi@linux.intel.com
Cc: stable@vger.kernel.org
Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit e7fcc54524f04e42641de99028edd9c69dc19f8c upstream. When omr_source is 0x2, the omr_snoop (bit[6]) and omr_promoted (bit[7]) fields are combined to represent the snoop information. However, the omr_promoted field was not left-shifted by 1 bit, resulting in incorrect snoop information. Besides, the snoop information parsing is not accurate for some OMR sources, like the snoop information should be SNOOP_NONE for these memory access (omr_source >= 7) instead of SNOOP_HIT. Fix these issues. Closes: https://lore.kernel.org/all/CAP-5=fW4zLWFw1v38zCzB9-cseNSTTCtup=p2SDxZq7dPayVww@mail.gmail.com/ Fixes: d2bdcde9626c ("perf/x86/intel: Add support for PEBS memory auxiliary info field in DMR") Reported-by: Ian Rogers <irogers@google.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Ian Rogers <irogers@google.com> Link: https://patch.msgid.link/20260311075201.2951073-1-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit dbde07f06226438cd2cf1179745fa1bec5d8914a upstream.
Auto counter reload may have a group of events with software events
present within it. The software event PMU isn't the x86_hybrid_pmu and
a container_of operation in intel_pmu_set_acr_caused_constr (via the
hybrid helper) could cause out of bound memory reads. Avoid this by
guarding the call to intel_pmu_set_acr_caused_constr with an
is_x86_event check.
Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload")
Signed-off-by: Ian Rogers <irogers@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Falcon <thomas.falcon@intel.com>
Link: https://patch.msgid.link/20260312194305.1834035-1-irogers@google.com
Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit b191aa32be2c960ca2391b40e862c389230cadef upstream. It's good enough to only check GP counters for PEBS constraints validation since constraints overlap can only happen on GP counters. Besides opportunistically refine the code style and use pr_warn() to replace pr_info() as the message itself is a warning message. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260228053320.140406-1-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 5ad732a56be46aabf158c16aa0c095291727aaef upstream.
Currently there are several issues on the user space ACR mask validation
and configuration.
- The validation for user space ACR mask (attr.config2) is incomplete,
e.g., the ACR mask could include the index which belongs to another
ACR events group, but it's not validated.
- An early return on an invalid ACR mask caused all subsequent ACR groups
to be skipped.
- The stale hardware ACR mask (hw.config1) is not cleared before setting
new hardware ACR mask.
The following changes address all of the above issues.
- Figure out the event index group of an ACR group. Any bits in the
user-space mask not present in the index group are now dropped.
- Instead of an early return on invalid bits, drop only the invalid
portions and continue iterating through all ACR events to ensure full
configuration.
- Explicitly clear the stale hardware ACR mask for each event prior to
writing the new configuration.
Besides, a non-leader event member of ACR group could be disabled in
theory. This could cause bit-shifting errors in the acr_mask of remaining
group members. But since ACR sampling requires all events to be active,
this should not be a big concern in real use case. Add a "FIXME" comment
to notice this risk.
Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260430002558.712334-2-dapeng1.mi@linux.intel.com
Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 8ba0b706a485b1e607594cf4210786d517ad1611 upstream.
Members of an ACR group are logically linked via a bitmask of their
hardware counter indices. If some members of the group are assigned new
hardware counters during rescheduling, even events that keep their
original counter index must be updated with a new mask.
Without this, an event will continue to use a stale acr_mask that
references the old indices of its group peers. Ensure all ACR events are
reprogrammed during the scheduling path to maintain consistency across
the group.
Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260430002558.712334-3-dapeng1.mi@linux.intel.com
Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 1271aeccc307066315b2d3b0d5af2510e27018b5 upstream.
On platforms with Auto Counter Reload (ACR) support, such as NVL, a
"NMI received for unknown reason 30" warning is observed when running
multiple events in a group with ACR enabled:
$ perf record -e '{instructions/period=20000,acr_mask=0x2/u,\
cycles/period=40000,acr_mask=0x3/u}' ./test
The warning occurs because the Performance Monitoring Interrupt (PMI)
is enabled for the self-reloaded event (the cycles event in this case).
According to the Intel SDM, the overflow bit
(IA32_PERF_GLOBAL_STATUS.PMCn_OVF) is never set for self-reloaded events.
Since the bit is not set, the perf NMI handler cannot identify the source
of the interrupt, leading to the "unknown reason" message.
Furthermore, enabling PMI for self-reloaded events is unnecessary and
can lead to extraneous records that pollute the user's requested data.
Disable the interrupt bit for all events configured with ACR self-reload.
Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload")
Reported-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260430002558.712334-4-dapeng1.mi@linux.intel.com
Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit aa4384bc8f4360167f3c3d5322121fe892289ea2 upstream.
Panther cove µarch starts to support auto counter reload (ACR), but the
static_call intel_pmu_enable_acr_event() is not updated for the Panther
Cove µarch used by DMR. It leads to the auto counter reload is not
really enabled on DMR.
Update static_call intel_pmu_enable_acr_event() in intel_pmu_init_pnc().
Fixes: d345b6bb8860 ("perf/x86/intel: Add core PMU support for DMR")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260430002558.712334-5-dapeng1.mi@linux.intel.com
Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 5c3cdc74af25fc7f64a3ed260b4f6eb8313a3b75 upstream. Both Auto Counter Reload (ACR) and Architectural PEBS use the PERF_CFG_C MSRs to configure event behavior. Currently, the driver maintains two independent variables acr_cfg_c and cfg_c_val to cache the values intended for these MSRs. Using separate variables to track a single hardware register state is error-prone and can lead to configuration conflicts. Consolidate the tracking into a single cfg_c_val variable to ensure a unified and consistent view of the PERF_CFG_C MSR state. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260430002558.712334-6-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit ffbe4ab upstream. The current ref-cycles event is only available on the fixed counter 2. Starting from the GLC and GRT core, the architectural UnHalted Reference Cycles event (0x013c) which is available on general-purpose counters can collect the exact same events as the fixed counter 2. Update the mapping of ref-cycles to 0x013c. So the ref-cycles can be available on both fixed counter 2 and general-purpose counters. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230911144139.2354015-1-kan.liang@linux.intel.com Conflicts: arch/x86/events/intel/core.c [jz: resolve context conflict] Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit acc41cdcb091453f48381d1c0d2e76b63c9d985f upstream. Update perf hard-coded event constraints and cache_extra_regs[] for Icelake server according to the latest ICX perfmon events (v1.30). Since the value of cache extra registers differs with previous generations, introduce new snc_hw_cache_extra_regs[] to represent the value of extra registers on ICX. ICX perfmon events: https://github.com/intel/perfmon/blob/main/ICX/events/icelakex_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-2-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 30d82ddee085b4b0f9a1b5bded53acaca68d9a52 upstream. Update perf hard-coded event constraints and cache_extra_regs[] for Sapphire rapids according to the latest SPR perfmon events (v1.39). Emerald Rapids (EMR) and Granite Rapids (GNR) share exactly same event constraints and extra MSR values with SPR. No extra changes are needed for EMR and GNR. Please note the change could temporarily impact other platforms which share the hard coded data structures, but it would be fixed in subsequent patches soon. SPR perfmon events: https://github.com/intel/perfmon/blob/main/SPR/events/sapphirerapids_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-3-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 070bd45e1dba684bfa4e7fdaa8ef8efa99b4572e upstream. Add missed event constraint for 0x0200 event and add comments to show the event names in pnc_hw_cache_extra_regs[]. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-4-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 7950de14ff5fd8da355d872b887ee8b7b5a1f327 upstream. From PMU's perspective, Panther Lake is similar to the previous generation Lunar Lake. Both are hybrid platforms, with e-core and p-core. The key differences are the ARCH PEBS feature and several new events. The ARCH PEBS is supported in the following patches. The new events will be supported later in perf tool. Share the code path with the Lunar Lake. Only update the name. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lkml.kernel.org/r/20250415114428.341182-2-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 4ef863352bcde482d65722ed721c3fd3967a67d6 upstream. Update perf hard-coded event constraints and cache_extra_regs[] for Alderlake according to the latest ADL perfmon events (V1.39). One important note is that ADL has differences on the L3/node related OCR events although it shares same uarch with SPR server, e.g., ADL has different extra MSR values and no node events. So some variants of structures and functions are introduced to reflect these differences, like adl_glc_hw_cache_event_ids[], adl_glc_hw_cache_extra_regs[] and intel_pmu_init_glc_hybrid(), etc. Please note these changes would temporarily impact other platforms like MTL/ARL-U which shares hard-coded event structures, but it would be fixed soon in subsequent patches. ADL perfmon events: https://github.com/intel/perfmon/blob/main/ADL/events/alderlake_goldencove_core.json https://github.com/intel/perfmon/blob/main/ADL/events/alderlake_gracemont_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-5-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit e99fb45436eaa4ac1b72a8e4af56381f59759b0c upstream. Update perf hard-coded event constraints and cache_extra_regs[] for Meteor Lake according to the latest MTL perfmon events (V1.21). MTL P-core (redwoodcove) inherits same perf events list from previous generation (Goldencove), but the E-core (Crestmont) brings some difference on the perf event list comparing with Gracemont. So apply the changes for Crestmont core. MTL perfmon events: https://github.com/intel/perfmon/blob/main/MTL/events/meteorlake_redwoodcove_core.json https://github.com/intel/perfmon/blob/main/MTL/events/meteorlake_crestmont_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-6-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 331c3e4fa39a87560c09bdd878652090ae040b69 upstream. Update perf hard-coded event constraints and cache_extra_regs[] for Lunarlake according to the latest LNL perfmon events (V1.22). LNL introduces new extra register values for the OCR L3 cache events, so introduce lnc_hw_cache_extra_regs[] and skt_hw_cache_extra_regs[] to reflect the changes. LNL perfmon events: https://github.com/intel/perfmon/blob/main/LNL/events/lunarlake_lioncove_core.json https://github.com/intel/perfmon/blob/main/LNL/events/lunarlake_skymont_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-7-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 0073ed169226f4ed65e339f770118f54ce4e1370 upstream. Update perf hard-coded event constraints and cache_extra_regs[] for Arrowlake according to the latest ARL perfmon events (V1.17). ARL shares almost same event constraints and extra MSR configuration with LNL except 2 differences. - ARL P-core has different extra MSR value for OCR.DEMAND_DATA_RD.L3_MISS and OCR.DEMAND_RFO.L3_MISS. So introduce arl_lnc_hw_cache_extra_regs[] to reflect the difference. - ARL-H has extra LPE cores which use crestmont architectures. Add crestmont specific event constraints and hw_cache_extra_regs[] for LPE cores. ARL perfmon events: https://github.com/intel/perfmon/blob/main/ARL/events/arrowlake_lioncove_core.json https://github.com/intel/perfmon/blob/main/ARL/events/arrowlake_skymont_core.json https://github.com/intel/perfmon/blob/main/ARL/events/arrowlake_crestmont_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-8-dapeng1.mi@linux.intel.com Conflicts: arch/x86/events/intel/core.c [jz: not including ARROWLAKE_H code changes to avoid over-introducing dependency] Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 65fd435095bb299b9c50d3285d4e6569b79b86e2 upstream. Update perf hard-coded event constraints for Pantherlake according to the latest PTL perfmon events (V1.05). PTL has almost same perf event list as LNL except some PEBS event constraints of E-core (exactly same on P-core). Define intel_dkt_pebs_event_constraints[] to reflect the PTL E-core specific PEBS event constraints. PTL perfmon events: https://github.com/intel/perfmon/blob/main/PTL/events/pantherlake_cougarcove_core.json https://github.com/intel/perfmon/blob/main/PTL/events/pantherlake_darkmont_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-9-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 7ae5f58517a6604ea86ae2b34cc7252d13d37180 upstream. Update perf hard-coded event constraints and cache_extra_regs[] for Sierra Forest according to the latest SRF perfmon events (V1.17). SRF has same uarch (crestmont) as MTL E-core and shares same perf events, so directly apply the crestmont perf events. SRF perfmon events: https://github.com/intel/perfmon/blob/main/SRF/events/sierraforest_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-11-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 66cc29745f2f5815482587bb9fbc1e8a3e6fcf00 upstream. Update perf hard-coded event constraints and cache_extra_regs[] for Clearwater Forest according to the latest CWF perfmon events (V1.02). An important difference is that CWF introduce new extra register values for the L3 cache OCR events, so define darkmont specific dkt_hw_cache_extra_regs[] array. CWF perfmon events: https://github.com/intel/perfmon/blob/main/CWF/events/clearwaterforest_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-12-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit e33ed362cf9e35db6082f7a776b7e8d557407e19 upstream. For ARM's implementation, perf_instruction_pointer() and perf_misc_flags() are equivalent to the generic versions in include/linux/perf_event.h so arch/arm doesn't need to provide its own versions. Drop them here. Signed-off-by: Colton Lewis <coltonlewis@google.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20241113190156.2145593-2-coltonlewis@google.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 04782e63917dbcb60932fe93df52c4a4e3859d07 upstream. For clarity, rename the arch-specific definitions of these functions to perf_arch_* to denote they are arch-specifc. Define the generic-named functions in one place where they can call the arch-specific ones as needed. Signed-off-by: Colton Lewis <coltonlewis@google.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Acked-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Madhavan Srinivasan <maddy@linux.ibm.com> Acked-by: Kan Liang <kan.liang@linux.intel.com> Link: https://lore.kernel.org/r/20241113190156.2145593-3-coltonlewis@google.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 3e807cf07d96eedb57d91a91f611f828e8918aab upstream. Make sure PowerPC uses the arch-specific function now that those have been reorganized. Signed-off-by: Colton Lewis <coltonlewis@google.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Acked-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://lore.kernel.org/r/20241113190156.2145593-4-coltonlewis@google.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit baff01f3d75ff3948a0465853dcaa71c394c5c46 upstream. Break the assignment logic for misc flags into their own respective functions to reduce the complexity of the nested logic. Signed-off-by: Colton Lewis <coltonlewis@google.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Acked-by: Kan Liang <kan.liang@linux.intel.com> Link: https://lore.kernel.org/r/20241113190156.2145593-5-coltonlewis@google.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 2c47e7a74f445426d156278e339b7abb259e50de upstream. Previously any PMU overflow interrupt that fired while a VCPU was loaded was recorded as a guest event whether it truly was or not. This resulted in nonsense perf recordings that did not honor perf_event_attr.exclude_guest and recorded guest IPs where it should have recorded host IPs. Rework the sampling logic to only record guest samples for events with exclude_guest = 0. This way any host-only events with exclude_guest set will never see unexpected guest samples. The behaviour of events with exclude_guest = 0 is unchanged. Note that events configured to sample both host and guest may still misattribute a PMI that arrived in the host as a guest event depending on KVM arch and vendor behavior. Signed-off-by: Colton Lewis <coltonlewis@google.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Kan Liang <kan.liang@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: https://lore.kernel.org/r/20241113190156.2145593-6-coltonlewis@google.com Conflicts: include/linux/perf_event.h [jz: resolve context conflicts] Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 8767b4d73018bd3143f4c55b672064fad292f11b upstream.
AnyThread mode deprecation is enumerated by CPUID.0AH:EDX[15] instead of
PERF_CAPABILITIES MSR. It's not a good practice to define a bit to
represent "anythread deprecation" in perf_capabilities. It leads to the
anythread_deprecated bit could be overwritten by the real value of
PERF_CAPABILITIES MSR, just like the below code in update_pmu_cap() does.
if (!intel_pmu_broken_perf_cap()) {
/* Perf Metric (Bit 15) and PEBS via PT (Bit 16) are hybrid enumeration */
rdmsrq(MSR_IA32_PERF_CAPABILITIES, hybrid(pmu, intel_cap).capabilities);
}
It leads to the anythread_deprecated bit is cleared to 0 and the "any"
attribute is incorrectly shown in the /sys/devices/cpu/format/ folder on
these support Perfmon v6 platforms, like Clearwater Forest.
$ grep . /sys/devices/cpu/format/*
/sys/devices/cpu/format/acr_mask:config2:0-63
/sys/devices/cpu/format/any:config:21
/sys/devices/cpu/format/cmask:config:24-31
So remove the anythread_deprecated bit from perf_capabilities structure
and directly depends on CPUID.0AH:EDX[15] to judge if anythread is
deprecated.
Fixes: cadbaa0 ("perf/x86/intel: Make anythread filter support conditional")
Reported-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Zide Chen <zide.chen@intel.com>
Reviewed-by: Thomas Falcon <thomas.falcon@intel.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260616044654.3468742-2-dapeng1.mi@linux.intel.com
Conflicts:
arch/x86/events/intel/core.c
[jz: resolve context conflict]
Signed-off-by: Jason Zeng <jason.zeng@intel.com>
…tate
commit 3c4ec9b2a5db56b60127bfaf933ecdeea7a1f10a upstream.
After introducing the RDPMC user disable feature, user-space RDPMC may
return 0 instead of the actual event count. This creates an inconsistency
with cap_user_rdpmc, where cap_user_rdpmc is set, but user-space RDPMC
only returns 0.
To accurately represent the user-space RDPMC capability, update
cap_user_rdpmc (depending on PERF_EVENT_FLAG_USER_READ_CNT) according to
the RDPMC user disable state. If RDPMC user disable is enabled,
cap_user_rdpmc is updated to false eventually, allowing user-space
programs to fall back to the read() syscall to obtain the real event
count.
Because PERF_EVENT_FLAG_USER_READ_CNT is evaluated in
x86_pmu_event_init(), move intel_pmu_update_rdpmc_user_disable()
earlier into intel_pmu_hw_config(). This ensures that the user-disable
state is updated before updating PERF_EVENT_FLAG_USER_READ_CNT. Note that
since event->ctx is not yet assigned at this stage, use the
PERF_ATTACH_TASK flag to detect whether the event is task-attached.
While at it, fix the indentation of x86_pmu_has_rdpmc_user_disable()
to adhere to the kernel coding style.
Fixes: 59af95e028d4 ("perf/x86/intel: Add support for rdpmc user disable feature")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260616044654.3468742-3-dapeng1.mi@linux.intel.com
Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 170cc6b02e3d5203ccaa49ffea1ee5a7ab08c885 upstream. intel_pmu_lbr_filter() currently assumes arch-LBR provides hardware branch-type decoding and skips software decoding on that path. However, arch-LBR may not always expose branch-type information. In that case, treating entries as hardware-decoded can misclassify sampled branches (for example, defaulting to JCC), which breaks branch-type filtering results. Fix this by using software branch-type decoding when hardware branch-type decoding is unavailable (that is, when x86_lbr_type is not enabled). This keeps branch classification and filtering behavior correct across arch-LBR configurations. Since x86_lbr_type is only set to true when arch-LBR is supported, it's unnecessary to check if the CPU has the arch-LBR feature. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260616044654.3468742-4-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit e2b0575900ff72aa82748af96e7bd564ade5157a upstream.
Before Arch LBR gained CPL filtering support, a user-only branch stack
could still contain kernel addresses. As a result, kernel branch records
may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is
requested.
For example, on Intel Tiger Lake, the following command can still report
SYSRET/ERET entries with kernel-space from addresses:
$ ./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \
./perf bench syscall basic --loop 1000 | \
./perf script -i - --fields brstack|tr ' ' '\n'| \
grep -E '0x[89a-f][0-9a-f]{15}'
Total time: 0.000 [sec]
0.219000 usecs/op
4,566,210 ops/sec
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.551 MB - ]
0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/-
0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/-
0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/-
0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/-
The problem is that intel_pmu_lbr_filter() does not fully validate the
privilege level of sampled entries. It filters some mismatches based on
the branch type and the to address, but it does not reject entries whose
from address violates the requested branch privilege filter.
Fix this by extending software filtering to validate both from and to
addresses against br_sel. Any LBR entry contains kernel address does not
match the requested user filter is dropped. This prevents kernel
addresses from appearing in user-only branch stacks.
Fixes: 47125db ("perf/x86/intel/lbr: Support Architectural LBR")
Reported-by: Ian Rogers <irogers@google.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260616044654.3468742-5-dapeng1.mi@linux.intel.com
Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 01c153956b4436ead05a529dae56abc0ef58beac upstream. The intel_pmu_init_hybrid() function allocates memory for the x86_pmu.hybrid_pmu[] array. If this allocation fails under memory pressure, hybrid PMU initialization will fail. Currently, the caller does not check the return value of intel_pmu_init_hybrid(). This can lead to a null-pointer dereference or invalid memory access when attempting to use the uninitialized array, potentially triggering a system panic. Fix this by validating the return value of intel_pmu_init_hybrid(). Additionally, reset x86_pmu.num_hybrid_pmus to 0 on failure, and defer intel_pmu_arch_lbr_init() until after hybrid PMU initialization succeeds. This reordering avoids the need to explicitly destroy the kmem cache if the memory allocation fails. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260616044654.3468742-6-dapeng1.mi@linux.intel.com Conflicts: arch/x86/events/intel/core.c [jz: - resolve context conflict - not include hunks for arrowlake/novalake platforms since VE hasn't support them] Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit a6b5fbc33172509fbe991358d718617a8e33ea7e upstream. On Sapphire Rapids (SPR) guests where pebs_baseline is not advertised, running command $ ./perf record -e cpu/event=0x00,umask=0x01,i\ name=INST_RETIRED.PREC_DIST/p -c 10000 sleep 1 can trigger: unchecked MSR access error: WRMSR to 0x3f1 ... in\ intel_pmu_pebs_enable_all() This occurs because SPR-specific PEBS constraints allow fixed-counter scheduling (for example, INST_RETIRED.PREC_DIST on fixed counter 0). In guests lacking pebs_baseline, KVM does not support PEBS sampling on fixed counters, so enabling such events reaches an invalid MSR programming path. Starting with Icelake, regardless of whether Extended PEBS or Architectural PEBS is in use, all counters (including fixed counters) support PEBS sampling, and the PMU_FL_PEBS_ALL flag is set by default. As long as PMU_FL_PEBS_ALL is set, constraint lookup automatically falls back to the corresponding non-PEBS constraints if no matching entry is found in the PEBS constraints table. Since non-PEBS event constraints already contain the same fixed-counter constraints, it is safe to remove these fixed-counter entries from the PEBS constraints table. The fallback mechanism will ensure that fixed PEBS events are scheduled onto the correct fixed counters. So, directly drop the fixed-counter entries from the PEBS constraint table. Without pebs_baseline, these fixed-counter PEBS events will now resolve to empty constraints and will not be scheduled or enabled, thereby avoiding the warning and bypassing the broken guest PEBS path. Reported-by: Yi Lai <yi1.lai@intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260616044654.3468742-7-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 166f10836a653dfa280d4335603b52f685b8b1ef upstream. An unprivileged hardware perf event using exclude_kernel=1 can leak kernel register data to user space via PERF_SAMPLE_REGS_INTR or PERF_SAMPLE_IP. Due to hardware skid, a PMI may trigger after the CPU has already entered kernel space (Ring 0), bypassing the perf_allow_kernel() privilege barrier. This security vulnerability is severely exacerbated by upcoming support for SIMD register sampling via XSAVES, which could expose sensitive kernel FPU states (such as active cryptographic keys). Fix this by ensuring that sampled register data is dropped if the event's exclude_kernel attribute is set but the PMI catches the CPU in kernel mode. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/all/20260529085613.CCAFB1F00893@smtp.kernel.org/ Link: https://patch.msgid.link/20260616044654.3468742-8-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit a4573a3838ae4fc73b70019cfa1dac9aaea7cc2f upstream. perf_event_open() currently gates perf_allow_kernel() only on !attr.exclude_kernel. However, users can still request kernel callchain collection with attr.exclude_callchain_kernel == 0 even when attr.exclude_kernel == 1. That still requires kernel profiling privilege, but the existing check does not enforce it. Update the permission check to call perf_allow_kernel() when either kernel sampling is requested or kernel callchains are requested. This keeps permission checks aligned with requested data and prevents unprivileged use of kernel callchain capture. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260616044654.3468742-9-dapeng1.mi@linux.intel.com Conflicts: kernel/events/core.c [jz: resolve context conflict because 9ec84f79c5a7 ("perf: Remove unnecessary parameter of security check") not backported] Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 91787047b1dc52b1fee68b07f79af70aae5fce47 upstream. Fix an NMI handler leak in init_hw_perf_events(). When PMU initialization fails after register_nmi_handler(), the error path exits without calling unregister_nmi_handler(), leaving a stale NMI_LOCAL "PMI" handler registered. Add the missing call before clearing x86_pmu state. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Thomas Falcon <thomas.falcon@intel.com> Reviewed-by: Zide Chen <zide.chen@intel.com> Link: https://patch.msgid.link/20260717080342.1879573-2-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 96746e731e1626545e343974ca4673739dceb31b upstream. If PMU initialization fails, for example in check_hw_exists(), hybrid state can be left partially initialized: x86_pmu.hybrid_pmu is not freed and perf_is_hybrid remains set. This can leak memory and leave stale hybrid state reachable after a failed init path. Add x86_pmu_free_hybrid() and use it on PMU init failure paths so all hybrid-related state is consistently reset. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Thomas Falcon <thomas.falcon@intel.com> Reviewed-by: Zide Chen <zide.chen@intel.com> Link: https://patch.msgid.link/20260717080342.1879573-3-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 278a3731c9d08bc6ea489c1987c6b7a7020f5d2b upstream. In failure paths, cpuc->pmu can still point to the global static pmu instead of an embedded x86_hybrid_pmu::pmu. Calling hybrid_pmu() on that pointer causes an invalid container conversion and may lead to out-of-bounds access. This can happen in at least two cases: - init_hybrid_pmu() fails check_hw_exists() and leaves cpuc->pmu as-is. - CPU hotplug fails between CPUHP_PERF_X86_PREPARE and CPUHP_AP_PERF_X86_STARTING, and rollback invokes intel_pmu_cpu_dead(). Fix both paths by: - Clear cpuc->pmu to NULL when check_hw_exists() fails. - Validat that cpuc->pmu is not the global static pmu before calling hybrid_pmu() in intel_pmu_cpu_dead(). A new helper x86_get_static_pmu() is added to get the global static pmu. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Thomas Falcon <thomas.falcon@intel.com> Reviewed-by: Zide Chen <zide.chen@intel.com> Link: https://patch.msgid.link/20260717080342.1879573-4-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 85182f902afda28ca7ae3408b72f31640a5cfc73 upstream. intel_pmu_cpu_prepare() allocates per-CPU perf state first and then sets up the arch PEBS buffer. If alloc_arch_pebs_buf_on_cpu() fails, the previously allocated cpuc resources are left behind. Make the failure path call intel_cpuc_finish(cpuc) to release the per-CPU state allocated by intel_cpuc_prepare(). Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Thomas Falcon <thomas.falcon@intel.com> Reviewed-by: Zide Chen <zide.chen@intel.com> Link: https://patch.msgid.link/20260717080342.1879573-5-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 3ba87c5bf11bea80e56abe17730085bc962ecfbe upstream. On hybrid systems, init_hw_perf_events() can call check_hw_exists() with the global PMU pointer after perf_is_hybrid is set. In that case, fixed_counter_disabled() uses hybrid() on a non-hybrid PMU object, so the intel_ctrl access is taken from the wrong layout and can read out of bounds. fixed_counter_disabled() was added in commit 3245161 ("perf/x86/intel: Support CPUID 10.ECX to disable fixed counters"), when fixed counters were tracked via num_fixed_counters. Today fixed counters are represented by fixed_cntr_mask, so this helper is obsolete. Remove fixed_counter_disabled() and its callers, and rely directly on the fixed-counter bitmask. With the helper gone, check_hw_exists() no longer needs a PMU argument, so drop that parameter as well. This removes the invalid hybrid access and closes the out-of-bounds read risk. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Thomas Falcon <thomas.falcon@intel.com> Reviewed-by: Zide Chen <zide.chen@intel.com> Link: https://patch.msgid.link/20260717080342.1879573-6-dapeng1.mi@linux.intel.com Conflicts: arch/x86/events/core.c arch/x86/events/intel/core.c [jz: resolve context conflicts] Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit dd384d661f06e3725aad3a932a53e0ff81fb8805 upstream. intel_cap (IA32_PERF_CAPABILITIES) updates are currently tied to X86_FEATURE_ARCH_PERFMON_EXT, but these are independent feature paths. As a result, hybrid PMU capability state can be updated under the wrong condition. Also, intel_pmu_broken_perf_cap() is too narrow. Per RPL018, the missing PERF_METRICS_AVAILABLE bit affects both Raptor Lake and Meteor Lake parts, not only the currently covered subset. Move intel_cap updates out of the ARCH_PERFMON_EXT-gated path, extend intel_pmu_broken_perf_cap() coverage to both RPL and MTL families, and introduce intel_update_pmu_caps() to centralize PMU capability updates. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Thomas Falcon <thomas.falcon@intel.com> Reviewed-by: Zide Chen <zide.chen@intel.com> Link: https://patch.msgid.link/20260717080342.1879573-7-dapeng1.mi@linux.intel.com Conflicts: arch/x86/events/intel/core.c [jz: - resolve context conflicts - use rdmsrl instead of rdmsrq] Signed-off-by: Jason Zeng <jason.zeng@intel.com>
commit 917d558b151cad5b05991e5eaee22efab33525ca upstream. match_prev_assignment() currently forces a mismatch for ACR events, so ACR counter indices are reprogrammed on every scheduling pass. That causes avoidable overhead because disable and enable paths must touch multiple MSRs. The previous ACR assignment is already cached in acr_cfg_b[]. Use that state to compare the newly computed ACR counter indices in hwc->config1 against the cached value in acr_cfg_b[hwc->idx]. If they match, skip unnecessary disable and enable work. Also tighten is_acr_self_reload_event() so it first verifies the event is an ACR event before testing for the self-reload case. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Thomas Falcon <thomas.falcon@intel.com> Reviewed-by: Zide Chen <zide.chen@intel.com> Link: https://patch.msgid.link/20260717080342.1879573-8-dapeng1.mi@linux.intel.com Signed-off-by: Jason Zeng <jason.zeng@intel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Upstream merged some PMU core bugfixes for x86/intel platforms in v7.3-rc1. This is to backport these commits from upstream.
This pull request also includes the commits from PR#127 (DMR: PMU core event support)
Test