[PATCH 0/2] Fix 2 bugs for Intel auto counter reload (ACR)

[PATCH 0/2] Fix 2 bugs for Intel auto counter reload (ACR)

[Dapeng Mi]

This small patch-set fixes 2 issues in auto counter reload support.
- The stale ACR mask is not cleared before setting a new one. Patch 1/2
  fixes this issue.
- PMI is enabled by default for self-reloaded ACR events which causes
  suspicious NMI warning. Patch 2/2 fixes this issue.

Besides an ACR unit test is added into perf tests which would be posted
in a separate session.

Tests:

Run below ACR sampling commands on CWF and NVL (hybrid platform), no
issues are found.

a. Non-PEBS ACR sampling

perf record -e '{instructions/period=20000,acr_mask=0x2/u,cycles/period=40000,acr_mask=0x3/u}' ~/test

b. PEBS ACR sampling

perf record -e '{instructions/period=20000,acr_mask=0x2/pu,cycles/period=40000,acr_mask=0x3/u}' ~/test


Dapeng Mi (2):
  perf/x86/intel: Clear stale ACR mask before updating new mask
  perf/x86/intel: Disable PMI for self-reloaded ACR events

 arch/x86/events/intel/core.c | 20 ++++++++++++++++----
 arch/x86/events/perf_event.h | 10 ++++++++++
 2 files changed, 26 insertions(+), 4 deletions(-)


base-commit: 9805ed3c91478b08a586861b874bd8b6a2fed648
-- 
2.34.1

[PATCH 1/2] perf/x86/intel: Clear stale ACR mask before updating new mask

[Dapeng Mi]

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>
---
 arch/x86/events/intel/core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 4768236c054b..58c236ce4747 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3344,6 +3344,9 @@ static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
 			event = cpuc->event_list[j];
 			if (event->group_leader != leader->group_leader)
 				break;
+
+			/* Clear stale ACR mask first. */
+			event->hw.config1 = 0;
 			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]))
-- 
2.34.1

[PATCH 2/2] perf/x86/intel: Disable PMI for self-reloaded ACR events

[Dapeng Mi]

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 58c236ce4747..c45cd88c3710 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

Re: [PATCH 0/2] Fix 2 bugs for Intel auto counter reload (ACR)

[Mi, Dapeng]

On 4/13/2026 9:01 AM, Dapeng Mi wrote:
> This small patch-set fixes 2 issues in auto counter reload support.
> - The stale ACR mask is not cleared before setting a new one. Patch 1/2
>   fixes this issue.
> - PMI is enabled by default for self-reloaded ACR events which causes
>   suspicious NMI warning. Patch 2/2 fixes this issue.
>
> Besides an ACR unit test is added into perf tests which would be posted
> in a separate session.

The unit test patch:
https://lore.kernel.org/all/20260413010920.546501-1-dapeng1.mi@linux.intel.com/

Thanks.


>
> Tests:
>
> Run below ACR sampling commands on CWF and NVL (hybrid platform), no
> issues are found.
>
> a. Non-PEBS ACR sampling
>
> perf record -e '{instructions/period=20000,acr_mask=0x2/u,cycles/period=40000,acr_mask=0x3/u}' ~/test
>
> b. PEBS ACR sampling
>
> perf record -e '{instructions/period=20000,acr_mask=0x2/pu,cycles/period=40000,acr_mask=0x3/u}' ~/test
>
>
> Dapeng Mi (2):
>   perf/x86/intel: Clear stale ACR mask before updating new mask
>   perf/x86/intel: Disable PMI for self-reloaded ACR events
>
>  arch/x86/events/intel/core.c | 20 ++++++++++++++++----
>  arch/x86/events/perf_event.h | 10 ++++++++++
>  2 files changed, 26 insertions(+), 4 deletions(-)
>
>
> base-commit: 9805ed3c91478b08a586861b874bd8b6a2fed648

Re: [PATCH 1/2] perf/x86/intel: Clear stale ACR mask before updating new mask

[sashiko-bot]

Sashiko AI review found 2 potential issue(s):
- [High] Incomplete Fix: Early return bypasses the newly added stale mask cleanup for subsequent events.
- [High] Missing bounds check on user-provided mask allows cross-event PMU interference (cross-wiring).
--

