[PATCH AUTOSEL 6.19-6.12] perf/x86/msr: Add Airmont NP

[PATCH AUTOSEL 6.19-6.12] perf/x86/msr: Add Airmont NP

[Sasha Levin]

From: Martin Schiller <ms@dev.tdt.de>

[ Upstream commit 63dbadcafc1f4d1da796a8e2c0aea1e561f79ece ]

Like Airmont, the Airmont NP (aka Intel / MaxLinear Lightning Mountain)
supports SMI_COUNT MSR.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Link: https://patch.msgid.link/20251124074846.9653-2-ms@dev.tdt.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Here is my complete analysis:

---

## Analysis: perf/x86/msr: Add Airmont NP

### 1. Commit Message Analysis

The commit adds support for the Intel Airmont NP (aka Lightning Mountain
/ MaxLinear Lightning Mountain) CPU to the MSR perf driver. The commit
message explicitly states that "Like Airmont, the Airmont NP supports
SMI_COUNT MSR." This is a simple CPU model ID addition to an existing
driver/feature.

The commit was:
- Authored by Martin Schiller (ms@dev.tdt.de), who maintains patches for
  the Lightning Mountain SoC
- Signed off by Peter Zijlstra (Intel), the perf subsystem maintainer
- Reviewed by Dapeng Mi (Intel), an x86 perf developer

### 2. Code Change Analysis

The change is exactly **1 line** in a single file
(`arch/x86/events/msr.c`). It adds:

```c
case INTEL_ATOM_AIRMONT_NP:
```

right after the existing `case INTEL_ATOM_AIRMONT:` line in the
`test_intel()` function. This is a switch-case fall-through that enables
the `PERF_MSR_SMI` counter (which reads `MSR_SMI_COUNT`) for the Airmont
NP CPU model.

Without this patch, on Airmont NP systems:
- `test_intel()` returns `false` for `PERF_MSR_SMI`
- `perf_msr_probe()` skips the SMI counter
- The SMI perf counter is unavailable even though the hardware supports
  it
- Users cannot monitor SMI (System Management Interrupt) counts via perf
  on this CPU

### 3. Classification: CPU Model ID Addition

This falls squarely into the **"NEW DEVICE IDs"** exception category for
stable backports:
- It adds a CPU model ID to an **existing driver** (the MSR perf PMU)
- The driver already exists in all stable trees
- Only the CPU ID is new in the context of this driver
- The `INTEL_ATOM_AIRMONT_NP` / `INTEL_FAM6_ATOM_AIRMONT_NP` define has
  existed since kernel v5.4 (added September 2019 in commit
  `855fa1f362ca`)
- The CPU is already recognized in numerous other kernel subsystems
  (`common.c`, `intel.c`, `tsc_msr.c`, `intel_tcc.c`)

### 4. Scope and Risk Assessment

- **Lines changed**: 1 (absolute minimum)
- **Files touched**: 1
- **Complexity**: Trivially simple - adding a case label to an existing
  switch fall-through group
- **Risk of regression**: Essentially zero. The change only affects
  systems running on the Airmont NP CPU (model 0x75). For all other
  CPUs, behavior is completely unchanged. The added case falls through
  to the same `if (idx == PERF_MSR_SMI) return true;` that all other
  Atom variants in that group use.
- **Subsystem maturity**: The perf MSR driver is mature and stable; this
  same pattern of adding CPU model IDs has been repeated over a dozen
  times in the file's history.

### 5. User Impact

The Intel Airmont NP (Lightning Mountain) is a real SoC used in embedded
networking equipment (routers, CPE devices). Martin Schiller works for
TDT, which produces networking hardware using this SoC. Without this
patch, users of Lightning Mountain-based systems cannot use `perf` to
monitor SMI counts, which is useful for diagnosing system latency and
firmware issues.

The impact is:
- **Who**: Users of Intel Lightning Mountain / Airmont NP embedded
  systems
- **Severity**: Functionality gap - a hardware capability is not exposed
- **Real-world**: The patch author works with the hardware and submitted
  this based on actual need

### 6. Backport Feasibility

- **v6.12 and later**: Patch applies cleanly as-is (uses
  `INTEL_ATOM_AIRMONT_NP` and `x86_vfm`)
