x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem

Customers have identified an issue while using the QoS resource Control

feature. If a memory bandwidth associated with a CLOSID is aggressively

throttled, and it moves into Kernel mode, the Kernel operations are also

aggressively throttled. This can stall forward progress and eventually degrade overall system performance. AMD hardware supports a feature Privilege-Level Zero Association (PLZA) to change the association of the thread as soon as it begins executing.

Privilege-Level Zero Association (PLZA) allows the user to specify a CLOSID and/or RMID associated with execution in Privilege-Level Zero. When enabled on a HW thread, when the thread enters Privilege-Level Zero, transactions

associated with that thread will be associated with the PLZA CLOSID and/or RMID. Otherwise, the HW thread will be associated with the CLOSID and RMID identified by PQR_ASSOC.

Add PLZA support to resctrl and introduce a kernel parameter that allows enabling or disabling the feature at boot time.

The GLBE feature details are documented in:

AMD64 Zen6 Platform Quality of Service (PQOS) Extensions:
Publication # 69193 Revision: 1.00, Issue Date: March 2026

available at https://bugzilla.kernel.org/show_bug.cgi?id=206537

Signed-off-by Babu Moger <[email protected]>

---
v3: Code did not change. Patch order cahnged.
Added documentation link.

v2: Rebased on top of the latest tip.

---
 Documentation/admin-guide/kernel-parameters.txt | 2 +-
 arch/x86/include/asm/cpufeatures.h              | 1 +
 arch/x86/kernel/cpu/resctrl/core.c              | 2 ++
 arch/x86/kernel/cpu/scattered.c                 | 1 +

Hi Babu,

Quoted 1 line · Babu Moger

Customers have identified an issue while using the QoS resource Control

"Control" -> "control"?

Quoted 1 line

feature. If a memory bandwidth associated with a CLOSID is aggressively

"a memory bandwidth" -> "memory bandwidth"?

Quoted 2 lines

throttled, and it moves into Kernel mode, the Kernel operations are also

What does "it" refer to here? From text it seems to be the "CLOSID" but that does not sound right? Should "it" instead be something like "a task with that CLOSID"?

"Kernel" -> "kernel"?

Quoted 5 lines

aggressively throttled. This can stall forward progress and eventually degrade overall system performance. AMD hardware supports a feature Privilege-Level Zero Association (PLZA) to change the association of the thread as soon as it begins executing.

"change the association of the thread as soon as it begins executing." I am not able to parse this.

Quoted 4 lines

Privilege-Level Zero Association (PLZA) allows the user to specify a CLOSID and/or RMID associated with execution in Privilege-Level Zero. When enabled on a HW thread, when the thread enters Privilege-Level Zero, transactions

Could you please use consistent terminology throughout this series? This patch uses "HW thread"/"thread", the next patch then switches to "logical processor", and then by patch #4 the term seems to settle on "CPU". Could this just be "CPU" from here and throughout series to be consistent and easier to read?

What is meant with "transactions"? Is this just about memory transactions? Using this term combined with earlier "memory bandwidth" related problem description hints that this feature just impacts memory bandwidth allocation but from what I understand this impacts all allocation (CLOSID of all resources) and monitoring.

Could "transactions" be replaced with "allocation and monitoring" and be more accurate?

Quoted 4 lines

associated with that thread will be associated with the PLZA CLOSID and/or RMID. Otherwise, the HW thread will be associated with the CLOSID and RMID identified by PQR_ASSOC.

Quoted 4 lines

Add PLZA support to resctrl and introduce a kernel parameter that allows enabling or disabling the feature at boot time.

The GLBE feature details are documented in:

"GLBE" -> "PLZA"?

Quoted 5 lines

AMD64 Zen6 Platform Quality of Service (PQOS) Extensions:

   Publication # 69193 Revision: 1.00, Issue Date: March 2026

available at https://bugzilla.kernel.org/show_bug.cgi?id=206537

Please follow same style as what you used in the assignable counter enabling where this URL is provided via a "Link:" tag and then the text can refer to it. Specifically,

	Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [1]

Quoted 6 lines

Signed-off-by Babu Moger <[email protected]>

---
v3: Code did not change. Patch order cahnged.
Added documentation link.

Quoted 6 lines

v2: Rebased on top of the latest tip.

---
  Documentation/admin-guide/kernel-parameters.txt | 2 +-
  arch/x86/include/asm/cpufeatures.h              | 1 +
  arch/x86/kernel/cpu/resctrl/core.c              | 2 ++
  arch/x86/kernel/cpu/scattered.c                 | 1 +

Please split changes to other subsystems and make these changes obvious with their own subject prefix to avoid sneaking changes into other subsystems via resctrl.

Hi Reinette,

Quoted 7 lines · Reinette Chatre

Hi Babu,

Quoted 1 line · Babu Moger

Customers have identified an issue while using the QoS resource Control

"Control" -> "control"?

ack

Quoted 3 lines

Quoted 1 line

feature. If a memory bandwidth associated with a CLOSID is aggressively

"a memory bandwidth" -> "memory bandwidth"?

ack.

Quoted 6 lines

Quoted 2 lines

throttled, and it moves into Kernel mode, the Kernel operations are also

What does "it" refer to here? From text it seems to be the "CLOSID" but that does not sound right? Should "it" instead be something like "a task with that CLOSID"?

sure.

Quoted 2 lines

"Kernel" -> "kernel"?

ack.

Quoted 6 lines

Quoted 5 lines

aggressively throttled. This can stall forward progress and eventually degrade overall system performance. AMD hardware supports a feature Privilege-Level Zero Association (PLZA) to change the association of the thread as soon as it begins executing.

Quoted 2 lines

"change the association of the thread as soon as it begins executing." I am not able to parse this.

How about ?

Customers have identified an issue while using the QoS resource Control

Hi Reinette,

Quoted 7 lines · Reinette Chatre

Hi Babu,

Quoted 1 line · Babu Moger

Customers have identified an issue while using the QoS resource Control

"Control" -> "control"?

ack

Quoted 3 lines

Quoted 1 line

feature. If a memory bandwidth associated with a CLOSID is aggressively

"a memory bandwidth" -> "memory bandwidth"?

ack.

Quoted 6 lines

Quoted 2 lines

throttled, and it moves into Kernel mode, the Kernel operations are also

What does "it" refer to here? From text it seems to be the "CLOSID" but that does not sound right? Should "it" instead be something like "a task with that CLOSID"?

sure.

Quoted 2 lines

"Kernel" -> "kernel"?

ack.

Quoted 8 lines

Quoted 5 lines

aggressively throttled. This can stall forward progress and eventually degrade overall system performance. AMD hardware supports a feature Privilege-Level Zero Association (PLZA) to change the association of the thread as soon as it begins executing.

"change the association of the thread as soon as it begins executing." I am not able to parse this.

How about ?

Customers have identified an issue while using the QoS resource Control
feature. If memory bandwidth associated with a CLOSID is aggressively
throttled, and a task with that CLOSID moves into kernel mode, the kernel operations are also aggressively throttled. This can stall forward progress and eventually degrade overall system performance. AMD hardware supports a feature Privilege-Level Zero Association (PLZA)
to change the CPU association at the user-to-kernel transition, so the kernel execution can use a different association than user mode.

Privilege-Level Zero Association (PLZA) allows the user to specify a> CLOSID and/or RMID associated with execution in Privilege-Level Zero. When enabled on a CPU, as the CPU enters Privilege-Level Zero,
allocation and monitoring for that CPU will be associated with the
PLZA CLOSID and/or RMID. Otherwise, the CPU will be associated with
the CLOSID and RMID given by PQR_ASSOC.

Quoted 9 lines

Quoted 4 lines

  Documentation/admin-guide/kernel-parameters.txt | 2 +- arch/x86/include/asm/cpufeatures.h              | 1 + arch/x86/kernel/cpu/resctrl/core.c              | 2 ++ arch/x86/kernel/cpu/scattered.c                 | 1 +

Please split changes to other subsystems and make these changes obvious with their own subject prefix to avoid sneaking changes into other subsystems via resctrl.

Ok. Will be two patches.
1. For Documentation/admin-guide/kernel-parameters.txt 2.  arch/x86/include/asm/cpufeatures.h arch/x86/kernel/cpu/resctrl/core.c arch/x86/kernel/cpu/scattered.c

Hi Babu,

Quoted 41 lines · Babu

Hi Reinette,

Quoted 7 lines · Reinette Chatre

Hi Babu,

Quoted 1 line · Babu Moger

Customers have identified an issue while using the QoS resource Control

"Control" -> "control"?

ack

Quoted 3 lines

Quoted 1 line

feature. If a memory bandwidth associated with a CLOSID is aggressively

"a memory bandwidth" -> "memory bandwidth"?

ack.

Quoted 6 lines

Quoted 2 lines

throttled, and it moves into Kernel mode, the Kernel operations are also

What does "it" refer to here? From text it seems to be the "CLOSID" but that does not sound right? Should "it" instead be something like "a task with that CLOSID"?

sure.

Quoted 2 lines

"Kernel" -> "kernel"?

ack.

Quoted 8 lines

Quoted 5 lines

aggressively throttled. This can stall forward progress and eventually degrade overall system performance. AMD hardware supports a feature Privilege-Level Zero Association (PLZA) to change the association of the thread as soon as it begins executing.

"change the association of the thread as soon as it begins executing." I am not able to parse this.

Quoted 7 lines

How about ?

Customers have identified an issue while using the QoS resource Control
feature. If memory bandwidth associated with a CLOSID is aggressively
throttled, and a task with that CLOSID moves into kernel mode, the kernel operations are also aggressively throttled. This can stall forward progress and eventually degrade overall system performance. AMD hardware supports a feature Privilege-Level Zero Association (PLZA)
to change the CPU association at the user-to-kernel transition, so the kernel execution can use a different association than user mode.

"change the CPU association at the user-to-kernel transition" -> What is this trying to describe? CPU association of what?

"a different association"? What does this mean?

Quoted 6 lines

Privilege-Level Zero Association (PLZA) allows the user to specify a> CLOSID and/or RMID associated with execution in Privilege-Level Zero. When enabled on a CPU, as the CPU enters Privilege-Level Zero,
allocation and monitoring for that CPU will be associated with the
PLZA CLOSID and/or RMID. Otherwise, the CPU will be associated with
the CLOSID and RMID given by PQR_ASSOC.

Sounds like this is vague because MSR_IA32_PQR_PLZA_ASSOC has not been introduced yet. Could it help to introduce MSR_IA32_PQR_PLZA_ASSOC as part of this patch and then the changelog can be specific about PLZA feature introducing this new MSR and how it complements MSR_IA32_PQR_ASSOC?

...

Quoted 10 lines

Quoted 9 lines

Quoted 4 lines

   Documentation/admin-guide/kernel-parameters.txt | 2 +-
   arch/x86/include/asm/cpufeatures.h              | 1 +
   arch/x86/kernel/cpu/resctrl/core.c              | 2 ++
   arch/x86/kernel/cpu/scattered.c                 | 1 +

Please split changes to other subsystems and make these changes obvious with their own subject prefix to avoid sneaking changes into other subsystems via resctrl.

Quoted 5 lines

Ok. Will be two patches.
1. For Documentation/admin-guide/kernel-parameters.txt 2.  arch/x86/include/asm/cpufeatures.h arch/x86/kernel/cpu/resctrl/core.c arch/x86/kernel/cpu/scattered.c

The resctrl changes found in (2) would be documented in (1)? That does not look right. Why not just split the resctrl changes from the cpufeatures changes? This would be similar to how you did ABMC enabling.

Privilege Level Zero Association (PLZA) is configured per logical processor via MSR_IA32_PQR_PLZA_ASSOC (0xc00003fc). Software must program RMID and CLOSID association fields and their enable bits using the layout defined for the MSR.

Define MSR_IA32_PQR_PLZA_ASSOC and the RMID_EN, CLOSID_EN, and PLZA_EN bit masks in asm/msr-index.h. Add union msr_pqr_plza_assoc in arch resctrl internal.h