commit f516548e46c9feac44792cd958b5c0a840d60d43
Author: Dapeng Mi <dapeng1.mi@linux.intel.com>

perf/x86/intel: Clear stale ACR mask before updating new mask

This commit clears the ACR mask before applying a new one to prevent
stale bits from persisting during event rescheduling. It ensures the
hardware state does not get polluted by previous configurations.

> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 4768236c054bb..58c236ce47474 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -3344,6 +3344,9 @@ static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
>  			event = cpuc->event_list[j];
>  			if (event->group_leader != leader->group_leader)
>  				break;
> +
> +			/* Clear stale ACR mask first. */
> +			event->hw.config1 = 0;
>  			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]))

Could this validation check allow unprivileged users to cross-wire the PMU?

Since is_acr_event_group() only verifies that the target event belongs to any
ACR group, rather than the same group_leader, does this allow a user-provided
out-of-bounds bit in config2 to point to an independent, system-wide ACR event
running on the same CPU?

If so, it seems the hardware counter index of an unrelated privileged event
could be blindly copied into the user's hw.config1.

>  					return;

Does this early return bypass the newly added stale mask cleanup for subsequent
events?

Because attr.config2 is user-controlled, a user could supply a malformed mask
with an out-of-bounds bit to intentionally trigger this early return.

Since it returns from intel_pmu_acr_late_setup() completely, wouldn't this skip
the event->hw.config1 = 0 cleanup for all subsequent ACR events scheduled on the
same CPU, leaving them with a polluted hardware state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260413010157.535990-1-dapeng1.mi@linux.intel.com?part=1

Re: [PATCH 1/2] perf/x86/intel: Clear stale ACR mask before updating new mask

[Mi, Dapeng]

On 4/13/2026 9:35 AM, sashiko-bot@kernel.org wrote:
> Sashiko AI review found 2 potential issue(s):
> - [High] Incomplete Fix: Early return bypasses the newly added stale mask cleanup for subsequent events.
> - [High] Missing bounds check on user-provided mask allows cross-event PMU interference (cross-wiring).
> --
>
> commit f516548e46c9feac44792cd958b5c0a840d60d43
> Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
>
> perf/x86/intel: Clear stale ACR mask before updating new mask
>
> This commit clears the ACR mask before applying a new one to prevent
> stale bits from persisting during event rescheduling. It ensures the
> hardware state does not get polluted by previous configurations.
>
>> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
>> index 4768236c054bb..58c236ce47474 100644
>> --- a/arch/x86/events/intel/core.c
>> +++ b/arch/x86/events/intel/core.c
>> @@ -3344,6 +3344,9 @@ static void intel_pmu_acr_late_setup(struct cpu_hw_events *cpuc)
>>  			event = cpuc->event_list[j];
>>  			if (event->group_leader != leader->group_leader)
>>  				break;
>> +
>> +			/* Clear stale ACR mask first. */
>> +			event->hw.config1 = 0;
>>  			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]))
> Could this validation check allow unprivileged users to cross-wire the PMU?
>
> Since is_acr_event_group() only verifies that the target event belongs to any
> ACR group, rather than the same group_leader, does this allow a user-provided
> out-of-bounds bit in config2 to point to an independent, system-wide ACR event
> running on the same CPU?
>
> If so, it seems the hardware counter index of an unrelated privileged event
> could be blindly copied into the user's hw.config1.

It couldn't be. The above "if (event->group_leader !=
leader->group_leader)" has checked if the events are in a same ACR group.


>
>>  					return;
> Does this early return bypass the newly added stale mask cleanup for subsequent
> events?
>
> Because attr.config2 is user-controlled, a user could supply a malformed mask
> with an out-of-bounds bit to intentionally trigger this early return.
>
> Since it returns from intel_pmu_acr_late_setup() completely, wouldn't this skip
> the event->hw.config1 = 0 cleanup for all subsequent ACR events scheduled on the
> same CPU, leaving them with a polluted hardware state?

Yes, it's possible. It looks we have to do twice iteration for the
event_list.  The 1st iteration is to clear the stale hw.config1 and the 2nd
iteration is to validate and parse the ACR mask. Would fix it in next
version. Thanks.



>