- **v6.6, v6.1, v5.15**: Requires trivial name adaptation
  (`INTEL_FAM6_ATOM_AIRMONT_NP` instead of `INTEL_ATOM_AIRMONT_NP`, and
  `x86_model` switch). The `INTEL_FAM6_ATOM_AIRMONT_NP` define exists in
  all these trees.
- **Dependencies**: None. This is a completely standalone one-line
  addition.

### 7. Precedent

The `arch/x86/events/msr.c` file has a long history of similar CPU model
ID additions (Tremont, Tiger Lake, Ice Lake, Comet Lake, Rocket Lake,
Alder Lake, Raptor Lake, Sapphire Rapids, Emerald Rapids, Meteor Lake,
Granite Rapids), all following the exact same pattern. These additions
are the textbook example of the "device ID addition" exception to stable
kernel rules.

### Conclusion

This is a textbook example of a CPU model ID addition to an existing
driver - one of the explicitly allowed exception categories for stable
backports. The change is:
- 1 line, 1 file
- Zero risk of regression to any other hardware
- Enables existing functionality on real hardware that real users depend
  on
- Completely standalone with no dependencies
- The required CPU ID defines exist in all active stable trees
- Following an established pattern seen many times in this exact file

**YES**

 arch/x86/events/msr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/events/msr.c b/arch/x86/events/msr.c
index 7f5007a4752a1..8052596b85036 100644
--- a/arch/x86/events/msr.c
+++ b/arch/x86/events/msr.c
@@ -78,6 +78,7 @@ static bool test_intel(int idx, void *data)
 	case INTEL_ATOM_SILVERMONT:
 	case INTEL_ATOM_SILVERMONT_D:
 	case INTEL_ATOM_AIRMONT:
+	case INTEL_ATOM_AIRMONT_NP:
 
 	case INTEL_ATOM_GOLDMONT:
 	case INTEL_ATOM_GOLDMONT_D:
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] perf/x86/intel: Add Airmont NP

[Sasha Levin]

From: Martin Schiller <ms@dev.tdt.de>

[ Upstream commit a08340fd291671c54d379d285b2325490ce90ddd ]

The Intel / MaxLinear Airmont NP (aka Lightning Mountain) supports the
same architectual and non-architecural events as Airmont.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Link: https://patch.msgid.link/20251124074846.9653-3-ms@dev.tdt.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This confirms the commit under review only touches `core.c`, and other
files in the perf events subsystem also lack Airmont NP support (which
may be handled by other patches in the series, but this commit is
standalone).

---

## Comprehensive Analysis

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** `perf/x86/intel: Add Airmont NP`

The commit adds the `INTEL_ATOM_AIRMONT_NP` (Lightning Mountain SoC, CPU
model 0x75) case label to the Silvermont/Airmont PMU initialization
block in `intel_pmu_init()`. The commit message states this CPU supports
the same architectural and non-architectural events as Airmont, so it
should share the same event tables.

The commit was reviewed by `Dapeng Mi <dapeng1.mi@linux.intel.com>` (an
Intel PMU engineer) and merged by Peter Zijlstra. The patch link
`20251124074846.9653-3-ms@dev.tdt.de` indicates this is patch 3 of a
series, but the change itself is self-contained.

### 2. CODE CHANGE ANALYSIS

The diff shows a **single-line addition**:

```7407:7408:arch/x86/events/intel/core.c
        case INTEL_ATOM_AIRMONT:
        case INTEL_ATOM_AIRMONT_NP:
```

This adds `case INTEL_ATOM_AIRMONT_NP:` to an existing `switch
(boot_cpu_data.x86_vfm)` case block that groups Silvermont and Airmont
CPUs together. The block configures:
- Cache event IDs (`slm_hw_cache_event_ids`)
- Cache extra regs (`slm_hw_cache_extra_regs`)
- LBR initialization (`intel_pmu_lbr_init_slm()`)
- Event constraints (`intel_slm_event_constraints`)
- PEBS constraints (`intel_slm_pebs_event_constraints`)
- Extra registers (`intel_slm_extra_regs`)
- TopDown and format attributes

**Without this patch:** On Airmont NP (Lightning Mountain) systems,
`intel_pmu_init()` falls through to the `default:` case, which only
provides generic architectural perfmon support (using the version-based
sub-switch). Users would get:
- No Silvermont-specific hardware cache event support
- No LBR (Last Branch Record) support
- Generic event constraints instead of Silvermont-tuned ones
- No PEBS (Processor Event-Based Sampling) support appropriate for the
  microarchitecture