Signed-off-by Babu Moger <[email protected]>

---

arch/x86/include/asm/msr-index.h +1 -0

index 9dc6b610e4e2..623628d3c643 100644
@@ -1287,10 +1287,17 @@
 /* - AMD: */
 #define MSR_IA32_MBA_BW_BASE		0xc0000200
 #define MSR_IA32_SMBA_BW_BASE		0xc0000280
+#define MSR_IA32_PQR_PLZA_ASSOC		0xc00003fc

arch/x86/kernel/cpu/resctrl/internal.h +8 -0

+ */
+union msr_pqr_plza_assoc {
+	struct {
+		unsigned long rmid	:12,
+			      reserved1	:19,
+			      rmid_en	: 1,
+			      closid	: 4,
+			      reserved2	:11,

Quoted 13 lines

arch/x86/include/asm/msr-index.h +1 -0

index 9dc6b610e4e2..623628d3c643 100644
@@ -1287,10 +1287,17 @@
 /* - AMD: */
 #define MSR_IA32_MBA_BW_BASE               0xc0000200
 #define MSR_IA32_SMBA_BW_BASE              0xc0000280
+#define MSR_IA32_PQR_PLZA_ASSOC            0xc00003fc
 #define MSR_IA32_L3_QOS_ABMC_CFG   0xc00003fd
 #define MSR_IA32_L3_QOS_EXT_CFG            0xc00003ff
 #define MSR_IA32_EVT_CFG_BASE              0xc0000400
 

arch/x86/include/asm/msr-index.h line 1300

Quoted 6 lines

arch/x86/include/asm/msr-index.h +6 -0

+/* Lower 32 bits of MSR_IA32_PQR_PLZA_ASSOC */
+#define RMID_EN                            BIT(31)
+/* Upper 32 bits of MSR_IA32_PQR_PLZA_ASSOC */
+#define CLOSID_EN                  BIT(15)
+#define PLZA_EN                            BIT(31)
+

This is unexpected. So far resctrl has only defined the MSR numbers in this file, not the individual fields. This seems a legitimate use of msr-index.h but creates inconsistency with how the fields of the other resctrl registers are defined. This may be ok so I am looking past this for now. Since I am not familiar with this use I am looking at other patterns of this and it seems that the register fields are usually defined right after the register to make this relationship clear and also use more verbose naming to establish this relationship ... I do not think such cryptic names should be used without context in such a global scope. Please compare with how other fields are defined at this scope.

Quoted 13 lines

Quoted 13 lines

arch/x86/include/asm/msr-index.h +1 -0

index 9dc6b610e4e2..623628d3c643 100644
@@ -1287,10 +1287,17 @@
  /* - AMD: */
  #define MSR_IA32_MBA_BW_BASE               0xc0000200
  #define MSR_IA32_SMBA_BW_BASE              0xc0000280
+#define MSR_IA32_PQR_PLZA_ASSOC            0xc00003fc
  #define MSR_IA32_L3_QOS_ABMC_CFG   0xc00003fd
  #define MSR_IA32_L3_QOS_EXT_CFG            0xc00003ff
  #define MSR_IA32_EVT_CFG_BASE              0xc0000400
 

Quoted 15 lines

arch/x86/include/asm/msr-index.h line 1300

Quoted 6 lines

arch/x86/include/asm/msr-index.h +6 -0

+/* Lower 32 bits of MSR_IA32_PQR_PLZA_ASSOC */
+#define RMID_EN                            BIT(31)
+/* Upper 32 bits of MSR_IA32_PQR_PLZA_ASSOC */
+#define CLOSID_EN                  BIT(15)
+#define PLZA_EN                            BIT(31)
+

This is unexpected. So far resctrl has only defined the MSR numbers in this file, not the individual fields. This seems a legitimate use of msr-index.h but creates inconsistency with how the fields of the other resctrl registers are defined. This may be ok so I am looking past this for now. Since I am not familiar with this use I am looking at other patterns of this and it seems that the register fields are usually defined right after the register to make this relationship clear and also use more verbose naming to establish this relationship ... I do not think such cryptic names should be used without context in such a global scope. Please compare with how other fields are defined at this scope.

There's also patches in flight to treat MSRs as a single "u64" and move away from the low level implementation detail that the RDMSR/WRMSR instructions split into upper/lower halves.

All the kernel interfaces are moving to rdmsrq() and wrmsrq() (together with related functions).

So maybe:

#define PQR_PLZA_RMID_EN        BIT_ULL(31)
#define PQR_PLZA_CLOSID_EN      BIT_ULL(47)
#define PQR_PLZA_PLZA_EN        BIT_ULL(63)

[modify with whatever addition prefix characters seem necessary]

Hi Babu,

Quoted 5 lines · Babu Moger

Privilege Level Zero Association (PLZA) is configured per logical processor via MSR_IA32_PQR_PLZA_ASSOC (0xc00003fc). Software must program RMID and CLOSID association fields and their enable bits using the layout defined for the MSR.

Quoted 3 lines

Define MSR_IA32_PQR_PLZA_ASSOC and the RMID_EN, CLOSID_EN, and PLZA_EN bit masks in asm/msr-index.h. Add union msr_pqr_plza_assoc in arch resctrl internal.h

Above paragraph captures what can be seen from the patch. Please check entire series for this since many changelogs in this series verbatim describes the code changes in patch without helping reader understand why those changes are made.

Quoted 18 lines

Signed-off-by Babu Moger <[email protected]>

---

arch/x86/include/asm/msr-index.h +1 -0

index 9dc6b610e4e2..623628d3c643 100644
@@ -1287,10 +1287,17 @@
  /* - AMD: */
  #define MSR_IA32_MBA_BW_BASE		0xc0000200
  #define MSR_IA32_SMBA_BW_BASE		0xc0000280
+#define MSR_IA32_PQR_PLZA_ASSOC		0xc00003fc
  #define MSR_IA32_L3_QOS_ABMC_CFG	0xc00003fd
  #define MSR_IA32_L3_QOS_EXT_CFG		0xc00003ff
  #define MSR_IA32_EVT_CFG_BASE		0xc0000400
 

arch/x86/include/asm/msr-index.h line 1300

Quoted 6 lines

arch/x86/include/asm/msr-index.h +6 -0

+/* Lower 32 bits of MSR_IA32_PQR_PLZA_ASSOC */
+#define RMID_EN				BIT(31)
+/* Upper 32 bits of MSR_IA32_PQR_PLZA_ASSOC */
+#define CLOSID_EN			BIT(15)
+#define PLZA_EN				BIT(31)
+

This is unexpected. So far resctrl has only defined the MSR numbers in this file, not the individual fields. This seems a legitimate use of msr-index.h but creates inconsistency with how the fields of the other resctrl registers are defined. This may be ok so I am looking past this for now. Since I am not familiar with this use I am looking at other patterns of this and it seems that the register fields are usually defined right after the register to make this relationship clear and also use more verbose naming to establish this relationship ... I do not think such cryptic names should be used without context in such a global scope. Please compare with how other fields are defined at this scope.

arch/x86/kernel/cpu/resctrl/internal.h union l3_qos_abmc_cfg { · line 227

Quoted 12 lines

arch/x86/kernel/cpu/resctrl/internal.h +3 -0

index e3cfa0c10e92..1c2f87ffb0ea 100644
@@ -222,6 +222,33 @@ union l3_qos_abmc_cfg {
  	unsigned long full;
  };
 
+/*
+ * PLZA is programmed by writing to MSR_IA32_PQR_PLZA_ASSOC. Bitfield
+ * layout for MSR_IA32_PQR_PLZA_ASSOC (Privilege Level Zero Association).

These comments are valuable to describe how resctrl should interact with this register so it would help to be specific and document any and all constraints.

For example, I seem to remember that all fields except PLZA_EN are required to be identical on all CPUs. Please document that and any other constraints here.

arch/x86/kernel/cpu/resctrl/internal.h union l3_qos_abmc_cfg { · line 229

Quoted 2 lines

arch/x86/kernel/cpu/resctrl/internal.h +2 -0

+ *
+ * @rmid		: The RMID to be configured for PLZA.

What does "to be configured" mean? It seems to imply that when resctrl writes to @rmid then the setting does not take immediate effect but would take effect at some future "configure" time?

arch/x86/kernel/cpu/resctrl/internal.h union l3_qos_abmc_cfg { · line 231

Quoted 2 lines

arch/x86/kernel/cpu/resctrl/internal.h +2 -0

+ * @reserved1		: Reserved.
+ * @rmid_en		: Associate RMID or not.

Please elaborate ... what is RMID associated with? What does "or not" imply? Here it will help to document relationship with MSR_IA32_PQR_ASSOC.

arch/x86/kernel/cpu/resctrl/internal.h union l3_qos_abmc_cfg { · line 234

Quoted 3 lines

arch/x86/kernel/cpu/resctrl/internal.h +3 -0

+ * @closid		: The CLOSID to be configured for PLZA.
+ * @reserved2		: Reserved.
+ * @closid_en		: Associate CLOSID or not.

Same comments as for RMID

arch/x86/kernel/cpu/resctrl/internal.h union l3_qos_abmc_cfg { · line 236

Quoted 2 lines

arch/x86/kernel/cpu/resctrl/internal.h +2 -0

+ * @reserved3		: Reserved.
+ * @plza_en		: Configure PLZA or not.

plza_en implies "enable" but the comment mentions "configure". Considering the other fields are "to be configured" there seems to be relationship but that is not documented at all. For example, if @plza_en is 1 and resctrl modifies @rmid should resctrl write "1" to @plza_en again to "configure" the new RMID?

Please add specific detail to help understand how best to interact with this register.

Hi Reinette,

Quoted 8 lines · Reinette Chatre

Hi Babu,

Quoted 5 lines · Babu Moger

Privilege Level Zero Association (PLZA) is configured per logical processor via MSR_IA32_PQR_PLZA_ASSOC (0xc00003fc). Software must program RMID and CLOSID association fields and their enable bits using the layout defined for the MSR.

Quoted 8 lines

Quoted 3 lines

Define MSR_IA32_PQR_PLZA_ASSOC and the RMID_EN, CLOSID_EN, and PLZA_EN bit masks in asm/msr-index.h. Add union msr_pqr_plza_assoc in arch resctrl internal.h

Above paragraph captures what can be seen from the patch. Please check entire series for this since many changelogs in this series verbatim describes the code changes in patch without helping reader understand why those changes are made.

Sure. Will rewrite the changelog. And will check other patches also.

Quoted 24 lines

Quoted 13 lines

Signed-off-by Babu Moger <[email protected]>

---

arch/x86/include/asm/msr-index.h +0 -0

index 9dc6b610e4e2..623628d3c643 100644
@@ -1287,10 +1287,17 @@
   /* - AMD: */
   #define MSR_IA32_MBA_BW_BASE        0xc0000200
   #define MSR_IA32_SMBA_BW_BASE        0xc0000280

arch/x86/include/asm/msr-index.h line 1299

Quoted 10 lines

arch/x86/include/asm/msr-index.h +7 -0

+#define MSR_IA32_PQR_PLZA_ASSOC        0xc00003fc
   #define MSR_IA32_L3_QOS_ABMC_CFG    0xc00003fd
   #define MSR_IA32_L3_QOS_EXT_CFG        0xc00003ff
   #define MSR_IA32_EVT_CFG_BASE        0xc0000400
+/* Lower 32 bits of MSR_IA32_PQR_PLZA_ASSOC */
+#define RMID_EN                BIT(31)
+/* Upper 32 bits of MSR_IA32_PQR_PLZA_ASSOC */
+#define CLOSID_EN            BIT(15)
+#define PLZA_EN                BIT(31)
+

Quoted 8 lines

This is unexpected. So far resctrl has only defined the MSR numbers in this file, not the individual fields. This seems a legitimate use of msr-index.h but creates inconsistency with how the fields of the other resctrl registers are defined. This may be ok so I am looking past this for now. Since I am not familiar with this use I am looking at other patterns of this and it seems that the register fields are usually defined right after the register to make this relationship clear and also use more verbose naming to establish this relationship ... I do not think such cryptic names should be used without context in such a global scope. Please compare with how other fields are defined at this scope.

Sure. Will use the names tony suggested.
https://lore.kernel.org/lkml/ SJ1PR11MB6083C069F99FAB8A0BEB8518FC182@SJ1PR11MB6083.namprd11.prod.outlook.com/

Also will moving the register "MSR_IA32_PQR_PLZA_ASSOC" together with BIT definition. It will break the sorting order. Hope that is not a problem.

Privilege-Level Zero Association (PLZA) allows the user to specify a CLOSID

and/or RMID associated with execution in Privilege-Level Zero. Introduce a generic enumeration so that architecture and generic code can agree on the available policies.

Introduce enum resctrl_kernel_modes with the following values:

- INHERIT_CTRL_AND_MON: kernel and user tasks share the same CLOSID and RMID. This is the default and matches today's resctrl behaviour.

- GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU: a CLOSID is assigned for kernel work while the RMID used for monitoring is inherited from the running user task. The default scope is all online CPUs and may be narrowed to a subset via the resctrl group interface. A CTRL_MON group can be bound to this mode.

- GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU: both CLOSID and RMID are assigned to kernel work. The default scope is all online CPUs and may be narrowed per CPU via the resctrl group interface. A CTRL_MON group can be bound to this mode.

- RESCTRL_KMODE_LAST: highest enumerator naming a policy mode.

- RESCTRL_NUM_KERNEL_MODES: number of policy modes; use this to size static tables indexed by mode.

Also add struct resctrl_kmode_cfg (the snapshot architecture code returns) in include/linux/resctrl_types.h, and declare resctrl_arch_get_kmode_support() in include/linux/resctrl.h so architecture code can advertise the supported modes.

Signed-off-by Babu Moger <[email protected]>

---
v3: Removed resctrl_kmode definition.
Changed the kernel mode definitions to enum resctrl_kernel_modes. Used BIT() to set/test the features.
Added details to changelog.

v2: New patch to handle PLZA interfaces with /sys/fs/resctrl/info/ directory.

    https://lore.kernel.org/lkml/[email protected]/
---
 include/linux/resctrl.h       | 13 ++++++++++
 include/linux/resctrl_types.h | 46 +++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+)

include/linux/resctrl.h +0 -0

index 006e57fd7ca5..ce28418df00f 100644

Global-assign modes treat all online CPUs as
+ * in scope by default; a subset of CPUs may be selected by using resctrl
+ * group's interface.
+ *
+ * @INHERIT_CTRL_AND_MON:
+ * User and kernel tasks use the same CLOSID and RMID.

+ * @GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:
+ * A CLOSID may be assigned for kernel work while RMID selection for

+ * monitoring follows the same inheritance rules as for user contexts.
+ * Default scope is all online CPUs: subset of CPUs may be selected by
+ * using resctrl group's interface.
+ * @GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU:
+ * A single resource group (CLOSID and RMID together) may be assigned to

+ * kernel work. Default scope is all online CPUs: subset of CPUs may be
+ * selected by using resctrl group's interface.
+ * @RESCTRL_KMODE_LAST:

+ * Highest enumerator that names a policy mode. Use RESCTRL_NUM_KERNEL_MODES
+ * to size static tables indexed by mode.

+ * @kmode: Hardware- or policy-supported modes: each enumerator from
+ * &enum resctrl_kernel_modes is represented by BIT(mode index).
+ * @kmode_cur: Effective mode(s) in the same BIT(index) form as @kmode.

+ * @k_rdtgrp: Resource group backing global-assign modes when applicable;
+ * initialized to the default group at boot.

Hi Babu,

Quoted 1 line · Babu Moger

Privilege-Level Zero Association (PLZA) allows the user to specify a CLOSID

Subject prefix makes it clear this is a resctrl fs patch so please take care to not mix architecture specific terms with resctrl fs generalized support.

Something that may help here is to consider all resctrl fs changes to be relevant from MPAM perspective. Please do so with all resctrl fs changes in this series.

Quoted 6 lines

and/or RMID associated with execution in Privilege-Level Zero. Introduce a generic enumeration so that architecture and generic code can agree on the available policies.

Introduce enum resctrl_kernel_modes with the following values:

Please make the enum name singular, "resctrl_kernel_modes" -> "resctrl_kernel_mode" Doing so will make its use in code easier to parse.

Quoted 4 lines

- INHERIT_CTRL_AND_MON: kernel and user tasks share the same CLOSID and RMID. This is the default and matches today's resctrl behaviour.

CLOSID and RMID are x86 terms where the meaning is not 1:1 with other architectures. Since this is a new resctrl fs interface it is expected to be usable by all architectures. Making this architecture specific is not appropriate.

These are the modes that are exposed to user space and user space has no insight into CLOSID and RMID (ignoring scenario of debugging). I see no reason for resctrl do dictate CLOSID/RMID assignment as part of these modes but instead what the modes mean should be explained. If it is helpful then any x86 specific details can be added by highlighting it is x86 specific. For example,

"Kernel work inherits the allocation and monitoring from the user space task.
On x86 this means that kernel work shares the same CLOSID and RMID as the user space task."

Quoted 9 lines

- GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU: a CLOSID is assigned for kernel work while the RMID used for monitoring is inherited from the running user task. The default scope is all online CPUs and may be narrowed to a subset via the resctrl group interface. A CTRL_MON group can be bound to this mode.

Is binding a CTRL_MON group optional? Consider, for example:

"A CTRL_MON group is bound to this mode."

Quoted 5 lines

- GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU: both CLOSID and RMID are assigned to kernel work. The default scope is all online CPUs and may be narrowed per CPU via the resctrl group interface. A CTRL_MON group can be bound to this mode.

It should be possible to bind a MON group also, no?

Quoted 6 lines

- RESCTRL_KMODE_LAST: highest enumerator naming a policy mode.

- RESCTRL_NUM_KERNEL_MODES: number of policy modes; use this to size static tables indexed by mode.

The last two can be dropped, this is clear from the patch.

Quoted 6 lines

Also add struct resctrl_kmode_cfg (the snapshot architecture code returns) in include/linux/resctrl_types.h, and declare resctrl_arch_get_kmode_support() in include/linux/resctrl.h so architecture code can advertise the supported modes.

Above mostly just describes what is clear from the patch. Instead this can summarize what the addition does: "Provide callback with which architecture can set the kernel modes supported by it". (not exactly what this patch does though, but more below ...)

Quoted 20 lines

Signed-off-by Babu Moger <[email protected]>

---
v3: Removed resctrl_kmode definition.
Changed the kernel mode definitions to enum resctrl_kernel_modes. Used BIT() to set/test the features.
Added details to changelog.

v2: New patch to handle PLZA interfaces with /sys/fs/resctrl/info/ directory.

     https://lore.kernel.org/lkml/[email protected]/
---
  include/linux/resctrl.h       | 13 ++++++++++
  include/linux/resctrl_types.h | 46 +++++++++++++++++++++++++++++++++++
  2 files changed, 59 insertions(+)

include/linux/resctrl.h +0 -0

index 006e57fd7ca5..ce28418df00f 100644

include/linux/resctrl.h int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable); · line 703

Quoted 5 lines

include/linux/resctrl.h +2 -0

@@ -699,6 +699,19 @@ int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable);
   */
  bool resctrl_arch_get_io_alloc_enabled(struct rdt_resource *r);
 
