* [Patch v2 1/4] perf/x86/intel: Clear stale ACR mask before updating new mask
2026-04-20 2:45 [Patch v2 0/4] perf/x86/intel: Fix several bugs of auto counter Dapeng Mi
@ 2026-04-20 2:45 ` Dapeng Mi
2026-04-20 3:24 ` sashiko-bot
2026-04-21 22:29 ` Andi Kleen
2026-04-20 2:45 ` [Patch v2 2/4] perf/x86/intel: Disable PMI for self-reloaded ACR events Dapeng Mi
` (2 subsequent siblings)
3 siblings, 2 replies; 15+ messages in thread
From: Dapeng Mi @ 2026-04-20 2:45 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Andi Kleen, Eranian Stephane
Cc: linux-kernel, linux-perf-users, Dapeng Mi, Zide Chen,
Falcon Thomas, Xudong Hao, Dapeng Mi, stable
The current implementation forgets to clear the ACR mask before applying
a new one. During event rescheduling, this allow bits from a previous
stale ACR mask to persist, leading to an incorrect hardware state.
Ensure that the ACR mask is zeroed out before setting the new mask to
prevent state pollution.
Cc: stable@vger.kernel.org
Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
V2: Clear stale acr_mask for all events.
arch/x86/events/intel/core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 4768236c054b..774ae9a4eeaf 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3334,6 +3334,12 @@ static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
struct perf_event *event, *leader;
int i, j, idx;
+ /* Clear stale ACR mask first. */
+ for (i = 0; i < cpuc->n_events; i++) {
+ event = cpuc->event_list[i];
+ event->hw.config1 = 0;
+ }
+
for (i = 0; i < cpuc->n_events; i++) {
leader = cpuc->event_list[i];
if (!is_acr_event_group(leader))
--
2.34.1
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [Patch v2 1/4] perf/x86/intel: Clear stale ACR mask before updating new mask
2026-04-20 2:45 ` [Patch v2 1/4] perf/x86/intel: Clear stale ACR mask before updating new mask Dapeng Mi
@ 2026-04-20 3:24 ` sashiko-bot
2026-04-20 6:29 ` Mi, Dapeng
2026-04-21 22:29 ` Andi Kleen
1 sibling, 1 reply; 15+ messages in thread
From: sashiko-bot @ 2026-04-20 3:24 UTC (permalink / raw)
To: Dapeng Mi; +Cc: linux-perf-users
Sashiko AI review found 1 potential issue(s):
- [High] Unvalidated user input in ACR setup leads to cross-user hardware state corruption and PMU DoS
--
commit 67dc3d7b096879ed6418f54978bf45536496156f
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
perf/x86/intel: Clear stale ACR mask before updating new mask
This commit zeroes out the ACR mask (event->hw.config1) for all scheduled
events before applying a new mask. This ensures that bits from a previous
stale ACR mask do not persist and pollute the hardware state during event
rescheduling.
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 4768236c054bb..774ae9a4eeaf8 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -3334,6 +3334,12 @@ static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
> struct perf_event *event, *leader;
> int i, j, idx;
>
> + /* Clear stale ACR mask first. */
> + for (i = 0; i < cpuc->n_events; i++) {
> + event = cpuc->event_list[i];
> + event->hw.config1 = 0;
> + }
> +
Does this new clearing loop inadvertently amplify an existing regression where
a single user can disable Auto Counter Reload for all processes on the same CPU?
Looking further down in the same function, the code iterates over
user-controlled bits from event->attr.config2:
arch/x86/events/intel/core.c:intel_pmu_acr_late_setup() {
...
for_each_set_bit(idx, (unsigned long *)&event->attr.config2, X86_PMC_IDX_MAX) {
if (i + idx >= cpuc->n_events ||
!is_acr_event_group(cpuc->event_list[i + idx]))
return;
__set_bit(cpuc->assign[i + idx], (unsigned long *)&event->hw.config1);
}
...
}
Because idx is derived from the user-controlled event->attr.config2 mask
without being validated against the actual size of the event group, a
user could provide an artificially large idx.
The validation in intel_pmu_hw_config() only checks the weight of the mask
using hweight64(), rather than checking the actual bit indices, leaving this
exposed. Subsequent patches in the series do not fix this.
If the computed index hits a non-ACR event or exceeds cpuc->n_events, the
loop triggers an early return. Since the newly added code zeroes out
event->hw.config1 for all scheduled events before this loop, wouldn't this
early return leave all subsequent valid ACR events with a cleared mask?
Additionally, if the out-of-bounds idx points to another user's valid ACR
group, is_acr_event_group() returns true, and the code proceeds to update
the event->hw.config1 with the victim's hardware counter index.
Could this also result in cross-user state corruption of event->hw.config1
when the event overflows and cross-reloads the victim's counter?
> for (i = 0; i < cpuc->n_events; i++) {
> leader = cpuc->event_list[i];
> if (!is_acr_event_group(leader))
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260420024528.2130065-1-dapeng1.mi@linux.intel.com?part=1
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [Patch v2 1/4] perf/x86/intel: Clear stale ACR mask before updating new mask
2026-04-20 3:24 ` sashiko-bot
@ 2026-04-20 6:29 ` Mi, Dapeng
2026-04-21 5:03 ` Mi, Dapeng
0 siblings, 1 reply; 15+ messages in thread
From: Mi, Dapeng @ 2026-04-20 6:29 UTC (permalink / raw)
To: sashiko; +Cc: linux-perf-users
On 4/20/2026 11:24 AM, sashiko-bot@kernel.org wrote:
> Sashiko AI review found 1 potential issue(s):
> - [High] Unvalidated user input in ACR setup leads to cross-user hardware state corruption and PMU DoS
> --
>
> commit 67dc3d7b096879ed6418f54978bf45536496156f
> Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
>
> perf/x86/intel: Clear stale ACR mask before updating new mask
>
> This commit zeroes out the ACR mask (event->hw.config1) for all scheduled
> events before applying a new mask. This ensures that bits from a previous
> stale ACR mask do not persist and pollute the hardware state during event
> rescheduling.
>
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index 4768236c054bb..774ae9a4eeaf8 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -3334,6 +3334,12 @@ static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
>> struct perf_event *event, *leader;
>> int i, j, idx;
>>
>> + /* Clear stale ACR mask first. */
>> + for (i = 0; i < cpuc->n_events; i++) {
>> + event = cpuc->event_list[i];
>> + event->hw.config1 = 0;
>> + }
>> +
> Does this new clearing loop inadvertently amplify an existing regression where
> a single user can disable Auto Counter Reload for all processes on the same CPU?
>
> Looking further down in the same function, the code iterates over
> user-controlled bits from event->attr.config2:
>
> arch/x86/events/intel/core.c:intel_pmu_acr_late_setup() {
> ...
> for_each_set_bit(idx, (unsigned long *)&event->attr.config2, X86_PMC_IDX_MAX) {
> if (i + idx >= cpuc->n_events ||
> !is_acr_event_group(cpuc->event_list[i + idx]))
> return;
> __set_bit(cpuc->assign[i + idx], (unsigned long *)&event->hw.config1);
> }
> ...
> }
>
> Because idx is derived from the user-controlled event->attr.config2 mask
> without being validated against the actual size of the event group, a
> user could provide an artificially large idx.
>
> The validation in intel_pmu_hw_config() only checks the weight of the mask
> using hweight64(), rather than checking the actual bit indices, leaving this
> exposed. Subsequent patches in the series do not fix this.
>
> If the computed index hits a non-ACR event or exceeds cpuc->n_events, the
> loop triggers an early return. Since the newly added code zeroes out
> event->hw.config1 for all scheduled events before this loop, wouldn't this
> early return leave all subsequent valid ACR events with a cleared mask?
>
> Additionally, if the out-of-bounds idx points to another user's valid ACR
> group, is_acr_event_group() returns true, and the code proceeds to update
> the event->hw.config1 with the victim's hardware counter index.
>
> Could this also result in cross-user state corruption of event->hw.config1
> when the event overflows and cross-reloads the victim's counter?
That looks a real potential issue. Current validation for the acr_mask
needs to be enhanced. The acr_mask from user space should not exceeds the
index bitmap of current ACR events group.
Thanks.
>
>> for (i = 0; i < cpuc->n_events; i++) {
>> leader = cpuc->event_list[i];
>> if (!is_acr_event_group(leader))
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [Patch v2 1/4] perf/x86/intel: Clear stale ACR mask before updating new mask
2026-04-20 6:29 ` Mi, Dapeng
@ 2026-04-21 5:03 ` Mi, Dapeng
0 siblings, 0 replies; 15+ messages in thread
From: Mi, Dapeng @ 2026-04-21 5:03 UTC (permalink / raw)
To: sashiko; +Cc: linux-perf-users
On 4/20/2026 2:29 PM, Mi, Dapeng wrote:
> On 4/20/2026 11:24 AM, sashiko-bot@kernel.org wrote:
>> Sashiko AI review found 1 potential issue(s):
>> - [High] Unvalidated user input in ACR setup leads to cross-user hardware state corruption and PMU DoS
>> --
>>
>> commit 67dc3d7b096879ed6418f54978bf45536496156f
>> Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
>>
>> perf/x86/intel: Clear stale ACR mask before updating new mask
>>
>> This commit zeroes out the ACR mask (event->hw.config1) for all scheduled
>> events before applying a new mask. This ensures that bits from a previous
>> stale ACR mask do not persist and pollute the hardware state during event
>> rescheduling.
>>
>>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>>> index 4768236c054bb..774ae9a4eeaf8 100644
>>> --- a/arch/x86/events/intel/core.c
>>> +++ b/arch/x86/events/intel/core.c
>>> @@ -3334,6 +3334,12 @@ static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
>>> struct perf_event *event, *leader;
>>> int i, j, idx;
>>>
>>> + /* Clear stale ACR mask first. */
>>> + for (i = 0; i < cpuc->n_events; i++) {
>>> + event = cpuc->event_list[i];
>>> + event->hw.config1 = 0;
>>> + }
>>> +
>> Does this new clearing loop inadvertently amplify an existing regression where
>> a single user can disable Auto Counter Reload for all processes on the same CPU?
>>
>> Looking further down in the same function, the code iterates over
>> user-controlled bits from event->attr.config2:
>>
>> arch/x86/events/intel/core.c:intel_pmu_acr_late_setup() {
>> ...
>> for_each_set_bit(idx, (unsigned long *)&event->attr.config2, X86_PMC_IDX_MAX) {
>> if (i + idx >= cpuc->n_events ||
>> !is_acr_event_group(cpuc->event_list[i + idx]))
>> return;
>> __set_bit(cpuc->assign[i + idx], (unsigned long *)&event->hw.config1);
>> }
>> ...
>> }
>>
>> Because idx is derived from the user-controlled event->attr.config2 mask
>> without being validated against the actual size of the event group, a
>> user could provide an artificially large idx.
>>
>> The validation in intel_pmu_hw_config() only checks the weight of the mask
>> using hweight64(), rather than checking the actual bit indices, leaving this
>> exposed. Subsequent patches in the series do not fix this.
>>
>> If the computed index hits a non-ACR event or exceeds cpuc->n_events, the
>> loop triggers an early return. Since the newly added code zeroes out
>> event->hw.config1 for all scheduled events before this loop, wouldn't this
>> early return leave all subsequent valid ACR events with a cleared mask?
>>
>> Additionally, if the out-of-bounds idx points to another user's valid ACR
>> group, is_acr_event_group() returns true, and the code proceeds to update
>> the event->hw.config1 with the victim's hardware counter index.
>>
>> Could this also result in cross-user state corruption of event->hw.config1
>> when the event overflows and cross-reloads the victim's counter?
> That looks a real potential issue. Current validation for the acr_mask
> needs to be enhanced. The acr_mask from user space should not exceeds the
> index bitmap of current ACR events group.
> Thanks.
The following changes would be done to address all current found issues.
- Calculate the indices bitmap for each ACR events group. Any bits in
the user-space mask not present in the group's bitmap 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.
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 4768236c054b..1a2c268018a2 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3332,23 +3332,41 @@ static void intel_pmu_enable_event(struct
perf_event *event)
static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
{
struct perf_event *event, *leader;
- int i, j, idx;
+ int i, j, k, bit, idx;
+ u64 group_mask;
for (i = 0; i < cpuc->n_events; i++) {
leader = cpuc->event_list[i];
if (!is_acr_event_group(leader))
continue;
- /* The ACR events must be contiguous. */
+ /* Find the last event of the ACR group. */
for (j = i; j < cpuc->n_events; j++) {
event = cpuc->event_list[j];
if (event->group_leader != leader->group_leader)
break;
- for_each_set_bit(idx, (unsigned long
*)&event->attr.config2, X86_PMC_IDX_MAX) {
- if (i + idx >= cpuc->n_events ||
- !is_acr_event_group(cpuc->event_list[i
+ idx]))
- return;
- __set_bit(cpuc->assign[i + idx], (unsigned
long *)&event->hw.config1);
+ }
+
+ /* Figure out the group indices bitmap. */
+ group_mask = 0;
+ for (k = i; k < j; k++)
+ group_mask |= BIT_ULL(cpuc->assign[k]);
+
+ /*
+ * Translate the user-space ACR mask (attr.config2) into
the physical
+ * counter bitmask (hw.config1) for each ACR event in the
group.
+ * NOTE: ACR event contiguity is guaranteed by
intel_pmu_hw_config().
+ */
+ for (k = i; k < j; k++) {
+ event = cpuc->event_list[k];
+ event->hw.config1 = 0;
+ for_each_set_bit(bit, (unsigned long
*)&event->attr.config2, X86_PMC_IDX_MAX) {
+ idx = i + bit;
+ if (idx >= cpuc->n_events ||
+ !(BIT_ULL(cpuc->assign[idx]) &
group_mask) ||
+ !is_acr_event_group(cpuc->event_list[idx]))
+ continue;
+ __set_bit(cpuc->assign[idx], (unsigned long
*)&event->hw.config1);
}
}
i = j - 1;
>
>
>>> for (i = 0; i < cpuc->n_events; i++) {
>>> leader = cpuc->event_list[i];
>>> if (!is_acr_event_group(leader))
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [Patch v2 1/4] perf/x86/intel: Clear stale ACR mask before updating new mask
2026-04-20 2:45 ` [Patch v2 1/4] perf/x86/intel: Clear stale ACR mask before updating new mask Dapeng Mi
2026-04-20 3:24 ` sashiko-bot
@ 2026-04-21 22:29 ` Andi Kleen
2026-04-22 0:57 ` Mi, Dapeng
1 sibling, 1 reply; 15+ messages in thread
From: Andi Kleen @ 2026-04-21 22:29 UTC (permalink / raw)
To: Dapeng Mi
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Eranian Stephane, linux-kernel, linux-perf-users, Dapeng Mi,
Zide Chen, Falcon Thomas, Xudong Hao, stable
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 4768236c054b..774ae9a4eeaf 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -3334,6 +3334,12 @@ static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
> struct perf_event *event, *leader;
> int i, j, idx;
>
> + /* Clear stale ACR mask first. */
> + for (i = 0; i < cpuc->n_events; i++) {
> + event = cpuc->event_list[i];
> + event->hw.config1 = 0;
> + }
Are you sure nothing else could be using config1?
In principle ACR events can be used with some config1 setting.
-Andi
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [Patch v2 1/4] perf/x86/intel: Clear stale ACR mask before updating new mask
2026-04-21 22:29 ` Andi Kleen
@ 2026-04-22 0:57 ` Mi, Dapeng
0 siblings, 0 replies; 15+ messages in thread
From: Mi, Dapeng @ 2026-04-22 0:57 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Eranian Stephane, linux-kernel, linux-perf-users, Dapeng Mi,
Zide Chen, Falcon Thomas, Xudong Hao, stable
On 4/22/2026 6:29 AM, Andi Kleen wrote:
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index 4768236c054b..774ae9a4eeaf 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -3334,6 +3334,12 @@ static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
>> struct perf_event *event, *leader;
>> int i, j, idx;
>>
>> + /* Clear stale ACR mask first. */
>> + for (i = 0; i < cpuc->n_events; i++) {
>> + event = cpuc->event_list[i];
>> + event->hw.config1 = 0;
>> + }
> Are you sure nothing else could be using config1?
>
> In principle ACR events can be used with some config1 setting.
Yes, the field "hw.config1" is introduced for support auto counter reload,
it's only used to store the ACR counter indices. Thanks.
https://lore.kernel.org/all/20250327195217.2683619-6-kan.liang@linux.intel.com/
>
>
> -Andi
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Patch v2 2/4] perf/x86/intel: Disable PMI for self-reloaded ACR events
2026-04-20 2:45 [Patch v2 0/4] perf/x86/intel: Fix several bugs of auto counter Dapeng Mi
2026-04-20 2:45 ` [Patch v2 1/4] perf/x86/intel: Clear stale ACR mask before updating new mask Dapeng Mi
@ 2026-04-20 2:45 ` Dapeng Mi
2026-04-21 22:37 ` Andi Kleen
2026-04-20 2:45 ` [Patch v2 3/4] perf/x86/intel: Enable auto counter reload for DMR Dapeng Mi
2026-04-20 2:45 ` [Patch v2 4/4] perf/x86/intel: Consolidate MSR_IA32_PERF_CFG_C tracking Dapeng Mi
3 siblings, 1 reply; 15+ messages in thread
From: Dapeng Mi @ 2026-04-20 2:45 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Andi Kleen, Eranian Stephane
Cc: linux-kernel, linux-perf-users, Dapeng Mi, Zide Chen,
Falcon Thomas, Xudong Hao, Dapeng Mi, stable
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.
Reported-by: Andi Kleen <ak@linux.intel.com>
Cc: stable@vger.kernel.org
Fixes: ec980e4facef ("perf/x86/intel: Support auto counter reload")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
arch/x86/events/intel/core.c | 17 +++++++++++++----
arch/x86/events/perf_event.h | 10 ++++++++++
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 774ae9a4eeaf..510b087c9e89 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3118,11 +3118,11 @@ static void intel_pmu_enable_fixed(struct perf_event *event)
intel_set_masks(event, idx);
/*
- * Enable IRQ generation (0x8), if not PEBS,
- * and enable ring-3 counting (0x2) and ring-0 counting (0x1)
- * if requested:
+ * Enable IRQ generation (0x8), if not PEBS and self-reloaded
+ * ACR event, and enable ring-3 counting (0x2) and ring-0
+ * counting (0x1) if requested:
*/
- if (!event->attr.precise_ip)
+ if (!event->attr.precise_ip && !is_acr_self_reload_event(event))
bits |= INTEL_FIXED_0_ENABLE_PMI;
if (hwc->config & ARCH_PERFMON_EVENTSEL_USR)
bits |= INTEL_FIXED_0_USER;
@@ -3306,6 +3306,15 @@ static void intel_pmu_enable_event(struct perf_event *event)
intel_set_masks(event, idx);
static_call_cond(intel_pmu_enable_acr_event)(event);
static_call_cond(intel_pmu_enable_event_ext)(event);
+ /*
+ * For self-reloaded ACR event, don't enable PMI since
+ * HW won't set overflow bit in GLOBAL_STATUS. Otherwise,
+ * the PMI would be recognized as a suspicious NMI.
+ */
+ if (is_acr_self_reload_event(event))
+ hwc->config &= ~ARCH_PERFMON_EVENTSEL_INT;
+ else if (!event->attr.precise_ip)
+ hwc->config |= ARCH_PERFMON_EVENTSEL_INT;
__x86_pmu_enable_event(hwc, enable_mask);
break;
case INTEL_PMC_IDX_FIXED ... INTEL_PMC_IDX_FIXED_BTS - 1:
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index fad87d3c8b2c..524668dcf4cc 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -137,6 +137,16 @@ static inline bool is_acr_event_group(struct perf_event *event)
return check_leader_group(event->group_leader, PERF_X86_EVENT_ACR);
}
+static inline bool is_acr_self_reload_event(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = &event->hw;
+
+ if (hwc->idx < 0)
+ return false;
+
+ return test_bit(hwc->idx, (unsigned long *)&hwc->config1);
+}
+
struct amd_nb {
int nb_id; /* NorthBridge id */
int refcnt; /* reference count */
--
2.34.1
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [Patch v2 2/4] perf/x86/intel: Disable PMI for self-reloaded ACR events
2026-04-20 2:45 ` [Patch v2 2/4] perf/x86/intel: Disable PMI for self-reloaded ACR events Dapeng Mi
@ 2026-04-21 22:37 ` Andi Kleen
2026-04-22 1:24 ` Mi, Dapeng
0 siblings, 1 reply; 15+ messages in thread
From: Andi Kleen @ 2026-04-21 22:37 UTC (permalink / raw)
To: Dapeng Mi
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Eranian Stephane, linux-kernel, linux-perf-users, Dapeng Mi,
Zide Chen, Falcon Thomas, Xudong Hao, stable
On Mon, Apr 20, 2026 at 10:45:26AM +0800, Dapeng Mi wrote:
> @@ -3306,6 +3306,15 @@ static void intel_pmu_enable_event(struct perf_event *event)
> intel_set_masks(event, idx);
> static_call_cond(intel_pmu_enable_acr_event)(event);
> static_call_cond(intel_pmu_enable_event_ext)(event);
> + /*
> + * For self-reloaded ACR event, don't enable PMI since
> + * HW won't set overflow bit in GLOBAL_STATUS. Otherwise,
> + * the PMI would be recognized as a suspicious NMI.
> + */
> + if (is_acr_self_reload_event(event))
> + hwc->config &= ~ARCH_PERFMON_EVENTSEL_INT;
> + else if (!event->attr.precise_ip)
> + hwc->config |= ARCH_PERFMON_EVENTSEL_INT;
It seems weird to either clear or set the bit. You don't know the previous
state of the bit here? I would assume it starts with zero?
> +static inline bool is_acr_self_reload_event(struct perf_event *event)
> +{
> + struct hw_perf_event *hwc = &event->hw;
> +
> + if (hwc->idx < 0)
> + return false;
> +
> + return test_bit(hwc->idx, (unsigned long *)&hwc->config1);
Are you sure this doesn't conflict with some other non ACR usage of config1?
-Andi
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [Patch v2 2/4] perf/x86/intel: Disable PMI for self-reloaded ACR events
2026-04-21 22:37 ` Andi Kleen
@ 2026-04-22 1:24 ` Mi, Dapeng
2026-04-22 17:07 ` Andi Kleen
0 siblings, 1 reply; 15+ messages in thread
From: Mi, Dapeng @ 2026-04-22 1:24 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Eranian Stephane, linux-kernel, linux-perf-users, Dapeng Mi,
Zide Chen, Falcon Thomas, Xudong Hao, stable
On 4/22/2026 6:37 AM, Andi Kleen wrote:
> On Mon, Apr 20, 2026 at 10:45:26AM +0800, Dapeng Mi wrote:
>> @@ -3306,6 +3306,15 @@ static void intel_pmu_enable_event(struct perf_event *event)
>> intel_set_masks(event, idx);
>> static_call_cond(intel_pmu_enable_acr_event)(event);
>> static_call_cond(intel_pmu_enable_event_ext)(event);
>> + /*
>> + * For self-reloaded ACR event, don't enable PMI since
>> + * HW won't set overflow bit in GLOBAL_STATUS. Otherwise,
>> + * the PMI would be recognized as a suspicious NMI.
>> + */
>> + if (is_acr_self_reload_event(event))
>> + hwc->config &= ~ARCH_PERFMON_EVENTSEL_INT;
>> + else if (!event->attr.precise_ip)
>> + hwc->config |= ARCH_PERFMON_EVENTSEL_INT;
> It seems weird to either clear or set the bit. You don't know the previous
> state of the bit here? I would assume it starts with zero?
It's hard and unsafe to trace the previous state. Generally speaking, the
PMI bit would always be set by default at the initialization, then it would
be cleared later if it's a PEBS or ACR self-reloaded event.
>
>> +static inline bool is_acr_self_reload_event(struct perf_event *event)
>> +{
>> + struct hw_perf_event *hwc = &event->hw;
>> +
>> + if (hwc->idx < 0)
>> + return false;
>> +
>> + return test_bit(hwc->idx, (unsigned long *)&hwc->config1);
> Are you sure this doesn't conflict with some other non ACR usage of config1?
Yes, currently hw.config1 is only used to store ACR event indices.
Thanks.
>
>
> -Andi
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [Patch v2 2/4] perf/x86/intel: Disable PMI for self-reloaded ACR events
2026-04-22 1:24 ` Mi, Dapeng
@ 2026-04-22 17:07 ` Andi Kleen
2026-04-23 1:01 ` Mi, Dapeng
0 siblings, 1 reply; 15+ messages in thread
From: Andi Kleen @ 2026-04-22 17:07 UTC (permalink / raw)
To: Mi, Dapeng
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Eranian Stephane, linux-kernel, linux-perf-users, Dapeng Mi,
Zide Chen, Falcon Thomas, Xudong Hao, stable
> > Are you sure this doesn't conflict with some other non ACR usage of config1?
>
> Yes, currently hw.config1 is only used to store ACR event indices.
Thanks. Should probably rename the field to make that clear.
-Andi
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Patch v2 2/4] perf/x86/intel: Disable PMI for self-reloaded ACR events
2026-04-22 17:07 ` Andi Kleen
@ 2026-04-23 1:01 ` Mi, Dapeng
2026-04-23 9:30 ` Mi, Dapeng
0 siblings, 1 reply; 15+ messages in thread
From: Mi, Dapeng @ 2026-04-23 1:01 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Eranian Stephane, linux-kernel, linux-perf-users, Dapeng Mi,
Zide Chen, Falcon Thomas, Xudong Hao, stable
On 4/23/2026 1:07 AM, Andi Kleen wrote:
>>> Are you sure this doesn't conflict with some other non ACR usage of config1?
>> Yes, currently hw.config1 is only used to store ACR event indices.
> Thanks. Should probably rename the field to make that clear.
Yeah, would do. Thanks.
>
> -Andi
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Patch v2 2/4] perf/x86/intel: Disable PMI for self-reloaded ACR events
2026-04-23 1:01 ` Mi, Dapeng
@ 2026-04-23 9:30 ` Mi, Dapeng
0 siblings, 0 replies; 15+ messages in thread
From: Mi, Dapeng @ 2026-04-23 9:30 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Eranian Stephane, linux-kernel, linux-perf-users, Dapeng Mi,
Zide Chen, Falcon Thomas, Xudong Hao, stable
On 4/23/2026 9:01 AM, Mi, Dapeng wrote:
> On 4/23/2026 1:07 AM, Andi Kleen wrote:
>>>> Are you sure this doesn't conflict with some other non ACR usage of config1?
>>> Yes, currently hw.config1 is only used to store ACR event indices.
>> Thanks. Should probably rename the field to make that clear.
> Yeah, would do. Thanks.
Just look the code again, the config1 is defined in hw_perf_event structure
which is a generic structure used by all kinds of different architectures.
Although currently it's only used to save the ACR events index mask by x86,
it could still be used for other specific usages on other architectures in
the future. So we'd better keep this generic name "config1" then.
Thanks.
>
>
>> -Andi
>>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Patch v2 3/4] perf/x86/intel: Enable auto counter reload for DMR
2026-04-20 2:45 [Patch v2 0/4] perf/x86/intel: Fix several bugs of auto counter Dapeng Mi
2026-04-20 2:45 ` [Patch v2 1/4] perf/x86/intel: Clear stale ACR mask before updating new mask Dapeng Mi
2026-04-20 2:45 ` [Patch v2 2/4] perf/x86/intel: Disable PMI for self-reloaded ACR events Dapeng Mi
@ 2026-04-20 2:45 ` Dapeng Mi
2026-04-20 2:45 ` [Patch v2 4/4] perf/x86/intel: Consolidate MSR_IA32_PERF_CFG_C tracking Dapeng Mi
3 siblings, 0 replies; 15+ messages in thread
From: Dapeng Mi @ 2026-04-20 2:45 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Andi Kleen, Eranian Stephane
Cc: linux-kernel, linux-perf-users, Dapeng Mi, Zide Chen,
Falcon Thomas, Xudong Hao, Dapeng Mi, stable
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().
Cc: stable@vger.kernel.org
Fixes: d345b6bb8860 ("perf/x86/intel: Add core PMU support for DMR")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
V2: New patch.
arch/x86/events/intel/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 510b087c9e89..fa4073bf18fe 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -7506,6 +7506,7 @@ static __always_inline void intel_pmu_init_pnc(struct pmu *pmu)
hybrid(pmu, event_constraints) = intel_pnc_event_constraints;
hybrid(pmu, pebs_constraints) = intel_pnc_pebs_event_constraints;
hybrid(pmu, extra_regs) = intel_pnc_extra_regs;
+ static_call_update(intel_pmu_enable_acr_event, intel_pmu_enable_acr);
}
static __always_inline void intel_pmu_init_skt(struct pmu *pmu)
--
2.34.1
^ permalink raw reply related [flat|nested] 15+ messages in thread* [Patch v2 4/4] perf/x86/intel: Consolidate MSR_IA32_PERF_CFG_C tracking
2026-04-20 2:45 [Patch v2 0/4] perf/x86/intel: Fix several bugs of auto counter Dapeng Mi
` (2 preceding siblings ...)
2026-04-20 2:45 ` [Patch v2 3/4] perf/x86/intel: Enable auto counter reload for DMR Dapeng Mi
@ 2026-04-20 2:45 ` Dapeng Mi
3 siblings, 0 replies; 15+ messages in thread
From: Dapeng Mi @ 2026-04-20 2:45 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Namhyung Kim, Ian Rogers, Adrian Hunter, Alexander Shishkin,
Andi Kleen, Eranian Stephane
Cc: linux-kernel, linux-perf-users, Dapeng Mi, Zide Chen,
Falcon Thomas, Xudong Hao, Dapeng Mi
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>
---
V2: New patch.
arch/x86/events/intel/core.c | 13 +++++++------
arch/x86/events/perf_event.h | 4 +---
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index fa4073bf18fe..667917baf7f2 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3169,10 +3169,10 @@ static void intel_pmu_config_acr(int idx, u64 mask, u32 reload)
wrmsrl(msr_b + msr_offset, mask);
cpuc->acr_cfg_b[idx] = mask;
}
- /* Only need to update the reload value when there is a valid config value. */
- if (mask && cpuc->acr_cfg_c[idx] != reload) {
+ /* Only update CFG_C reload when ACR is actively enabled (mask != 0) */
+ if (mask && ((cpuc->cfg_c_val[idx] & ARCH_PEBS_RELOAD) != reload)) {
wrmsrl(msr_c + msr_offset, reload);
- cpuc->acr_cfg_c[idx] = reload;
+ cpuc->cfg_c_val[idx] = reload;
}
}
@@ -3198,14 +3198,15 @@ static void intel_pmu_enable_event_ext(struct perf_event *event)
{
struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
struct hw_perf_event *hwc = &event->hw;
- union arch_pebs_index old, new;
- struct arch_pebs_cap cap;
u64 ext = 0;
- cap = hybrid(cpuc->pmu, arch_pebs_cap);
+ if (is_acr_event_group(event))
+ ext |= (-hwc->sample_period) & ARCH_PEBS_RELOAD;
if (event->attr.precise_ip) {
u64 pebs_data_cfg = intel_get_arch_pebs_data_config(event);
+ struct arch_pebs_cap cap = hybrid(cpuc->pmu, arch_pebs_cap);
+ union arch_pebs_index old, new;
ext |= ARCH_PEBS_EN;
if (hwc->flags & PERF_X86_EVENT_AUTO_RELOAD)
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index 524668dcf4cc..40d6fe0afc4a 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -322,10 +322,8 @@ struct cpu_hw_events {
u64 fixed_ctrl_val;
u64 active_fixed_ctrl_val;
- /* Intel ACR configuration */
+ /* Intel ACR/arch-PEBS configuration */
u64 acr_cfg_b[X86_PMC_IDX_MAX];
- u64 acr_cfg_c[X86_PMC_IDX_MAX];
- /* Cached CFG_C values */
u64 cfg_c_val[X86_PMC_IDX_MAX];
/*
--
2.34.1
^ permalink raw reply related [flat|nested] 15+ messages in thread