- No TopDown or extra format attributes

This significantly degrades perf monitoring capability on real hardware.

### 3. CLASSIFICATION

This is a **device ID addition to an existing driver**, which is one of
the explicitly enumerated exceptions allowed in stable:

> "NEW DEVICE IDs (Very Common): Adding PCI IDs, USB IDs, ACPI IDs, etc.
to existing drivers. These are trivial one-line additions that enable
hardware support. Rule: The driver must already exist in stable; only
the ID is new."

The `INTEL_ATOM_AIRMONT_NP` define (model `IFM(6, 0x75)`) has existed in
`arch/x86/include/asm/intel-family.h` since kernel v5.4 (commit
`855fa1f362ca`, September 2019). This means it is available in **all
currently maintained stable trees** (5.4, 5.10, 5.15, 6.1, 6.6, 6.12).
The Silvermont/Airmont event tables and LBR code all predate v5.4 as
well.

The CPU model is already handled in multiple other subsystems:
- `arch/x86/kernel/cpu/common.c` - vulnerability whitelist
- `arch/x86/kernel/cpu/intel.c` - TSC features
- `arch/x86/kernel/tsc_msr.c` - TSC frequency
- `drivers/thermal/intel/intel_tcc.c` - thermal management

The perf events subsystem was simply missed when the CPU ID was first
added.

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** 1 (single `case` label addition)
- **Files touched:** 1 (`arch/x86/events/intel/core.c`)
- **Risk:** Extremely low - this is a fall-through case label addition
  to an existing switch block. It only affects systems with CPUID family
  6 model 0x75. No other CPU model is affected.
- **Dependencies:** None. `INTEL_ATOM_AIRMONT_NP` is already defined in
  `intel-family.h` in all stable trees. The Silvermont event tables all
  exist in stable.

### 5. USER IMPACT

The Lightning Mountain (Airmont NP) SoC is used in Intel/MaxLinear
network gateway devices. The author Martin Schiller is from TDT GmbH, a
networking equipment company, and has several commits related to
Lantiq/Intel LGM networking platforms. This is a real embedded platform
with real users who need proper perf support.

Without this patch, `perf stat`, `perf record`, and other perf tools
provide only basic generic counter support, missing the Silvermont-
specific events, PEBS, LBR, and proper event constraints.

### 6. STABILITY INDICATORS

- **Reviewed-by:** Dapeng Mi (Intel PMU engineer)
- **Merged by:** Peter Zijlstra (perf subsystem maintainer)
- **Pattern:** This is a well-established pattern - the switch statement
  in `intel_pmu_init()` has dozens of similar case additions over the
  years
- **No possible regression:** Only affects one specific CPU model

### 7. DEPENDENCY CHECK

The commit is fully self-contained. The `INTEL_ATOM_AIRMONT_NP` macro
exists in all stable trees since v5.4. The Silvermont event tables and
LBR code it hooks into have existed since well before v5.4. No other
patches from the series are required for this change to be correct and
useful.

### Conclusion

This is a textbook example of a device ID addition to an existing driver
- a single `case` label adding CPU model support to the perf PMU
initialization switch statement. The CPU model define has existed in the
kernel since v5.4. The change is trivially correct (confirmed by Intel
PMU engineer review), zero-risk (only affects one specific CPU model),
and enables proper perf monitoring on real embedded hardware. It matches
the explicit stable exception for device ID additions perfectly.

**YES**

 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 bdf3f0d0fe216..d85df652334fb 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -7405,6 +7405,7 @@ __init int intel_pmu_init(void)
 	case INTEL_ATOM_SILVERMONT_D:
 	case INTEL_ATOM_SILVERMONT_MID:
 	case INTEL_ATOM_AIRMONT:
+	case INTEL_ATOM_AIRMONT_NP:
 	case INTEL_ATOM_SILVERMONT_MID2:
 		memcpy(hw_cache_event_ids, slm_hw_cache_event_ids,
 			sizeof(hw_cache_event_ids));
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.18] perf/core: Fix slow perf_event_task_exit() with LBR callstacks

[Sasha Levin]

From: Namhyung Kim <namhyung@kernel.org>