+/**
+ * resctrl_arch_get_kmode_support() - Advertise kernel-mode capabilities

"Advertise" implies a "broadcast" while the function name is "get" that implies retrieval.

Why does resctrl query the support from the architecture? The typical resctrl initialization involves the architecture setting certain capabilities. This simplifies enabling since it does not require the addition of this feature to be accompanied with an implementation of this call by every architecture.

Instead, resctrl can just initialize the defaults and an architecture can make any adjustments using the optional callback. So, instead of resctrl_arch_get_kmode_support(), why not resctrl_set_kmode_support() that is implemented in resctrl fs and called by architecture?

When considering the x86 implementation of this it seems as though this implementation assumes that all architectures will support inherit_ctrl_and_mon but this is not enforced anywhere. Having any assumptions enforced/verified will help to make this more robust. The fs/arch separation depending on so many architectures "doing the right thing" seems risky.

include/linux/resctrl.h int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable); · line 710

Quoted 9 lines

include/linux/resctrl.h +7 -0

+ * @kcfg:	Architecture ORs BIT() flags into @kcfg->kmode for each supported
+ *		&enum resctrl_kernel_modes value (see &struct resctrl_kmode_cfg).
+ *
+ * Used for optional features (for example PLZA on x86) that can assign CLOSID
+ * and/or RMID to kernel work separately from user tasks.  Generic code compares
+ * @kcfg->kmode with the effective @kcfg->kmode_cur; when a global-assign mode is
+ * active, @kcfg->k_rdtgrp identifies the active &struct rdtgroup. The default mode

Does the architecture need to know these implementation details?

include/linux/resctrl.h int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable); · line 713

Quoted 4 lines

include/linux/resctrl.h +3 -0

+ * is INHERIT_CTRL_AND_MON and group is default group.
+ */
+void resctrl_arch_get_kmode_support(struct resctrl_kmode_cfg *kcfg);

Why does architecture need to know the layout of struct resctrl_kmode_cfg? It only needs

to share the modes it supports and need not be concerned with any of the internals - from what I can tell the hook to program the kernel mode does not use this structure either and this is the only "outside of resctrl fs" usage and it does not seem necessary.

Quoted 5 lines

include/linux/resctrl.h +1 -0

+
  extern unsigned int resctrl_rmid_realloc_threshold;
  extern unsigned int resctrl_rmid_realloc_limit;
 

include/linux/resctrl_types.h

Quoted 4 lines

include/linux/resctrl_types.h +0 -0

index a5f56faa18d2..3aba07764b99 100644

Please keep in mind that resctrl_types.h is reserved for those types that an architecture needs to use in its asm/resctrl.h ... it does not look like any of the types added here qualify.

include/linux/resctrl_types.h enum resctrl_event_id { · line 72

Quoted 7 lines

include/linux/resctrl_types.h +2 -0

@@ -68,4 +68,50 @@ enum resctrl_event_id {
  #define QOS_NUM_L3_MBM_EVENTS	(QOS_L3_MBM_LOCAL_EVENT_ID - QOS_L3_MBM_TOTAL_EVENT_ID + 1)
  #define MBM_STATE_IDX(evt)	((evt) - QOS_L3_MBM_TOTAL_EVENT_ID)
 
+/**
+ * enum resctrl_kernel_modes - Kernel versus user CLOSID/RMID policy

What does "versus user" mean? Can this be dropped?

include/linux/resctrl_types.h enum resctrl_event_id {

Quoted 4 lines

include/linux/resctrl_types.h +3 -0

+ *
+ * Enumeration values are contiguous indices from 0 through
+ * @RESCTRL_KMODE_LAST inclusive.

Above sentence is not necessary.

Quoted 7 lines

Global-assign modes treat all online CPUs as
+ * in scope by default; a subset of CPUs may be selected by using resctrl
+ * group's interface.
+ *
+ * @INHERIT_CTRL_AND_MON:
+ * User and kernel tasks use the same CLOSID and RMID.

Similar comment as earlier. Since this is generic resctrl fs interface it needs to be applicable to all architectures. For example (same suggestion as earlier),
"Kernel work inherits the allocation and monitoring of the user space task.

Quoted 3 lines

+ * @GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:
+ * A CLOSID may be assigned for kernel work while RMID selection for

"may be assigned" - this is not optional, right? How about "A control group is assigned ..."

Quoted 7 lines

+ * monitoring follows the same inheritance rules as for user contexts.
+ * Default scope is all online CPUs: subset of CPUs may be selected by
+ * using resctrl group's interface.
+ * @GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU:
+ * A single resource group (CLOSID and RMID together) may be assigned to

"may be" -> "is" ?

Quoted 3 lines

+ * kernel work. Default scope is all online CPUs: subset of CPUs may be
+ * selected by using resctrl group's interface.
+ * @RESCTRL_KMODE_LAST:

Documenting @RESCTRL_KMODE_LAST is not necessary.

Quoted 2 lines

+ * Highest enumerator that names a policy mode. Use RESCTRL_NUM_KERNEL_MODES
+ * to size static tables indexed by mode.

No need to document this.

include/linux/resctrl_types.h enum resctrl_event_id { · line 104

Quoted 13 lines

+ */

include/linux/resctrl_types.h +11 -0

+enum resctrl_kernel_modes {
+	INHERIT_CTRL_AND_MON,
+	GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU,
+	GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU,
+	RESCTRL_KMODE_LAST = GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU,
+};
+
+#define RESCTRL_NUM_KERNEL_MODES (RESCTRL_KMODE_LAST + 1)
+
+/**
+ * struct resctrl_kmode_cfg - Kernel-mode policy snapshot from architecture

Only @kmode is initialized from the architecture. The rest is managed by resctrl fs. I do not see why architecture needs to know the structure details.

Quoted 4 lines

+ * @kmode: Hardware- or policy-supported modes: each enumerator from
+ * &enum resctrl_kernel_modes is represented by BIT(mode index).
+ * @kmode_cur: Effective mode(s) in the same BIT(index) form as @kmode.

"mode(s)" ... this is plural implying more than one mode can be active at a time?

Should this not be just one mode and can thus have type "enum resctrl_kernel_mode" to make this obvious?

Quoted 3 lines

+ * @k_rdtgrp: Resource group backing global-assign modes when applicable;
+ * initialized to the default group at boot.

Why is this initialized to default group at boot? I believe inherit_ctrl_and_mon is the default mode and it does not have a group so should this not be NULL by default?

include/linux/resctrl_types.h enum resctrl_event_id { · line 114

Quoted 6 lines

+ */

include/linux/resctrl_types.h +4 -0

+struct resctrl_kmode_cfg {
+	u32 kmode;
+	u32 kmode_cur;
+	struct rdtgroup *k_rdtgrp;

Please align struct members in tabular fashion.

Not specific to this patch: After so many contributions to resctrl I am very surprised how this series does not respect Documentation/process/maintainer-tip.rst in many ways. For example, later patches at some point just stops writing changelogs in imperative tone and just documents what the code does, patches document locking requirements instead of using code like lockdep_assert_held(), variables are not declared in reverse fir, changelogs refer to other patches in series. Following Documentation/process/maintainer-tip.rst should be very familiar by now.

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 162

Quoted 6 lines · Babu Moger

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +6 -0

+void resctrl_arch_configure_kmode(cpumask_var_t cpu_mask, u32 closid, u32 rmid, bool enable)
+{
+	union msr_pqr_plza_assoc plza = { 0 };
+
+	plza.split.rmid = rmid;
+	plza.split.rmid_en = 1;

Shouldn't there be a parameter for the value of rmid_en?

/sys/fs/resctrl/info/kernel_mode

Hi Tony,

Quoted 9 lines · Tony

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 162

Quoted 6 lines · Babu Moger

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +6 -0

+void resctrl_arch_configure_kmode(cpumask_var_t cpu_mask, u32 closid, u32 rmid, bool enable)
+{
+	union msr_pqr_plza_assoc plza = { 0 };
+
+	plza.split.rmid = rmid;
+	plza.split.rmid_en = 1;

Shouldn't there be a parameter for the value of rmid_en?

I realized that behavior is not required—it was actually due to a mistake in my v2 series implementation.

Below are the relevant definitions:

GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:
The CLOSID is applied to kernel work, while the RMID used for monitoring is inherited from the currently running user task.
No separate monitoring group is assigned for kernel work, so kernel execution naturally inherits the user-space RMID.

GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU:
Both CLOSID and RMID are explicitly assigned to kernel work. This allows assigning a dedicated monitoring group for kernel execution and therefore requires a separate RMID.

Example: For GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:

# mount -t resctrl resctrl /sys/fs/resctrl

# cat /sys/fs/resctrl/info/kernel_mode
[inherit_ctrl_and_mon:group=//]
global_assign_ctrl_inherit_mon_per_cpu:group=none
global_assign_ctrl_assign_mon_per_cpu:group=none

# mkdir /sys/fs/resctrl/ctrl1   (PQR_ASSOC closid=1 rmid=1)

This configures all the CPU threads to use closid=1 and rmid=1 for both allocation and monitoring across user and kernel modes.

# echo "global_assign_ctrl_inherit_mon_per_cpu:group=ctrl1//" \

Quoted 1 line

/sys/fs/resctrl/info/kernel_mode

# cat /sys/fs/resctrl/info/kernel_mode
inherit_ctrl_and_mon:group=none
[global_assign_ctrl_inherit_mon_per_cpu:group=ctrl1//]
global_assign_ctrl_assign_mon_per_cpu:group=none

This overrides the previous configuration, and PQR_PLZA_ASSOC is written.

Possible options:

1. (closid=1, rmid_en=0, rmid=1)
Here, hardware uses closid=1 for kernel work, but RMID tracking is disabled for kernel mode.

As a result, reading RMID 1 reports only user-mode activity This contradicts the definition of this mode, since kernel work is expected to inherit the user RMID for monitoring.

2. (closid=1, rmid_en=1, rmid=1)
In this case, RMID tracking is enabled for both user and kernel modes.

Reading RMID 1 reports combined user + kernel activity This aligns with the expected inherit_monitoring behavior

The preferred approach is to separate kernel monitoring by assigning it a dedicated monitoring group and updating PQR_PLZA_ASSOC to use a different RMID (e.g., closid=1, rmid_en=1, rmid=2). This is exactly the behavior implemented by GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU.

Thanks
Babu

Quoted 71 lines · Babu Moger

Hi Tony,

Quoted 9 lines · Tony

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 162

Quoted 6 lines · Babu Moger

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +6 -0

+void resctrl_arch_configure_kmode(cpumask_var_t cpu_mask, u32 closid, u32 rmid, bool enable)
+{
+	union msr_pqr_plza_assoc plza = { 0 };
+
+	plza.split.rmid = rmid;
+	plza.split.rmid_en = 1;

Shouldn't there be a parameter for the value of rmid_en?

I realized that behavior is not required—it was actually due to a mistake in my v2 series implementation.

Below are the relevant definitions:

GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:
The CLOSID is applied to kernel work, while the RMID used for monitoring is inherited from the currently running user task.
No separate monitoring group is assigned for kernel work, so kernel execution naturally inherits the user-space RMID.

GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU:
Both CLOSID and RMID are explicitly assigned to kernel work. This allows assigning a dedicated monitoring group for kernel execution and therefore requires a separate RMID.

Example: For GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:

# mount -t resctrl resctrl /sys/fs/resctrl

# cat /sys/fs/resctrl/info/kernel_mode
[inherit_ctrl_and_mon:group=//]
global_assign_ctrl_inherit_mon_per_cpu:group=none
global_assign_ctrl_assign_mon_per_cpu:group=none

# mkdir /sys/fs/resctrl/ctrl1   (PQR_ASSOC closid=1 rmid=1)

This configures all the CPU threads to use closid=1 and rmid=1 for both allocation and monitoring across user and kernel modes.

# echo "global_assign_ctrl_inherit_mon_per_cpu:group=ctrl1//" \

Quoted 1 line

/sys/fs/resctrl/info/kernel_mode

# cat /sys/fs/resctrl/info/kernel_mode
inherit_ctrl_and_mon:group=none
[global_assign_ctrl_inherit_mon_per_cpu:group=ctrl1//]
global_assign_ctrl_assign_mon_per_cpu:group=none

This overrides the previous configuration, and PQR_PLZA_ASSOC is written.

Possible options:

1. (closid=1, rmid_en=0, rmid=1)
Here, hardware uses closid=1 for kernel work, but RMID tracking is disabled for kernel mode.

As a result, reading RMID 1 reports only user-mode activity This contradicts the definition of this mode, since kernel work is expected to inherit the user RMID for monitoring.

2. (closid=1, rmid_en=1, rmid=1)
In this case, RMID tracking is enabled for both user and kernel modes.

Quoted 8 lines

Reading RMID 1 reports combined user + kernel activity This aligns with the expected inherit_monitoring behavior

The preferred approach is to separate kernel monitoring by assigning it a dedicated monitoring group and updating PQR_PLZA_ASSOC to use a different RMID (e.g., closid=1, rmid_en=1, rmid=2). This is exactly the behavior implemented by GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU.

So maybe I'm just confused by the name "global_assign_ctrl_inherit_mon_per_cpu"

That sounds like "Use the CLOSID from PLZA, but keep the RMID from legacy PQR_ASSOC.

So:

# mkdir ctrl1 # maybe gets CLOSID=1, RMID=1
# echo global_assign_ctrl_inherit_mon_per_cpu:group=ctrl1//" > info/kernel_mode

# mkdir ctrl2 # maybe gets CLOSID=2, RMID=2
# echo $$ > ctrl2/tasks

My shell, and all children run with CLOSID=2 and RMID=2 from ctrl2. But when they do system calls, take page faults or there is an interrupt I'd expect the code in the kernel to run with the CLOSID=1, while inheriting RMID=2.

To make that happen, I thing the PLZA MSR should have rmid_en = 0. But the only code I see that sets this always sets rmid_en=1.

Quoted 3 lines · Tony

So maybe I'm just confused by the name
"global_assign_ctrl_inherit_mon_per_cpu"

Quoted 5 lines

That sounds like "Use the CLOSID from PLZA, but keep the RMID from legacy PQR_ASSOC.

To make that happen, I thing the PLZA MSR should have rmid_en = 0. But the only code I see that sets this always sets rmid_en=1.

Setting rmid_en = 0 in [1] disables counting of kernel usage for RMID 1 (from ctrl1).

The key difference between the two modes is:

In one mode, user and kernel usage are counted together.
In the other mode, kernel usage is counted separately from user usage.

Quoted 4 lines · Babu

Quoted 3 lines · Tony

So maybe I'm just confused by the name
"global_assign_ctrl_inherit_mon_per_cpu"

Quoted 8 lines

Quoted 5 lines

That sounds like "Use the CLOSID from PLZA, but keep the RMID from legacy PQR_ASSOC.

To make that happen, I thing the PLZA MSR should have rmid_en = 0. But the only code I see that sets this always sets rmid_en=1.

Setting rmid_en = 0 in [1] disables counting of kernel usage for RMID 1 (from ctrl1).

I've been reviewing these patches and went back to the AMD hardware manual (Publication #69193, Rev 1.00, March 2026) to understand the RMID_EN semantics.

The spec defines RMID_EN (bit 31 of PQR_PLZA_ASSOC, MSR C000_03FCh):

"RMID_EN (PLZA Resource Monitoring Identifier Association Enable)
- bit 31. When set and PLZA_EN is set, the Resource Monitoring Identifier (RMID) for this logical processor executing at CPL=0 is specified in the RMID field instead of PQR_ASSOC[RMID]."

Reading "instead of PQR_ASSOC[RMID]", my understanding is that when RMID_EN is clear, the hardware falls back to PQR_ASSOC[RMID] - the user process's RMID - rather than disabling monitoring entirely. If that reading is correct, RMID_EN would be a source selector between PLZA and PQR_ASSOC, not an on/off switch for counting.

Babu, could you confirm whether that is the intended hardware behavior?

Quoted 5 lines

The key difference between the two modes is:

In one mode, user and kernel usage are counted together.
In the other mode, kernel usage is counted separately from user usage.

If RMID_EN=0 does fall back to PQR_ASSOC[RMID], then the "counted together" behavior only holds when the user process happens to be in the same group as the PLZA-bound group. Taking Tony's example:

   # mkdir ctrl1   # CLOSID=1, RMID=1, bound to inherit_mon via PLZA
   # mkdir ctrl2   # CLOSID=2, RMID=2
   # echo $$ > ctrl2/tasks

With rmid_en=1 (current code): when the shell (in ctrl2, PQR_ASSOC RMID=2) enters kernel mode, kernel activity is counted under PLZA RMID=1. The user process's RMID is NOT inherited.

With rmid_en=0: kernel mode would fall back to PQR_ASSOC RMID=2, correctly inheriting the monitoring identity of the current user process - which seems to be what "inherit_mon" intends.

If this reading is right, Tony's suggestion of adding a parameter to control rmid_en based on the mode would be the right fix:

void resctrl_arch_configure_kmode(const struct cpumask *cpu_mask,
u32 closid, u32 rmid, bool assign_rmid, bool enable)

where assign_rmid=true sets RMID_EN=1 (assign_mon) and assign_rmid=false sets RMID_EN=0 (inherit_mon).

---

Separately, I have a question about the group type constraint for global_assign_ctrl_assign_mon_per_cpu (assign_mon mode).

In patch 08/12 ("fs/resctrl: Make info/kernel_mode writable and identify the bound group"), resctrl_kernel_mode_write() enforces that assign_mon must bind to an RDTMON_GROUP:

   if (kmode == BIT(GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU) &&
       rdtgrp->type != RDTMON_GROUP) {

This forces the user to create a ctrl group plus a monitor sub-group. But since the kernel-mode group is dedicated to kernel work and no user tasks are assigned to it, the ctrl group's own RMID (allocated via alloc_rmid() at mkdir time) should be clean and usable. Requiring an extra monitor group seems to waste a scarce RMID.

Would it make sense to relax this constraint so that assign_mon also accepts an RDTCTRL_GROUP? The path infrastructure (rdtgroup_by_kmode_path and resctrl_kernel_mode_show) already handles the "<ctrl>//" form, so only the check above would need to change:

   mkdir /sys/fs/resctrl/kernel_ctrl
   echo "global_assign_ctrl_assign_mon_per_cpu:group=kernel_ctrl//" \
        > info/kernel_mode

Hi Tony,

Quoted 18 lines · Tony

Quoted 17 lines · Babu Moger

Hi Tony,

Quoted 9 lines · Tony

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 162

Quoted 6 lines · Babu Moger

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +6 -0

+void resctrl_arch_configure_kmode(cpumask_var_t cpu_mask, u32 closid, u32 rmid, bool enable)
+{
+  union msr_pqr_plza_assoc plza = { 0 };
+
+  plza.split.rmid = rmid;
+  plza.split.rmid_en = 1;

Shouldn't there be a parameter for the value of rmid_en?

I realized that behavior is not required—it was actually due to a mistake in my v2 series implementation.

Quoted 63 lines

Quoted 54 lines

Below are the relevant definitions:

GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:
The CLOSID is applied to kernel work, while the RMID used for monitoring is inherited from the currently running user task.
No separate monitoring group is assigned for kernel work, so kernel execution naturally inherits the user-space RMID.

GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU:
Both CLOSID and RMID are explicitly assigned to kernel work. This allows assigning a dedicated monitoring group for kernel execution and therefore requires a separate RMID.

Example: For GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:

# mount -t resctrl resctrl /sys/fs/resctrl

# cat /sys/fs/resctrl/info/kernel_mode
[inherit_ctrl_and_mon:group=//]
global_assign_ctrl_inherit_mon_per_cpu:group=none
global_assign_ctrl_assign_mon_per_cpu:group=none

# mkdir /sys/fs/resctrl/ctrl1   (PQR_ASSOC closid=1 rmid=1)

This configures all the CPU threads to use closid=1 and rmid=1 for both allocation and monitoring across user and kernel modes.

# echo "global_assign_ctrl_inherit_mon_per_cpu:group=ctrl1//" \

Quoted 1 line

/sys/fs/resctrl/info/kernel_mode

# cat /sys/fs/resctrl/info/kernel_mode
inherit_ctrl_and_mon:group=none
[global_assign_ctrl_inherit_mon_per_cpu:group=ctrl1//]
global_assign_ctrl_assign_mon_per_cpu:group=none

This overrides the previous configuration, and PQR_PLZA_ASSOC is written.

Possible options:

1. (closid=1, rmid_en=0, rmid=1)
Here, hardware uses closid=1 for kernel work, but RMID tracking is disabled for kernel mode.

As a result, reading RMID 1 reports only user-mode activity This contradicts the definition of this mode, since kernel work is expected to inherit the user RMID for monitoring.

2. (closid=1, rmid_en=1, rmid=1)
In this case, RMID tracking is enabled for both user and kernel modes.

Quoted 8 lines

Reading RMID 1 reports combined user + kernel activity This aligns with the expected inherit_monitoring behavior

The preferred approach is to separate kernel monitoring by assigning it a dedicated monitoring group and updating PQR_PLZA_ASSOC to use a different RMID (e.g., closid=1, rmid_en=1, rmid=2). This is exactly the behavior implemented by GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU.

Quoted 4 lines

So maybe I'm just confused by the name "global_assign_ctrl_inherit_mon_per_cpu"

That sounds like "Use the CLOSID from PLZA, but keep the RMID from legacy PQR_ASSOC.

Yes. That is correct. We need to work on naming this correctly.

Quoted 5 lines

So:

# mkdir ctrl1 # maybe gets CLOSID=1, RMID=1
# echo global_assign_ctrl_inherit_mon_per_cpu:group=ctrl1//" > info/kernel_mode

This makes kernel mode run with CLOSID 1 and RMID 1(Use the same RMID as the user mode). [1]

Quoted 7 lines

# mkdir ctrl2 # maybe gets CLOSID=2, RMID=2
# echo $$ > ctrl2/tasks

My shell, and all children run with CLOSID=2 and RMID=2 from ctrl2. But when they do system calls, take page faults or there is an interrupt I'd expect the code in the kernel to run with the CLOSID=1, while inheriting RMID=2.

ctrl2 is not a PLZA group. So, RMID 2 is not connected to PLZA.

Quoted 3 lines

To make that happen, I thing the PLZA MSR should have rmid_en = 0. But the only code I see that sets this always sets rmid_en=1.

Setting rmid_en = 0 in [1] disables counting of kernel usage for RMID 1 (from ctrl1).

The key difference between the two modes is:

In one mode, user and kernel usage are counted together.
In the other mode, kernel usage is counted separately from user usage.

Please feel free to continue the discussion if anything is still unclear.

Thanks,
Babu

Hi Babu,

Quoted 20 lines · Babu

Hi Tony,

Quoted 16 lines · Tony

Quoted 15 lines · Babu Moger

Hi Tony,

Quoted 9 lines · Tony

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 162

Quoted 6 lines · Babu Moger

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +6 -0

+void resctrl_arch_configure_kmode(cpumask_var_t cpu_mask, u32 closid, u32 rmid, bool enable)
+{
+  union msr_pqr_plza_assoc plza = { 0 };
+
+  plza.split.rmid = rmid;
+  plza.split.rmid_en = 1;

Shouldn't there be a parameter for the value of rmid_en?

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

I realized that behavior is not required—it was actually due to a mistake in my v2 series implementation.

Really? This is in fact the only behavior we wanted:

https://lore.kernel.org/lkml/CABPqkBSq=cgn-am4qorA_VN0vsbpbfDePSi7gubicpROB1=djw@mail.gmail.com/

AMD Privilege Level Zero Association (PLZA) exposes kernel CLOSID/RMID association through MSR_IA32_PQR_PLZA_ASSOC. Generic resctrl already tracks supported and effective kernel-mode policy in struct resctrl_kmode_cfg, but the architecture layer needs a callable entry point that can push those values into per-CPU hardware on a chosen CPU mask.

Declare resctrl_arch_configure_kmode() in linux/resctrl.h with kernel-doc. Implement it on x86: add an SMP callback that writes MSR_IA32_PQR_PLZA_ASSOC on each targeted CPU, and use on_each_cpu_mask() for the broadcast.

The hook is unused in this patch; later patches in the series wire it into

generic resctrl when an effective kernel-mode policy is selected or a CPU mask changes.

Signed-off-by Babu Moger <[email protected]>

---

---
 arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 35 +++++++++++++++++++++++
 include/linux/resctrl.h                   | 10 +++++++
 2 files changed, 45 insertions(+)

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +1 -0

index b20e705606b8..68f1cf503904 100644
@@ -131,3 +131,38 @@ int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable)
 
 	return 0;
 }
+

include/linux/resctrl.h +0 -0

index ce28418df00f..570918e57e24 100644

Hi Babu,

Quoted 10 lines · Babu Moger

AMD Privilege Level Zero Association (PLZA) exposes kernel CLOSID/RMID association through MSR_IA32_PQR_PLZA_ASSOC. Generic resctrl already tracks supported and effective kernel-mode policy in struct resctrl_kmode_cfg, but the architecture layer needs a callable entry point that can push those values into per-CPU hardware on a chosen CPU mask.

Declare resctrl_arch_configure_kmode() in linux/resctrl.h with kernel-doc. Implement it on x86: add an SMP callback that writes MSR_IA32_PQR_PLZA_ASSOC on each targeted CPU, and use on_each_cpu_mask() for the broadcast.

Above is clear from the patch. Please start with focus on why this patch is needed.

Quoted 2 lines

The hook is unused in this patch; later patches in the series wire it into

Similar to previous work: write changelog in imperative tone and do not refer to patches in series but instead let each patch stand on its own.

Quoted 28 lines

generic resctrl when an effective kernel-mode policy is selected or a CPU mask changes.

Signed-off-by Babu Moger <[email protected]>

---

---
  arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 35 +++++++++++++++++++++++
  include/linux/resctrl.h                   | 10 +++++++
  2 files changed, 45 insertions(+)

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +7 -0

index b20e705606b8..68f1cf503904 100644
@@ -131,3 +131,38 @@ int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable)
 
  	return 0;
  }
+
+/*
+ * SMP call-function callback: each CPU writes its own MSR_IA32_PQR_PLZA_ASSOC
+ * (AMD PLZA).  Invoked via on_each_cpu_mask() with wait=1 so the on-stack
+ * union pointed at by @arg is safe.
+ */
+static void resctrl_kmode_set_one_amd(void *arg)

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 144

Quoted 4 lines

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +4 -0

+{
+	union msr_pqr_plza_assoc *plza = arg;
+
+	wrmsrl(MSR_IA32_PQR_PLZA_ASSOC, plza->full);

fyi ...
commit 2232959db26d ("x86/msr: Switch wrmsrl() users to wrmsrq()") commit b5884070f9da ("x86/msr: Remove wrmsrl()")

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 149

Quoted 5 lines

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +5 -0

+}
+
+/**
+ * resctrl_arch_configure_kmode() - x86/AMD: program PLZA MSR on a CPU subset
+ * @cpu_mask:	CPUs to receive the update (see on_each_cpu_mask() for online subset).

Why is the caveat added? Will resctrl ever provide offline CPUs in the mask?

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 152

Quoted 4 lines

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +3 -0

+ * @closid:	CLOSID field written into the MSR with CLOSID_EN set.
+ * @rmid:	RMID field written into the MSR with RMID_EN set.
+ * @enable:	Value for the PLZA_EN split field.

Please describe the meaning of the fields instead the mechanics of the code that are obvious.

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 155

Quoted 4 lines

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +3 -0

+ *
+ * Context: Do not call with IRQs off or from IRQ context except as allowed for
+ * on_each_cpu_mask(); see kernel/smp.c.

Why is this context caveat needed?

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 157

Quoted 3 lines

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +2 -0

+ */
+void resctrl_arch_configure_kmode(cpumask_var_t cpu_mask, u32 closid, u32 rmid, bool enable)

Please replace "cpumask_var_t cpu_mask" with "const struct cpumask *cpu_mask".

arch/x86/kernel/cpu/resctrl/ctrlmondata.c int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable) · line 168

Quoted 12 lines

arch/x86/kernel/cpu/resctrl/ctrlmondata.c +11 -0

+{
+	union msr_pqr_plza_assoc plza = { 0 };
+
+	plza.split.rmid = rmid;
+	plza.split.rmid_en = 1;
+	plza.split.closid = closid;
+	plza.split.closid_en = 1;
+	plza.split.plza_en = enable;
+
+	on_each_cpu_mask(cpu_mask, resctrl_kmode_set_one_amd, &plza, 1);
+}

function self has been discussed already

Quoted 8 lines

include/linux/resctrl.h +0 -0

index ce28418df00f..570918e57e24 100644
@@ -712,6 +712,16 @@ bool resctrl_arch_get_io_alloc_enabled(struct rdt_resource *r);
   */
  void resctrl_arch_get_kmode_support(struct resctrl_kmode_cfg *kcfg);
 

include/linux/resctrl.h bool resctrl_arch_get_io_alloc_enabled(struct rdt_resource *r); · line 720

Quoted 6 lines

include/linux/resctrl.h +6 -0

+/**
+ * resctrl_arch_configure_kmode() - Program MSR_IA32_PQR_PLZA_ASSOC on CPUs in @cpu_mask
+ * @cpu_mask:	Target CPUs; on_each_cpu_mask() applies the callback on the online subset.
+ * @closid:	CLOSID written to the MSR with CLOSID_EN set.
+ * @rmid:	RMID written to the MSR with RMID_EN set.
+ * @enable:	PLZA_EN field value for this update.

This is a resctrl fs API - please replace all the AMD architecture specific implementation details with what the parameters actually mean/represent.

Resctrl subsystem tracks which kernel-mode CLOSID/RMID policies the platform can offer via struct resctrl_kmode_cfg and resctrl_arch_get_kmode_support(). AMD PLZA (Privilege Level Zero Association) is the x86 feature that allows kernel traffic to use an assigned CLOSID alone or CLOSID and RMID together.

Report the available kernel-modes when x86 PLZA is enabled.

Signed-off-by Babu Moger <[email protected]>

---
v3: New patch to report all the supported kernel mode by arch.

---
 arch/x86/kernel/cpu/resctrl/core.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

arch/x86/kernel/cpu/resctrl/core.c +0 -0

index 4a8717157e3e..699d8bb82875 100644

arch/x86/kernel/cpu/resctrl/core.c +5 -0

+ *
+ * When PLZA is present (CPUID X86_FEATURE_PLZA), the kernel may assign a CLOSID
+ * for kernel work alone or assign CLOSID and RMID together.  Advertise both
+ * assign-style modes in @kcfg->kmode using &enum resctrl_kernel_modes indices.
+ */

Hi Babu,

Quoted 23 lines · Babu Moger

Resctrl subsystem tracks which kernel-mode CLOSID/RMID policies the platform can offer via struct resctrl_kmode_cfg and resctrl_arch_get_kmode_support(). AMD PLZA (Privilege Level Zero Association) is the x86 feature that allows kernel traffic to use an assigned CLOSID alone or CLOSID and RMID together.

Report the available kernel-modes when x86 PLZA is enabled.

Signed-off-by Babu Moger <[email protected]>

---
v3: New patch to report all the supported kernel mode by arch.

---
  arch/x86/kernel/cpu/resctrl/core.c | 15 +++++++++++++++
  1 file changed, 15 insertions(+)

arch/x86/kernel/cpu/resctrl/core.c +0 -0

index 4a8717157e3e..699d8bb82875 100644
@@ -894,6 +894,21 @@ bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt)
  	}
  }
 

arch/x86/kernel/cpu/resctrl/core.c bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt) · line 899

Quoted 3 lines

arch/x86/kernel/cpu/resctrl/core.c +3 -0

+/**
+ * resctrl_arch_get_kmode_support() - x86: record which kernel-mode policies hardware supports
+ * @kcfg:	Cumulative snapshot; OR bits into @kcfg->kmode (see &struct resctrl_kmode_cfg).

If this is intended to be a cumulative snapshot this is a very subtle requirement for architectures to "do the right thing" here. To make this more robust I think it will be simpler if resctrl fs boots with resctrl_kcfg initialized to expected defaults. Instead of this callback resctrl can add resctrl_set_kmode_support(u32 kmodes) that the architecture *may* use to further initialize the kmodes supported by it. This function is implemented by resctrl fs, instead of architecture, and it can fail if architecture does not support INHERIT_CTRL_AND_MON. This will help to keep struct resctrl_kmode_cfg private to resctrl fs while enforcing any assumptions about which modes are required to be supported.

kernel_mode feature needs to add the interface that lets user space choose between INHERIT_CTRL_AND_MON, GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU and GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU. Both the generic resctrl code and the architecture layer need a single shared snapshot of the supported and effective policy plus the resource group that backs the global-assign modes; that snapshot is struct resctrl_kmode_cfg.

Add the file-local resctrl_kcfg and a helper resctrl_kmode_init() that:

- Adds kmode and kmode_cur with BIT(INHERIT_CTRL_AND_MON), the

    universally supported mode and today's behaviour;
  - points k_rdtgrp at rdtgroup_default so global-assign modes have a
    valid backing group from boot;

- calls resctrl_arch_get_kmode_support() so each architecture ORs BIT(<mode>) into kmode for the policies its hardware supports (on x86, AMD PLZA contributes the two global-assign modes).

resctrl_kmode_init() runs from resctrl_init() once the default group

has been set up. No user-visible behaviour changes yet; later patches

expose kmode_cur via sysfs and act on changes.

Signed-off-by Babu Moger <[email protected]>

Hi Babu,

Quoted 6 lines · Babu Moger

kernel_mode feature needs to add the interface that lets user space choose between INHERIT_CTRL_AND_MON, GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU and GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU. Both the generic resctrl code and the architecture layer need a single shared snapshot of the supported and effective policy plus the resource group that backs the global-assign modes; that snapshot is struct resctrl_kmode_cfg.

This does not seem to match implementation since this implementation does not actually share struct resctrl_kmode_cfg as described above. Only resctrl_arch_get_kmode_support() exchanges this struct between fs and arch and as already mentioned that usage looks unnecessary. The other arch/fs touch points use either individual members or their properties (like closid/rmid).

As described in response to previous patch I think this can be simplified while also making it more robust.

Quoted 7 lines

Add the file-local resctrl_kcfg and a helper resctrl_kmode_init() that:

- Adds kmode and kmode_cur with BIT(INHERIT_CTRL_AND_MON), the

     universally supported mode and today's behaviour;
   - points k_rdtgrp at rdtgroup_default so global-assign modes have a
     valid backing group from boot;

If the default mode is INHERIT_CTRL_AND_MON then should the default group not be NULL?

Quoted 6 lines

- calls resctrl_arch_get_kmode_support() so each architecture ORs BIT(<mode>) into kmode for the policies its hardware supports (on x86, AMD PLZA contributes the two global-assign modes).

resctrl_kmode_init() runs from resctrl_init() once the default group

resctrl_kmode_init() can be dropped after changes described in response to previous patch. Apart from no longer being necessary I also find that having the kernel mode fully initialized *before* the hotplug handlers run to be simpler.

Quoted 2 lines

has been set up. No user-visible behaviour changes yet; later patches

(drop "later patches ...")

Quoted 9 lines · Reinette Chatre

Quoted 5 lines · Babu Moger

   - calls resctrl_arch_get_kmode_support() so each architecture ORs BIT(<mode>) into kmode for the policies its hardware supports (on x86, AMD PLZA contributes the two global-assign modes).

resctrl_kmode_init() runs from resctrl_init() once the default group

Quoted 4 lines

resctrl_kmode_init() can be dropped after changes described in response to previous patch. Apart from no longer being necessary I also find that having the kernel mode fully initialized *before* the hotplug handlers run to be simpler.

That means resctrl_set_kmode_support() will be called from the architecture layer, likely from core.c within get_rdt_alloc_resources().

The resctrl_set_kmode_support() handler would need to initialize both the default mode and all supported modes.

Hi Babu,

Quoted 15 lines · Babu Moger

Quoted 13 lines · Reinette Chatre

Quoted 5 lines · Babu Moger

   - calls resctrl_arch_get_kmode_support() so each architecture ORs BIT(<mode>) into kmode for the policies its hardware supports (on x86, AMD PLZA contributes the two global-assign modes).

resctrl_kmode_init() runs from resctrl_init() once the default group

resctrl_kmode_init() can be dropped after changes described in response to previous patch. Apart from no longer being necessary I also find that having the kernel mode fully initialized *before* the hotplug handlers run to be simpler.

Quoted 3 lines

That means resctrl_set_kmode_support() will be called from the architecture layer, likely from core.c within get_rdt_alloc_resources().

The resctrl_set_kmode_support() handler would need to initialize both the default mode and all supported modes.

I see this differently. Since resctrl_set_kmode_support() is optional for an architecture resctrl fs can just statically initialize the defaults. resctrl_set_kmode_support() would expand the defaults to also accommodate what the architecture supports.

There is no user-visible way today to see which kernel-mode CLOSID/RMID policies the running kernel supports, which one is active, or which resctrl group currently owns the kernel CLOSID/RMID.

Add a read-only top-level sysfs file, info/kernel_mode. It emits one line per mode advertised in resctrl_kcfg.kmode, in stable lowercase spelling derived from enum resctrl_kernel_modes, e.g.:

[inherit_ctrl_and_mon:group=//]

global_assign_ctrl_inherit_mon_per_cpu:group=none global_assign_ctrl_assign_mon_per_cpu:group=none

The effective policy (resctrl_kcfg.kmode_cur) is wrapped in square

brackets and its :group= suffix names the resctrl group currently bound to the kernel CLOSID/RMID (resctrl_kcfg.k_rdtgrp), formatted as <ctrl>/<mon>/ with empty components left blank. Inactive modes are reported as :group=none.

rdtgroup_mutex is held while printing, matching other info/ show paths.

Signed-off-by Babu Moger <[email protected]>

---
v3: New patch to handle the changed interface file info/kernel_mode.
Changed the group name to "none" if kmode binding is not done. Reinette suggested "uninitialized". "none" seemed more relevent.

---
 fs/resctrl/rdtgroup.c | 74 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

fs/resctrl/rdtgroup.c +0 -0

index a7bfc74897cc..9cdcfa64c4a2 100644

fs/resctrl/rdtgroup.c +4 -0

+ * ":group=<name>" suffix:
+ *
+ *   - The effective policy (whose BIT matches resctrl_kcfg.kmode_cur) is
+ *     wrapped in square brackets and <name> is the resctrl group that

fs/resctrl/rdtgroup.c +15 -0

+ */
+static int resctrl_kernel_mode_show(struct kernfs_open_file *of,
+				    struct seq_file *seq, void *v)
+{
+	struct rdtgroup *rdtgrp;
+	const char *ctrl, *mon;
+	int i;
+
+	mutex_lock(&rdtgroup_mutex);
+	for (i = 0; i < RESCTRL_NUM_KERNEL_MODES; i++) {
+		if (!(resctrl_kcfg.kmode & BIT(i)))
+			continue;
+
+		if (resctrl_kcfg.kmode_cur != BIT(i)) {
+			seq_printf(seq, "%s:group=none\n",

fs/resctrl/rdtgroup.c +5 -0

+	}
+	mutex_unlock(&rdtgroup_mutex);
+	return 0;
+}
+
 void *rdt_kn_parent_priv(struct kernfs_node *kn)
 {
 	/*

@@ -1891,6 +1958,13 @@ static struct rftype res_common_files[] = {
 		.seq_show	= rdt_last_cmd_status_show,
 		.fflags		= RFTYPE_TOP_INFO,
 	},

Hi Babu,

How should "introspection" as used in subject be interpreted? This just displays the supported and active kernel modes to user space, no?

Quoted 3 lines

There is no user-visible way today to see which kernel-mode CLOSID/RMID policies the running kernel supports, which one is active, or which resctrl group currently owns the kernel CLOSID/RMID.

Why should there be? This is a new feature being added in this series. No need to write this as a bugfix.

Quoted 4 lines

Add a read-only top-level sysfs file, info/kernel_mode. It emits one line per mode advertised in resctrl_kcfg.kmode, in stable lowercase spelling derived from enum resctrl_kernel_modes, e.g.:

All these changelogs feel so strange ... as though they are written by somebody who simultaneously has no and full knowledge of resctrl. These verbatim descriptions of what the code does is not necessary. Please start with why the patch is needed.

Quoted 3 lines

   [inherit_ctrl_and_mon:group=//]

This is unexpected. There should be no group associated with this default mode. This is how I interpreted our previous discussion ending:
https://lore.kernel.org/lkml/[email protected]/

Quoted 5 lines

global_assign_ctrl_inherit_mon_per_cpu:group=none global_assign_ctrl_assign_mon_per_cpu:group=none

The effective policy (resctrl_kcfg.kmode_cur) is wrapped in square

(needs imperative - please check all changelogs)

Quoted 7 lines

brackets and its :group= suffix names the resctrl group currently bound to the kernel CLOSID/RMID (resctrl_kcfg.k_rdtgrp), formatted as <ctrl>/<mon>/ with empty components left blank. Inactive modes are reported as :group=none.

rdtgroup_mutex is held while printing, matching other info/ show paths.

No need to describe details that can be seen from patch.

Quoted 19 lines

Signed-off-by Babu Moger <[email protected]>

---
v3: New patch to handle the changed interface file info/kernel_mode.
Changed the group name to "none" if kmode binding is not done. Reinette suggested "uninitialized". "none" seemed more relevent.

---
  fs/resctrl/rdtgroup.c | 74 +++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 74 insertions(+)

fs/resctrl/rdtgroup.c +0 -0

index a7bfc74897cc..9cdcfa64c4a2 100644
@@ -988,6 +988,73 @@ static int rdt_last_cmd_status_show(struct kernfs_open_file *of,
  	return 0;
  }
 

fs/resctrl/rdtgroup.c static int rdt_last_cmd_status_show(struct kernfs_open_file *of, · line 995

Quoted 5 lines

fs/resctrl/rdtgroup.c +5 -0

+/* Sysfs lines for info/kernel_mode; indexed by &enum resctrl_kernel_modes */
+static const char * const resctrl_mode_str[] = {
+	[INHERIT_CTRL_AND_MON]			= "inherit_ctrl_and_mon",
+	[GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU] = "global_assign_ctrl_inherit_mon_per_cpu",
+	[GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU]	= "global_assign_ctrl_assign_mon_per_cpu",

Please make alignment consistent.

fs/resctrl/rdtgroup.c static int rdt_last_cmd_status_show(struct kernfs_open_file *of, · line 1001

Quoted 6 lines

fs/resctrl/rdtgroup.c +6 -0

+};
+
+static_assert(ARRAY_SIZE(resctrl_mode_str) == RESCTRL_NUM_KERNEL_MODES);
+
+/**
+ * resctrl_kernel_mode_show() - Enumerate supported and effective kernel-mode policies

"Enumerate" -> "Display"?

fs/resctrl/rdtgroup.c static int rdt_last_cmd_status_show(struct kernfs_open_file *of, · line 1007

Quoted 7 lines

fs/resctrl/rdtgroup.c +6 -0

+ * @of: kernfs open file
+ * @seq: output seq_file
+ * @v: unused
+ *
+ * Emits one line per mode advertised in resctrl_kcfg.kmode (each mode is one
+ * BIT(index) per &enum resctrl_kernel_modes).  Every line carries a

Above is clear from the code. Please instead describe what this means.

Quoted 5 lines

fs/resctrl/rdtgroup.c +4 -0

+ * ":group=<name>" suffix:
+ *
+ *   - The effective policy (whose BIT matches resctrl_kcfg.kmode_cur) is
+ *     wrapped in square brackets and <name> is the resctrl group that

fs/resctrl/rdtgroup.c static int rdt_last_cmd_status_show(struct kernfs_open_file *of, · line 1021

Quoted 10 lines

fs/resctrl/rdtgroup.c +10 -0

+ *     currently owns the kernel CLOSID/RMID (resctrl_kcfg.k_rdtgrp),
+ *     formatted as "<ctrl>/<mon>/".  A component is left empty when it
+ *     does not apply: an RDTCTRL_GROUP emits "<ctrl>//", an RDTMON_GROUP
+ *     under the default control group emits "/<mon>/", and an RDTMON_GROUP
+ *     under a named control group emits "<ctrl>/<mon>/".
+ *
+ *   - Other supported but inactive modes are emitted without brackets and
+ *     <name> is reported as "none".
+ *
+ * Context: Called under rdtgroup_mutex like other resctrl sysfs show paths.

This does not look accurate since it is not called with mutex held but instead takes the mutex itself. Also no need to refer to what other code does.

Quoted 21 lines

fs/resctrl/rdtgroup.c +20 -0

+ */
+static int resctrl_kernel_mode_show(struct kernfs_open_file *of,
+				    struct seq_file *seq, void *v)
+{
+	struct rdtgroup *rdtgrp;
+	const char *ctrl, *mon;
+	int i;
+
+	mutex_lock(&rdtgroup_mutex);
+	for (i = 0; i < RESCTRL_NUM_KERNEL_MODES; i++) {
+		if (!(resctrl_kcfg.kmode & BIT(i)))
+			continue;
+
+		if (resctrl_kcfg.kmode_cur != BIT(i)) {
+			seq_printf(seq, "%s:group=none\n",
+				   resctrl_mode_str[i]);
+			continue;
+		}
+
+		rdtgrp = resctrl_kcfg.k_rdtgrp;

fs/resctrl/rdtgroup.c static int rdt_last_cmd_status_show(struct kernfs_open_file *of, · line 1046

Quoted 5 lines

fs/resctrl/rdtgroup.c +5 -0

+		ctrl = "";
+		mon = "";
+		if (rdtgrp->type == RDTMON_GROUP) {
+			if (rdtgrp->mon.parent != &rdtgroup_default)
+				ctrl = rdtgrp->mon.parent->kn->name;

Isn't default group's kn->name is initialized correctly via rdtgroup_setup_root()->kernfs_create_root()->__kernfs_new_node(root, NULL, "", ...) ?

fs/resctrl/rdtgroup.c static int rdt_last_cmd_status_show(struct kernfs_open_file *of, · line 1050

Quoted 5 lines

fs/resctrl/rdtgroup.c +4 -0

+			mon = rdtgrp->kn->name;
+		} else {
+			ctrl = rdtgrp->kn->name;
+		}

Can the names not just be initialized directly from kn->name?

fs/resctrl/rdtgroup.c static int rdt_last_cmd_status_show(struct kernfs_open_file *of, · line 1052

Quoted 4 lines

fs/resctrl/rdtgroup.c +2 -0

+		seq_printf(seq, "[%s:group=%s/%s/]\n",
+			   resctrl_mode_str[i], ctrl, mon);

This is not where I understood our discussion landed. I expected that the display will reflect what can/should be assigned in a mode. For example, mode "inherit_ctrl_and_mon" does not have an associated resource group and should thus not display one,

"global_assign_ctrl_inherit_mon_per_cpu" can only be assigned a control group and should thus not display a monitor group also.

info/kernel_mode lists the kernel-mode CLOSID/RMID policies the kernel

supports and the one currently active, but user space has no way to switch policies or rebind to a different rdtgroup, and the file does not name the group that owns the kernel CLOSID/RMID.

Make info/kernel_mode writable. The format used by both read and write is one line per mode:

inherit_ctrl_and_mon:group=none [global_assign_ctrl_inherit_mon_per_cpu:group=g1//] global_assign_ctrl_assign_mon_per_cpu:group=none

The active mode is wrapped in "[...]" and ":group=<ctrl>/<mon>/" names the bound rdtgroup ("//" for the default control group). Inactive modes report ":group=none". Documented in Documentation/filesystems/resctrl.rst.

The write path strims input, strips the optional "[...]", validates

the mode against resctrl_kcfg.kmode, and resolves the optional ":group=" suffix via the new helper rdtgroup_by_kmode_path(). An omitted suffix or an INHERIT-mode write binds to the default group. On success, rdtgroup_config_kmode_clear() tears down the previous binding and rdtgroup_config_kmode() programs the new one before resctrl_kcfg.k_rdtgrp and resctrl_kcfg.kmode_cur are updated under rdtgroup_mutex. Allocation failures in the helpers are propagated so the write fails atomically.

Add struct rdtgroup fields kmode and kmode_cpu_mask to track the per-group binding.

Signed-off-by Babu Moger <[email protected]>

---
v3: New patch to handle the changed interface file info/kernel_mode.

---
 Documentation/filesystems/resctrl.rst |  51 ++++
 fs/resctrl/internal.h                 |   6 +
 fs/resctrl/rdtgroup.c                 | 375 +++++++++++++++++++++++++-
 3 files changed, 431 insertions(+), 1 deletion(-)

Documentation/filesystems/resctrl.rst +0 -0

index b003bed339fd..89fbf8b4fb2a 100644

fs/resctrl/internal.h +2 -0

  * @plr:			pseudo-locked region
  */
 struct rdtgroup {

@@ -229,6 +233,8 @@ struct rdtgroup {
 	struct mongroup			mon;
 	enum rdtgrp_mode		mode;
 	enum resctrl_event_id		mba_mbps_event;
+	bool				kmode;
+	struct cpumask			kmode_cpu_mask;
 	struct pseudo_lock_region	*plr;
 };
 

fs/resctrl/rdtgroup.c +0 -0

index 9cdcfa64c4a2..5383b4eb23ed 100644

fs/resctrl/rdtgroup.c +66 -0

+
+	/*
+	 * Empty kmode_cpu_mask: enable on every online CPU.  Otherwise enable
+	 * only CPUs in the group mask and explicitly clear on other online CPUs
+	 * so a previously bound group's enable bits don't linger.
+	 */
+	if (!need_disable) {
+		cpumask_copy(enable_mask, cpu_online_mask);
+	} else {
+		cpumask_copy(enable_mask, &rdtgrp->kmode_cpu_mask);
+		cpumask_andnot(disable_mask, cpu_online_mask, &rdtgrp->kmode_cpu_mask);
+	}
+
+	if (!cpumask_empty(enable_mask))
+		resctrl_arch_configure_kmode(enable_mask, closid, rmid, true);
+
+	if (need_disable && !cpumask_empty(disable_mask))
+		resctrl_arch_configure_kmode(disable_mask, closid, rmid, false);
+
+	rdtgrp->kmode = true;
+
+	free_cpumask_var(enable_mask);
+	if (need_disable)
+		free_cpumask_var(disable_mask);
+
+	return 0;
+}
+
+/**
+ * rdtgroup_config_kmode_clear() - Tear down the kernel-mode binding on @rdtgrp
+ * @rdtgrp:	Resctrl group whose kernel-mode binding is being released.
+ *		May be %NULL when no group is currently bound, in which case
+ *		this is a no-op.
+ * @kmode:	Kernel-mode policy currently active on @rdtgrp, as a
+ *		BIT(&enum resctrl_kernel_modes) value.  When this is
+ *		BIT(INHERIT_CTRL_AND_MON) the hardware tear-down is skipped
+ *		because no MSR was previously programmed.
+ *
+ * Disables the kernel-mode binding on the CPUs @rdtgrp covers (its
+ * @kmode_cpu_mask, or all online CPUs when that mask is empty) and resets
+ * the per-group bookkeeping (@kmode and @kmode_cpu_mask).  This is the
+ * disable counterpart of rdtgroup_config_kmode() and exists so that a write
+ * that transitions the active mode to BIT(INHERIT_CTRL_AND_MON) -- which
+ * skips rdtgroup_config_kmode() entirely -- still tears down the previously
+ * bound group instead of leaving stale enable bits behind.
+ *
+ * On allocation failure the function returns -ENOMEM and leaves both the
+ * hardware state and @rdtgrp's bookkeeping unchanged so the caller can fail
+ * the operation atomically and last_cmd_status reflects reality.
+ *
+ * Context: Caller must hold rdtgroup_mutex.
+ *
+ * Return: 0 on success (including the @rdtgrp == %NULL and INHERIT cases),
+ * -ENOMEM if cpumask allocation fails.
+ */
+static int rdtgroup_config_kmode_clear(struct rdtgroup *rdtgrp, int kmode)
+{
+	cpumask_var_t disable_mask;
+	u32 closid, rmid;
+
+	if (!rdtgrp)
+		return 0;
+
+	if (kmode == BIT(INHERIT_CTRL_AND_MON))
+		goto out_clear;
+

fs/resctrl/rdtgroup.c +12 -0

+
+	resctrl_arch_configure_kmode(disable_mask, closid, rmid, false);
+	free_cpumask_var(disable_mask);
+
+out_clear:
+	cpumask_clear(&rdtgrp->kmode_cpu_mask);
+	rdtgrp->kmode = false;
+	return 0;
+}
+
+/**
+ * rdtgroup_by_kmode_path() - Resolve a "<ctrl>/<mon>/" path to an rdtgroup

fs/resctrl/rdtgroup.c +84 -0

+ *
+ * Return: Pointer to the matching rdtgroup, &rdtgroup_default when both
+ * names are empty (the show form "//"), or NULL if no such group exists.
+ */
+static struct rdtgroup *rdtgroup_by_kmode_path(const char *ctrl_name,
+					       const char *mon_name)
+{
+	struct rdtgroup *rdtg, *parent = NULL, *crg;
+
+	/* Show emits "//" for the default control group; round-trip it here. */
+	if (!*ctrl_name && !*mon_name)
+		return &rdtgroup_default;
+
+	/* Control-group-only form: "<ctrl>//". */
+	if (!*mon_name) {
+		list_for_each_entry(rdtg, &rdt_all_groups, rdtgroup_list) {
+			if (rdtg->type != RDTCTRL_GROUP)
+				continue;
+			if (!strcmp(rdt_kn_name(rdtg->kn), ctrl_name))
+				return rdtg;
+		}
+		return NULL;
+	}
+
+	/* Monitor-group form: locate the parent control group first. */
+	if (!*ctrl_name) {
+		parent = &rdtgroup_default;
+	} else {
+		list_for_each_entry(rdtg, &rdt_all_groups, rdtgroup_list) {
+			if (rdtg->type != RDTCTRL_GROUP)
+				continue;
+			if (!strcmp(rdt_kn_name(rdtg->kn), ctrl_name)) {
+				parent = rdtg;
+				break;
+			}
+		}
+		if (!parent)
+			return NULL;
+	}
+
+	list_for_each_entry(crg, &parent->mon.crdtgrp_list, mon.crdtgrp_list)
+		if (!strcmp(rdt_kn_name(crg->kn), mon_name))
+			return crg;
+	return NULL;
+}
+
+/**
+ * resctrl_kernel_mode_write() - Select kernel mode and bind group via info/kernel_mode
+ * @of:		kernfs file handle.
+ * @buf:	One line in the same format emitted by resctrl_kernel_mode_show(),
+ *		i.e. "<mode>[:group=<ctrl>/<mon>/]" with an optional surrounding
+ *		"[...]"; must end with a newline.  The ":group=<spec>" suffix is
+ *		optional -- when omitted the default control group
+ *		(&rdtgroup_default) is used.
+ * @nbytes:	Length of @buf.
+ * @off:	File offset (unused).
+ *
+ * Parses @buf, validates that <mode> is listed in resctrl_mode_str[] and is
+ * supported by the platform (resctrl_kcfg.kmode), resolves <ctrl>/<mon>/ to
+ * an existing rdtgroup (or picks &rdtgroup_default if no group was specified
+ * or if the new mode is INHERIT), clears any previous binding via
+ * rdtgroup_config_kmode_clear(), programs hardware via
+ * rdtgroup_config_kmode() when @kmode is not BIT(INHERIT_CTRL_AND_MON), and
+ * on success updates resctrl_kcfg.k_rdtgrp and resctrl_kcfg.kmode_cur.  The
+ * display-only "group=none" form produced by show for inactive modes is
+ * rejected.  Errors are reported in last_cmd_status.
+ *
+ * Return: @nbytes on success, negative errno with last_cmd_status set on error.
+ */
+static ssize_t resctrl_kernel_mode_write(struct kernfs_open_file *of,
+					 char *buf, size_t nbytes, loff_t off)
+{
+	char *mode_str, *group_str, *slash;
+	const char *ctrl_name, *mon_name;
+	struct rdtgroup *rdtgrp;
+	int ret = 0;
+	size_t len;
+	u32 kmode;
+	int i;
+
+	if (nbytes == 0 || buf[nbytes - 1] != '\n')
+		return -EINVAL;
+	buf[nbytes - 1] = '\0';
+

fs/resctrl/rdtgroup.c +21 -0

+
+	/*
+	 * Split "<mode>:group=<spec>"; the ":group=<spec>" suffix is optional
+	 * and when omitted the default control group (&rdtgroup_default) is used.
+	 */
+	group_str = strstr(buf, ":group=");
+	if (group_str) {
+		*group_str = '\0';
+		group_str += strlen(":group=");
+	}
+	mode_str = buf;
+
+	mutex_lock(&rdtgroup_mutex);
+	rdt_last_cmd_clear();
+
+	for (i = 0; i < RESCTRL_NUM_KERNEL_MODES; i++)
+		if (!strcmp(mode_str, resctrl_mode_str[i]))
+			break;
+	if (i == RESCTRL_NUM_KERNEL_MODES) {
+		rdt_last_cmd_puts("Unknown kernel mode\n");
+		ret = -EINVAL;

fs/resctrl/rdtgroup.c +22 -0

+		slash = strchr(group_str, '/');
+		if (!slash) {
+			rdt_last_cmd_puts("Group must be <ctrl>/<mon>/\n");
+			ret = -EINVAL;
+			goto out_unlock;
+		}
+		*slash = '\0';
+		ctrl_name = group_str;
+		mon_name = slash + 1;
+		slash = strchr(mon_name, '/');
+		if (!slash || slash[1] != '\0') {
+			rdt_last_cmd_puts("Group must be <ctrl>/<mon>/\n");
+			ret = -EINVAL;
+			goto out_unlock;
+		}
+		*slash = '\0';
+
+		rdtgrp = rdtgroup_by_kmode_path(ctrl_name, mon_name);
+		if (!rdtgrp) {
+			rdt_last_cmd_puts("Group not found\n");
+			ret = -EINVAL;
+			goto out_unlock;

fs/resctrl/rdtgroup.c +31 -0

+
+	/* No-op if the same mode is already active on the same group. */
+	if (resctrl_kcfg.kmode_cur == kmode && resctrl_kcfg.k_rdtgrp == rdtgrp)
+		goto out_unlock;
+
+	/*
+	 * global_assign_ctrl_assign_mon_per_cpu binds one CLOSID and RMID for
+	 * all kernel work (Documentation/filesystems/resctrl.rst uses
+	 * "<ctrl>/<mon>/", i.e. an RDTMON_GROUP).
+	 *
+	 * global_assign_ctrl_inherit_mon_per_cpu assigns one CLOSID globally
+	 * while leaving RMID inheritance to user contexts; that uses the
+	 * control group's CLOSID slot only, i.e. an RDTCTRL_GROUP.
+	 */
+	if (kmode == BIT(GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU) &&
+	    rdtgrp->type != RDTMON_GROUP) {
+		rdt_last_cmd_puts("global_assign_ctrl_assign_mon_per_cpu requires a monitor group\n");
+		ret = -EINVAL;
+		goto out_unlock;
+	}
+	if (kmode == BIT(GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU) &&
+	    rdtgrp->type != RDTCTRL_GROUP) {
+		rdt_last_cmd_puts("global_assign_ctrl_inherit_mon_per_cpu requires a control group\n");
+		ret = -EINVAL;
+		goto out_unlock;
+	}
+
+	/* Switching to a different group: release the old binding first. */
+	if (resctrl_kcfg.k_rdtgrp != rdtgrp) {
+		ret = rdtgroup_config_kmode_clear(resctrl_kcfg.k_rdtgrp,
+						  resctrl_kcfg.kmode_cur);

fs/resctrl/rdtgroup.c +12 -0

+			goto out_unlock;
+		}
+	}
+
+	resctrl_kcfg.k_rdtgrp = rdtgrp;
+	resctrl_kcfg.kmode_cur = kmode;
+
+out_unlock:
+	mutex_unlock(&rdtgroup_mutex);
+	return ret ?: nbytes;
+}
+
 void *rdt_kn_parent_priv(struct kernfs_node *kn)
 {
 	/*

@@ -1960,9 +2332,10 @@ static struct rftype res_common_files[] = {
 	},

Hi Babu,

Quoted 1 line · Babu Moger

info/kernel_mode lists the kernel-mode CLOSID/RMID policies the kernel

(also here please drop the x86 specific details and consider the resctrl fs changes to be valid from MPAM perspective also)

Quoted 4 lines

supports and the one currently active, but user space has no way to switch policies or rebind to a different rdtgroup, and the file does not name the group that owns the kernel CLOSID/RMID.

This adds a new feature. No need to describe this change as a bugfix.

Quoted 4 lines

Make info/kernel_mode writable. The format used by both read and write is one line per mode:

This sounds like multiple modes can be written to the file as long as they are separated by newline? I do not think it should be needed to support write of more than one mode at a time.

Quoted 10 lines

   inherit_ctrl_and_mon:group=none
   [global_assign_ctrl_inherit_mon_per_cpu:group=g1//]
   global_assign_ctrl_assign_mon_per_cpu:group=none

The active mode is wrapped in "[...]" and ":group=<ctrl>/<mon>/" names the bound rdtgroup ("//" for the default control group). Inactive modes report ":group=none". Documented in Documentation/filesystems/resctrl.rst.

Above describes the output of the file. This changelog can just focus on what needs to be supported when user space writes to the file.

Quoted 1 line

Quoted 1 line

The write path strims input, strips the optional "[...]", validates

strims?

Wait, why support the brackets as input? This seems unnecessary.

Quoted 9 lines

the mode against resctrl_kcfg.kmode, and resolves the optional ":group=" suffix via the new helper rdtgroup_by_kmode_path(). An omitted suffix or an INHERIT-mode write binds to the default group. On success, rdtgroup_config_kmode_clear() tears down the previous binding and rdtgroup_config_kmode() programs the new one before resctrl_kcfg.k_rdtgrp and resctrl_kcfg.kmode_cur are updated under rdtgroup_mutex. Allocation failures in the helpers are propagated so the write fails atomically.

This also reads like it just describes the code.

Quoted 3 lines

Add struct rdtgroup fields kmode and kmode_cpu_mask to track the per-group binding.

Please do not just describe the code but *why* this change is needed and what it means and how it is used.

Quoted 19 lines

Signed-off-by Babu Moger <[email protected]>

---
v3: New patch to handle the changed interface file info/kernel_mode.

---
  Documentation/filesystems/resctrl.rst |  51 ++++
  fs/resctrl/internal.h                 |   6 +
  fs/resctrl/rdtgroup.c                 | 375 +++++++++++++++++++++++++-
  3 files changed, 431 insertions(+), 1 deletion(-)

Documentation/filesystems/resctrl.rst +0 -0

index b003bed339fd..89fbf8b4fb2a 100644
@@ -522,6 +522,57 @@ conveyed in the error returns from file operations. E.g.
  	# cat info/last_cmd_status
  	mask f7 has non-consecutive 1-bits
 

Documentation/filesystems/resctrl.rst conveyed in the error returns from file operations. E.g. · line 525

Quoted 1 line

Documentation/filesystems/resctrl.rst +1 -0

+"kernel_mode":

(dropping the documentation here since I believe earlier comments apply)

...

fs/resctrl/internal.h struct mongroup { · line 220

Quoted 10 lines

fs/resctrl/internal.h +2 -0

index 1a9b29119f88..9435ce663f54 100644
@@ -216,6 +216,10 @@ struct mongroup {
   * @mon:			mongroup related data
   * @mode:			mode of resource group
   * @mba_mbps_event:		input monitoring event id when mba_sc is enabled
+ * @kmode:			true if this group is currently bound as the kernel-mode
+ *				CLOSID/RMID owner (resctrl_kcfg.k_rdtgrp)

(drop CLOSID/RMID)