[ Upstream commit 4960626f956d63dce57f099016c2ecbe637a8229 ]

I got a report that a task is stuck in perf_event_exit_task() waiting
for global_ctx_data_rwsem.  On large systems with lots threads, it'd
have performance issues when it grabs the lock to iterate all threads
in the system to allocate the context data.

And it'd block task exit path which is problematic especially under
memory pressure.

  perf_event_open
    perf_event_alloc
      attach_perf_ctx_data
        attach_global_ctx_data
          percpu_down_write (global_ctx_data_rwsem)
            for_each_process_thread
              alloc_task_ctx_data
                                               do_exit
                                                 perf_event_exit_task
                                                   percpu_down_read (global_ctx_data_rwsem)

It should not hold the global_ctx_data_rwsem on the exit path.  Let's
skip allocation for exiting tasks and free the data carefully.

Reported-by: Rosalie Fang <rosaliefang@google.com>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260112165157.1919624-1-namhyung@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

---

## Comprehensive Analysis

### 1. COMMIT MESSAGE ANALYSIS

**Subject**: "perf/core: Fix slow perf_event_task_exit() with LBR
callstacks"

The commit message clearly describes a **performance regression / system
hang** scenario. Key indicators:
- **"I got a report that a task is stuck"** - real-world report from a
  Google engineer (Rosalie Fang)
- **"On large systems with lots threads, it'd have performance issues"**
  - reproducible on production systems
- **"it'd block task exit path which is problematic especially under
  memory pressure"** - can escalate to system unresponsiveness
- **Reported-by: Rosalie Fang <rosaliefang@google.com>** - actual user
  report
- **Suggested-by: Peter Zijlstra** and **Signed-off-by: Peter Zijlstra**
  - the perf subsystem maintainer suggested and approved the fix

The commit message illustrates the exact deadlock scenario:
1. `perf_event_open` -> `attach_global_ctx_data` takes
   `global_ctx_data_rwsem` as a **writer** and iterates all threads to
   allocate context data
2. Simultaneously, a task calling `do_exit` -> `perf_event_exit_task`
   tries to take `global_ctx_data_rwsem` as a **reader**
3. On large systems with many threads, the write lock is held for a long
   time during the `for_each_process_thread` loop, blocking ALL task
   exits

This is effectively a **priority inversion / livelock** scenario where
task exit (a critical path) is blocked by a potentially very long
operation (iterating and allocating for all threads in the system).

### 2. CODE CHANGE ANALYSIS

The patch makes three coordinated changes:

#### Change 1: Skip exiting tasks in `attach_global_ctx_data()` (lines
5483-5484 in the diff)

```c
for_each_process_thread(g, p) {
    if (p->flags & PF_EXITING)
        continue;
```

This adds a check to skip tasks that are already exiting during the
global iteration. No point allocating context data for a task that's
about to die.

#### Change 2: Detect and undo allocation for exiting tasks in
`attach_task_ctx_data()` (lines 5427-5434 in the diff)

After successfully attaching via `try_cmpxchg`, the code now checks:
```c
if (task->flags & PF_EXITING) {
    /* detach_task_ctx_data() may free it already */
    if (try_cmpxchg(&task->perf_ctx_data, &cd, NULL))
        perf_free_ctx_data_rcu(cd);
}
```

This handles the race where `attach_global_ctx_data()` allocates for a
task that starts exiting between the `PF_EXITING` check and the
`try_cmpxchg`. If we detect the task is exiting, we undo our allocation.

The key insight: The `try_cmpxchg()` in `attach_task_ctx_data()` pairs
with the `try_cmpxchg()` in `detach_task_ctx_data()` to provide total
ordering. If `attach_task_ctx_data()` succeeds the cmpxchg first, it
will see `PF_EXITING` and undo the allocation. If
`detach_task_ctx_data()` (called from `perf_event_exit_task`) succeeds
first, the undo cmpxchg will fail (because `cd` is no longer at
`task->perf_ctx_data`), which is fine.

#### Change 3: Remove lock from `perf_event_exit_task()` (lines
14558-14603 in the diff)

The critical change:
```c
// BEFORE:
guard(percpu_read)(&global_ctx_data_rwsem);
detach_task_ctx_data(task);

// AFTER (no lock):
detach_task_ctx_data(task);
```

The comment explains the correctness:
> Done without holding global_ctx_data_rwsem; typically
attach_global_ctx_data() will skip over this task, but otherwise
attach_task_ctx_data() will observe PF_EXITING.

**Correctness argument**:
- `PF_EXITING` is set in `exit_signals()` (line 913 of exit.c)
  **before** `perf_event_exit_task()` is called (line 951)
- The `try_cmpxchg()` operations provide atomic visibility of
  `task->perf_ctx_data` changes
- If `attach_global_ctx_data()` races with exit: either it sees
  `PF_EXITING` and skips, or if it allocates, `attach_task_ctx_data()`
  sees `PF_EXITING` after the cmpxchg and undoes the allocation
- `detach_task_ctx_data()` uses `try_cmpxchg` to atomically clear the
  pointer, so concurrent operations are safe

### 3. BUG CLASSIFICATION

This is a **performance regression / system hang** fix. The
`global_ctx_data_rwsem` write lock blocks ALL readers (task exits) while
iterating ALL threads. On systems with thousands of threads:
- Opening a perf event with LBR callstacks causes the write lock to be
  held for a long time
- Every task trying to exit during this period blocks on the read lock
- Under memory pressure, blocked task exits compound the problem (tasks
  holding memory can't release it)
- This can effectively hang the system

### 4. SCOPE AND RISK ASSESSMENT

**Lines changed**: ~25 lines added/changed in a single file
(`kernel/events/core.c`)
**Files touched**: 1
**Complexity**: Moderate - the synchronization relies on cmpxchg +
PF_EXITING flag ordering
**Risk**: LOW-MEDIUM
  - The fix is self-contained within the perf subsystem
  - The cmpxchg-based synchronization replaces a lock-based approach,
    which is more lockless but well-reasoned
  - Peter Zijlstra (the maintainer) both suggested and signed off on the
    approach
  - The worst case if the fix has a subtle race: a small memory leak of
    one `perf_ctx_data` allocation (not a crash)

### 5. USER IMPACT

**Who is affected**: Anyone using perf with LBR callstacks (Intel) in
system-wide mode on systems with many threads. This is common on:
- Large servers doing production profiling
- CI/CD systems running perf monitoring
- Google's production fleet (where the bug was reported)

**Severity**: HIGH - can block the task exit path, which is critical.
Under memory pressure this can effectively hang the system.

### 6. STABILITY & TRUST INDICATORS

- **Reported-by**: Rosalie Fang from Google - real production issue
- **Suggested-by**: Peter Zijlstra (perf maintainer) - expert-designed
  solution
- **Signed-off-by**: Both Namhyung Kim (author) and Peter Zijlstra
  (maintainer)
- **Link**: Has a patch.msgid.link reference showing proper mailing list
  review

### 7. DEPENDENCY CHECK

The affected code was introduced in:
- `cb43691293390` "perf: Save PMU specific data in task_struct"
  (v6.15-rc1)
- `506e64e710ff9` "perf: attach/detach PMU specific data" (v6.15-rc1)

**Applicable stable trees**: 6.15.y, 6.16.y, 6.17.y, 6.18.y
**NOT applicable**: 6.14.y and earlier (code doesn't exist)

The patch is self-contained - it doesn't depend on any other commits. It
modifies only the code introduced by the above commits and the logic is
self-sufficient.

### 8. MINOR CLEANUP CONCERN

The patch also removes a `(struct perf_ctx_data **)` cast from one
`try_cmpxchg` call in `attach_task_ctx_data()`. This is a minor
whitespace/type-correctness issue and doesn't affect functionality -
`try_cmpxchg` on an `__rcu` pointer works the same way.

### CONCLUSION

This commit fixes a real, reported, production-impacting performance bug
that can cause task exit to hang on systems with many threads when LBR
callstack profiling is active. The fix is:

1. **Obviously correct**: The synchronization relies on the well-
   established pattern of `PF_EXITING` flag + atomic cmpxchg operations,
   with clear ordering guarantees
2. **Fixes a real bug**: Reported by a Google engineer on production
   systems
3. **Important**: Can cause system hangs, especially under memory
   pressure
4. **Small and contained**: ~25 lines in a single file, touching only
   the perf subsystem
5. **No new features**: Just removes unnecessary lock contention
6. **Expert-reviewed**: Suggested by Peter Zijlstra, the perf subsystem
   maintainer

The fix should be backported to all stable trees containing the affected
code (6.15.y through 6.18.y).

**YES**

 kernel/events/core.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 8cca800946248..69c56cad88a89 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5280,9 +5280,20 @@ attach_task_ctx_data(struct task_struct *task, struct kmem_cache *ctx_cache,
 		return -ENOMEM;
 
 	for (;;) {
-		if (try_cmpxchg((struct perf_ctx_data **)&task->perf_ctx_data, &old, cd)) {
+		if (try_cmpxchg(&task->perf_ctx_data, &old, cd)) {
 			if (old)
 				perf_free_ctx_data_rcu(old);
+			/*
+			 * Above try_cmpxchg() pairs with try_cmpxchg() from
+			 * detach_task_ctx_data() such that
+			 * if we race with perf_event_exit_task(), we must
+			 * observe PF_EXITING.
+			 */
+			if (task->flags & PF_EXITING) {
+				/* detach_task_ctx_data() may free it already */
+				if (try_cmpxchg(&task->perf_ctx_data, &cd, NULL))
+					perf_free_ctx_data_rcu(cd);
+			}
 			return 0;
 		}
 
@@ -5328,6 +5339,8 @@ attach_global_ctx_data(struct kmem_cache *ctx_cache)
 	/* Allocate everything */
 	scoped_guard (rcu) {
 		for_each_process_thread(g, p) {
+			if (p->flags & PF_EXITING)
+				continue;
 			cd = rcu_dereference(p->perf_ctx_data);
 			if (cd && !cd->global) {
 				cd->global = 1;
@@ -14294,8 +14307,11 @@ void perf_event_exit_task(struct task_struct *task)
 
 	/*
 	 * Detach the perf_ctx_data for the system-wide event.
+	 *
+	 * Done without holding global_ctx_data_rwsem; typically
+	 * attach_global_ctx_data() will skip over this task, but otherwise
+	 * attach_task_ctx_data() will observe PF_EXITING.
 	 */
-	guard(percpu_read)(&global_ctx_data_rwsem);
 	detach_task_ctx_data(task);
 }
 
-- 
2.51.0

[PATCH AUTOSEL 6.19-6.12] perf/x86/cstate: Add Airmont NP

[Sasha Levin]

From: Martin Schiller <ms@dev.tdt.de>

[ Upstream commit 3006911f284d769b0f66c12b39da130325ef1440 ]

From the perspective of Intel cstate residency counters, the Airmont NP
(aka Lightning Mountain) is identical to the Airmont.

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Link: https://patch.msgid.link/20251124074846.9653-4-ms@dev.tdt.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Here is my analysis:

---

## Detailed Analysis of "perf/x86/cstate: Add Airmont NP"

### 1. COMMIT MESSAGE ANALYSIS

The commit adds a single CPU model ID entry for Intel Airmont NP (also
known as Lightning Mountain, CPU model 0x75) to the perf cstate
residency counter driver's match table. The author, Martin Schiller from
TDT (a networking hardware company), states that from the perspective of
cstate residency counters, Airmont NP is identical to regular Airmont.
The patch was reviewed by Dapeng Mi (Intel) and signed off by Peter
Zijlstra (Intel), the perf maintainer.

The message ID `20251124074846.9653-4-ms@dev.tdt.de` indicates this is
patch 4 of a multi-patch series, which likely adds Airmont NP support to
several Intel subsystems simultaneously.

### 2. CODE CHANGE ANALYSIS

The change is a single line addition:

```c
X86_MATCH_VFM(INTEL_ATOM_AIRMONT_NP,    &slm_cstates),
```

This maps CPU model `INTEL_ATOM_AIRMONT_NP` (IFM(6, 0x75)) to the
`slm_cstates` configuration, which provides:
- **Core events**: C1 and C6 residency counters
- **Package events**: C6 residency counter (using the C7 MSR quirk)

This is the exact same cstate model used by Silvermont
(`INTEL_ATOM_SILVERMONT`), Silvermont-D (`INTEL_ATOM_SILVERMONT_D`), and
regular Airmont (`INTEL_ATOM_AIRMONT`). The Airmont NP is
architecturally an Airmont-based SoC, so sharing the same cstate
configuration is technically correct and expected.

### 3. CLASSIFICATION: NEW DEVICE ID

This falls squarely into the **"New Device ID"** exception category for
stable backports:
- The driver (`arch/x86/events/intel/cstate.c`) already exists in all
  stable trees back to v5.4
- The `slm_cstates` model structure already exists unchanged in all
  stable trees
- The `INTEL_ATOM_AIRMONT_NP` (or `INTEL_FAM6_ATOM_AIRMONT_NP`) macro
  has been defined since v5.4 (commit 855fa1f362ca from September 2019)
- Only the ID-to-model mapping is new

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed**: 1 addition
- **Files touched**: 1 (`arch/x86/events/intel/cstate.c`)
- **Complexity**: Trivial - a single entry in a match table
- **Risk of regression**: Essentially zero. The new line only activates
  when running on an Airmont NP CPU (model 0x75). It cannot affect any
  other CPU or any other code path.

### 5. USER IMPACT

Without this patch, users running Linux on the Intel Lightning Mountain
SoC (used in networking/embedded equipment like DSL/fiber routers from
companies such as TDT) cannot access perf cstate residency counters.
These counters are used by power management monitoring tools like `perf`
and `turbostat` to measure CPU power states. While not a crash or data
corruption bug, this is a hardware support gap for real users on real
hardware.

The Lightning Mountain SoC vulnerability whitelist entry already exists
in `arch/x86/kernel/cpu/common.c` (since earlier kernels), and
`arch/x86/kernel/tsc_msr.c` already has Airmont NP support. The cstate
driver was simply overlooked.

### 6. BACKPORTABILITY TO STABLE TREES

The change requires trivial adaptation for different stable trees due to
macro naming:

- **v6.12+**: Uses `X86_MATCH_VFM(INTEL_ATOM_AIRMONT_NP, &slm_cstates)`
  - applies as-is
- **v6.1, v6.6**: Uses `X86_MATCH_INTEL_FAM6_MODEL(ATOM_AIRMONT_NP,
  &slm_cstates)` - trivial macro name change
- **v5.4, v5.10, v5.15**: Uses
  `X86_CSTATES_MODEL(INTEL_FAM6_ATOM_AIRMONT_NP, slm_cstates)` (v5.4) or
  `X86_MATCH_INTEL_FAM6_MODEL` variant - trivial adaptation

All prerequisites (`slm_cstates` struct, the `AIRMONT_NP` macro) exist
in every supported stable tree.

### 7. DEPENDENCY CHECK

This commit is self-contained. While it's part of a series (patch 4/N),
each patch in such a series independently adds a CPU ID to a different
driver's match table. No other commits are needed for this one to
function correctly.

### 8. STABILITY INDICATORS

- **Reviewed-by**: Dapeng Mi (Intel) - domain expert
- **Signed-off-by**: Peter Zijlstra (Intel) - perf subsystem maintainer
- The pattern is well-established: every other Atom variant (Silvermont,
  Silvermont-D, Airmont, Goldmont, Tremont, etc.) follows the exact same
  pattern in this driver

---

## Summary

This is a textbook CPU ID addition to an existing driver - the exact
type of change that stable kernel rules explicitly permit as an
exception. It's a single-line, zero-risk change that enables hardware
monitoring on real embedded/networking hardware (Intel Lightning
Mountain SoC). The driver infrastructure, cstate model, and CPU ID
definitions are all already present in every supported stable tree. The
patch was reviewed by an Intel engineer and accepted by the perf
maintainer.

**YES**

 arch/x86/events/intel/cstate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
index fa67fda6e45b4..c1e318bdaa397 100644
--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -599,6 +599,7 @@ static const struct x86_cpu_id intel_cstates_match[] __initconst = {
 	X86_MATCH_VFM(INTEL_ATOM_SILVERMONT,	&slm_cstates),
 	X86_MATCH_VFM(INTEL_ATOM_SILVERMONT_D,	&slm_cstates),
 	X86_MATCH_VFM(INTEL_ATOM_AIRMONT,	&slm_cstates),
+	X86_MATCH_VFM(INTEL_ATOM_AIRMONT_NP,	&slm_cstates),
 
 	X86_MATCH_VFM(INTEL_BROADWELL,		&snb_cstates),
 	X86_MATCH_VFM(INTEL_BROADWELL_D,	&snb_cstates),
-- 
2.51.0