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 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), which allows the CPU's CLOSID association to be changed during the transition from user mode to kernel mode. This allows the kernel to run using a different CLOSID than user space, which can improve system performance in certain scenarios.

The feature is detected via CPUID_Fn80000020_EBX_x00 [Bit 9]:
Privilege Level Zero Association (PLZA).

The PLZA feature details are documented in [1] available from [2].

[1] AMD64 Zen6 Platform Quality of Service (PQOS) Extensions:

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

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

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

---
v4: Split the patch into 2. This patch only handles x86 changes.
Re-wrote the changelog along the ABMC changes.

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

v2: Rebased on top of the latest tip.

---
 arch/x86/include/asm/cpufeatures.h | 1 +
 arch/x86/kernel/cpu/scattered.c    | 1 +
 2 files changed, 2 insertions(+)

Quoted 1 line · Babu Moger

Customers have identified an issue while using the QoS resource control

Please drop the "customers" speak from kernel code.

Quoted 26 lines

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), which allows the CPU's CLOSID association to be changed during the transition from user mode to kernel mode. This allows the kernel to run using a different CLOSID than user space, which can improve system performance in certain scenarios.

The feature is detected via CPUID_Fn80000020_EBX_x00 [Bit 9]:
Privilege Level Zero Association (PLZA).

The PLZA feature details are documented in [1] available from [2].

[1] AMD64 Zen6 Platform Quality of Service (PQOS) Extensions:

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

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

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

---
v4: Split the patch into 2. This patch only handles x86 changes.
Re-wrote the changelog along the ABMC changes.

Quoted 8 lines

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

v2: Rebased on top of the latest tip.

---
  arch/x86/include/asm/cpufeatures.h | 1 +
  arch/x86/kernel/cpu/scattered.c    | 1 +
  2 files changed, 2 insertions(+)

With that addressed:

Acked-by Borislav Petkov (AMD) <[email protected]>

Will change the text to:

When 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.

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), which allows the CPU's CLOSID association to be changed during the transition from user mode to kernel mode. This allows the kernel to run using a different CLOSID than user space, which can improve system performance in certain scenarios.

The feature is detected via CPUID_Fn80000020_EBX_x00 [Bit 9]:
Privilege Level Zero Association (PLZA).

The PLZA feature details are documented in [1] available from [2].

[1] AMD64 Zen6 Platform Quality of Service (PQOS) Extensions:

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

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

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

---
v4: Split the patch into 2. This patch only handles x86 changes.
Re-wrote the changelog along the ABMC changes.

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

v2: Rebased on top of the latest tip.

---
  arch/x86/include/asm/cpufeatures.h | 1 +
  arch/x86/kernel/cpu/scattered.c    | 1 +
  2 files changed, 2 insertions(+)

arch/x86/include/asm/cpufeatures.h +1 -0

index 1b4a48bff18f..bf6fc71f87fa 100644
@@ -517,6 +517,7 @@
  						      * and purposes if CLEAR_CPU_BUF_VM is set).
  						      */
  #define X86_FEATURE_X2AVIC_EXT		(21*32+20) /* AMD SVM x2AVIC support for 4k vCPUs */
+#define X86_FEATURE_PLZA		(21*32+21) /* Privilege Level Zero Association */
 
  /*
   * BUG word(s)

arch/x86/kernel/cpu/scattered.c +0 -0

index 937129ce6a96..1fa4d5aef17e 100644

Quoted 16 lines

arch/x86/include/asm/cpufeatures.h +1 -0

index 1b4a48bff18f..bf6fc71f87fa 100644
@@ -517,6 +517,7 @@
  						      * and purposes if CLEAR_CPU_BUF_VM is set).
  						      */
  #define X86_FEATURE_X2AVIC_EXT		(21*32+20) /* AMD SVM x2AVIC support for 4k vCPUs */
+#define X86_FEATURE_PLZA		(21*32+21) /* Privilege Level Zero Association */
  /*
   * BUG word(s)

arch/x86/kernel/cpu/scattered.c +0 -0

index 937129ce6a96..1fa4d5aef17e 100644

arch/x86/kernel/cpu/scattered.c static const struct cpuid_bit cpuid_bits[] = { · line 67

Quoted 7 lines

arch/x86/kernel/cpu/scattered.c +1 -0

@@ -61,6 +61,7 @@ static const struct cpuid_bit cpuid_bits[] = {
  	{ X86_FEATURE_BMEC,			CPUID_EBX,  3, 0x80000020, 0 },
  	{ X86_FEATURE_ABMC,			CPUID_EBX,  5, 0x80000020, 0 },
  	{ X86_FEATURE_SDCIAE,			CPUID_EBX,  6, 0x80000020, 0 },
+	{ X86_FEATURE_PLZA,			CPUID_EBX,  9, 0x80000020, 0 },
  	{ X86_FEATURE_TSA_SQ_NO,		CPUID_ECX,  1, 0x80000021, 0 },
  	{ X86_FEATURE_TSA_L1_NO,		CPUID_ECX,  2, 0x80000021, 0 },
  	{ X86_FEATURE_AMD_WORKLOAD_CLASS,	CPUID_EAX, 22, 0x80000021, 0 },

Sashiko reported:

--- Patch [1]: [RESEND PATCH v4 01/15] x86/resctrl: Support Privilege Level Zero Association (PLZA) ---
commit 0f2aa093b81d7a2e0dc203ce3466562f708898df
Author: Babu Moger <[email protected]>
x86/resctrl: Support Privilege Level Zero Association (PLZA) This commit adds support for AMD's Privilege Level Zero Association (PLZA) feature. It detects the feature via CPUID_Fn80000020_EBX_x00 [Bit 9] and adds the corresponding feature flag to the x86 cpufeatures array.

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

Review

Quoted 1 line

(quoted diff) +0 -0

b/arch/x86/include/asm/cpufeatures.h

arch/x86/include/asm/cpufeatures.h line 519

Quoted 7 lines

index 1b4a48bff18f7..bf6fc71f87fab 100644

arch/x86/include/asm/cpufeatures.h +0 -0

@@ -517,6 +517,7 @@
 						      * and purposes if CLEAR_CPU_BUF_VM is set).
 						      */
 #define X86_FEATURE_X2AVIC_EXT		(21*32+20) /* AMD SVM x2AVIC support for

4k vCPUs */

arch/x86/include/asm/cpufeatures.h line 520

Quoted 1 line

arch/x86/include/asm/cpufeatures.h +1 -0

+#define X86_FEATURE_PLZA		(21*32+21) /* Privilege Level Zero Association

*/
Should this addition also be mirrored in the tools directory copies of cpufeatures.h and kcpuid.csv?
If tools/arch/x86/include/asm/cpufeatures.h is not updated to match, tools like
perf can generate build warnings during check-headers.sh verification. Also, without updating tools/arch/x86/kcpuid/cpuid.csv, the kcpuid tool will be unaware of the new PLZA feature bit when users query CPU capabilities.

I thought tools/arch/x86/include/asm/cpufeatures.h would be synced after the changes to arch/x86/include/asm/cpufeatures.h are merged. Has that process changed?

If the expectation is to update tools/arch/x86/include/asm/cpufeatures.h as part of this patch, I can add those changes as well.

Quoted 56 lines · Babu Moger

Quoted 16 lines

arch/x86/include/asm/cpufeatures.h +1 -0

index 1b4a48bff18f..bf6fc71f87fa 100644
@@ -517,6 +517,7 @@
  						      * and purposes if CLEAR_CPU_BUF_VM is set).
  						      */
  #define X86_FEATURE_X2AVIC_EXT		(21*32+20) /* AMD SVM x2AVIC support for 4k vCPUs */
+#define X86_FEATURE_PLZA		(21*32+21) /* Privilege Level Zero Association */
  /*
   * BUG word(s)

arch/x86/kernel/cpu/scattered.c +0 -0

index 937129ce6a96..1fa4d5aef17e 100644

arch/x86/kernel/cpu/scattered.c static const struct cpuid_bit cpuid_bits[] = { · line 67

Quoted 7 lines

arch/x86/kernel/cpu/scattered.c +1 -0

@@ -61,6 +61,7 @@ static const struct cpuid_bit cpuid_bits[] = {
  	{ X86_FEATURE_BMEC,			CPUID_EBX,  3, 0x80000020, 0 },
  	{ X86_FEATURE_ABMC,			CPUID_EBX,  5, 0x80000020, 0 },
  	{ X86_FEATURE_SDCIAE,			CPUID_EBX,  6, 0x80000020, 0 },
+	{ X86_FEATURE_PLZA,			CPUID_EBX,  9, 0x80000020, 0 },
  	{ X86_FEATURE_TSA_SQ_NO,		CPUID_ECX,  1, 0x80000021, 0 },
  	{ X86_FEATURE_TSA_L1_NO,		CPUID_ECX,  2, 0x80000021, 0 },
  	{ X86_FEATURE_AMD_WORKLOAD_CLASS,	CPUID_EAX, 22, 0x80000021, 0 },

Sashiko reported:

--- Patch [1]: [RESEND PATCH v4 01/15] x86/resctrl: Support Privilege Level Zero Association (PLZA) ---
commit 0f2aa093b81d7a2e0dc203ce3466562f708898df
Author: Babu Moger <[email protected]>
x86/resctrl: Support Privilege Level Zero Association (PLZA) This commit adds support for AMD's Privilege Level Zero Association (PLZA) feature. It detects the feature via CPUID_Fn80000020_EBX_x00 [Bit 9] and adds the corresponding feature flag to the x86 cpufeatures array.

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

Review

Quoted 1 line

(quoted diff) +0 -0

b/arch/x86/include/asm/cpufeatures.h

arch/x86/include/asm/cpufeatures.h line 519

Quoted 7 lines

index 1b4a48bff18f7..bf6fc71f87fab 100644

arch/x86/include/asm/cpufeatures.h +0 -0

@@ -517,6 +517,7 @@
 						      * and purposes if CLEAR_CPU_BUF_VM is set).
 						      */
 #define X86_FEATURE_X2AVIC_EXT		(21*32+20) /* AMD SVM x2AVIC support for

4k vCPUs */

arch/x86/include/asm/cpufeatures.h line 520

Quoted 1 line

arch/x86/include/asm/cpufeatures.h +1 -0

+#define X86_FEATURE_PLZA		(21*32+21) /* Privilege Level Zero Association

*/
Should this addition also be mirrored in the tools directory copies of cpufeatures.h and kcpuid.csv?
If tools/arch/x86/include/asm/cpufeatures.h is not updated to match, tools like
perf can generate build warnings during check-headers.sh verification. Also, without updating tools/arch/x86/kcpuid/cpuid.csv, the kcpuid tool will be unaware of the new PLZA feature bit when users query CPU capabilities.

Quoted 3 lines

I thought tools/arch/x86/include/asm/cpufeatures.h would be synced after the changes to arch/x86/include/asm/cpufeatures.h are merged. Has that process changed?

I guess that hasn't changed:

tools/include/uapi/README

Let's add those perf tools hackers to confirm.

Well.. it's changed as Linus wanted to not update the headers for trivial changes. The script is still there but it's not running automatically. For perf, we used to check ioctl and other user-visible changes for system call tracing. And some headers moved to the tools/perf/trace/beauty/include directory to sync separately.

I think the headers will be sync-ed less frequently. So you may need to update the header for tooling changes manually.

Hey Namhyung,

Quoted 8 lines · Namhyung Kim

Well.. it's changed as Linus wanted to not update the headers for trivial changes. The script is still there but it's not running automatically. For perf, we used to check ioctl and other user-visible changes for system call tracing. And some headers moved to the tools/perf/trace/beauty/include directory to sync separately.

I think the headers will be sync-ed less frequently. So you may need to update the header for tooling changes manually.

I'm reading this as, we should not touch cpufeatures.h in tools/ and let you guys decide when you actually need bits from it? In the sense: only when you really need bits from it, you'll update it and other, unrelated bits which are not needed, can remain different...

Or?

No, it's perfectly fine to update any tooling headers if you need it. It should be up to you whether you update the whole file or just needed bits. Just expect us to do it less frequently. :)

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), which allows the CPU's CLOSID association to be changed during the transition from user mode to kernel mode. This allows the kernel to run using a different CLOSID than user space, which can improve system performance in certain scenarios.

The feature is detected via CPUID_Fn80000020_EBX_x00 [Bit 9]:
Privilege Level Zero Association (PLZA).

The PLZA feature details are documented in [1] available from [2].

[1] AMD64 Zen6 Platform Quality of Service (PQOS) Extensions:

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

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

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

Hi Babu,

Could you please switch subject prefix to be "x86/cpufeatures:"?

Quoted 11 lines

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), which allows the CPU's CLOSID association to be changed during the transition from user mode to kernel mode. This allows the kernel to run using a different CLOSID than user space, which can improve system performance in certain scenarios.

How should user interpret "in certain scenarios"? Could the scenarios be highlighted ... or maybe just drop this since it is already preceded with "can improve system performance".

This description implies that PLZA is a feature that is only related to memory bandwidth allocation where it can be beneficial. As I understand the feature impacts all allocation features concurrently, including cache allocation where it should be used with care?

If the goal is to describe all the feature capabilities then it may be worth a mention of the impact/usage related to monitoring?

Quoted 7 lines

The feature is detected via CPUID_Fn80000020_EBX_x00 [Bit 9]:
Privilege Level Zero Association (PLZA).

The PLZA feature details are documented in [1] available from [2].

Quoted 5 lines

[1] AMD64 Zen6 Platform Quality of Service (PQOS) Extensions:

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

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

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

Please follow "Ordering of commit tags" found in Documentation/process/maintainer-tip.rst.

Add a kernel command-line parameter to enable or disable the exposure of the PLZA (Privilege Level Zero Association) feature to resctrl.

This allows administrators to control PLZA visibility at boot time via the rdt= option (e.g. rdt=plza or rdt=!plza).

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

---
v4: Split the patch 1 from v3 into 2 patches.
This patch contains changes for resctrl subsystem.

---
  Documentation/admin-guide/kernel-parameters.txt | 2 +-
  Documentation/filesystems/resctrl.rst           | 1 +
  arch/x86/kernel/cpu/resctrl/core.c              | 2 ++
  3 files changed, 4 insertions(+), 1 deletion(-)

Documentation/admin-guide/kernel-parameters.txt +1 -1

index b5493a7f8f22..1de27055cb32 100644
@@ -6401,7 +6401,7 @@ Kernel parameters
  	rdt=		[HW,X86,RDT]
  			Turn on/off individual RDT features. List is:
  			cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp,
-			mba, smba, bmec, abmc, sdciae, energy[:guid],
+			mba, smba, bmec, abmc, sdciae, plza, energy[:guid],
  			perf[:guid].
  			E.g. to turn on cmt and turn off mba use:
  				rdt=cmt,!mba

Documentation/filesystems/resctrl.rst +1 -0

index e4b66af55ffb..f3e941404967 100644
@@ -28,6 +28,7 @@ SMBA (Slow Memory Bandwidth Allocation)				""
  BMEC (Bandwidth Monitoring Event Configuration)			""
  ABMC (Assignable Bandwidth Monitoring Counters)			""
  SDCIAE (Smart Data Cache Injection Allocation Enforcement)	""
+PLZA (Privilege Level Zero Association)				""
  =============================================================== ================================
 
  Historically, new features were made visible by default in /proc/cpuinfo. This

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

index f452e8ce4cef..27e09cded829 100644
@@ -803,6 +803,7 @@ enum {
  	RDT_FLAG_BMEC,
  	RDT_FLAG_ABMC,
  	RDT_FLAG_SDCIAE,
+	RDT_FLAG_PLZA,
  };
 
  #define RDT_OPT(idx, n, f)	\

Add a kernel command-line parameter to enable or disable the exposure of the PLZA (Privilege Level Zero Association) feature to resctrl.

This allows administrators to control PLZA visibility at boot time via the rdt= option (e.g. rdt=plza or rdt=!plza).

Hi Babu,

Quoted 3 lines · Babu Moger

Add a kernel command-line parameter to enable or disable the exposure of the PLZA (Privilege Level Zero Association) feature to resctrl.

Quoted 2 lines

This allows administrators to control PLZA visibility at boot time via the rdt= option (e.g. rdt=plza or rdt=!plza).

nit: Since this provides examples of the only two supported usages it may be helpful to make clear when these options are required since users should not need to always boot with rdt=plza to use this feature.

Privilege Level Zero Association (PLZA) allows the kernel to use a different CLOSID (and optionally RMID) than user mode on entry to kernel mode. The CLOSID/RMID association is programmed per CPU via MSR_IA32_PQR_PLZA_ASSOC (0xc00003fc), using RMID/CLOSID values and their respective enable bits.

Add the MSR definition and union msr_pqr_plza_assoc to represent the MSR bitfield layout used by subsequent PLZA programming.

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

---
v4: Re-wrote the changelog and code comment.

v3: No code changes. Patch order changed. Improved changelog.

v2: No changes. Just rebasing on top of the latest tip branch.

---
  arch/x86/include/asm/msr-index.h       |  1 +
  arch/x86/kernel/cpu/resctrl/internal.h | 37 ++++++++++++++++++++++++++
  2 files changed, 38 insertions(+)

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

index 18c4be75e927..2503451a95fe 100644
@@ -1292,6 +1292,7 @@
  /* - 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/kernel/cpu/resctrl/internal.h +27 -0

index e3cfa0c10e92..020ebc2c8a1f 100644
@@ -222,6 +222,43 @@ union l3_qos_abmc_cfg {
  	unsigned long full;
  };
 
+/*
+ * Privilege Level Zero Association (PLZA) is configured by writing to
+ * MSR_IA32_PQR_PLZA_ASSOC. The MSR must be programmed on every CPU in
+ * the QoS domain. Each domain supports only one PLZA CLOSID and/or RMID
+ * association. All fields other than PLZA_EN must hold the same value
+ * across the domain for consistent operation.
+ *
+ * When PLZA_EN is set, the CLOSID/RMID association used at CPL 0 is
+ * taken from MSR_IA32_PQR_PLZA_ASSOC instead of MSR_IA32_PQR_ASSOC.
+ *
+ * @rmid		: RMID associated with PLZA.
+ * @reserved1		: Reserved.
+ * @rmid_en		: Enable RMID association for PLZA.
+ * @closid		: CLOSID associated with PLZA.
+ * @reserved2		: Reserved.
+ * @closid_en		: Enable CLOSID association for PLZA.
+ * @reserved3		: Reserved.
+ * @plza_en		: Enable PLZA. When enabled, PLZA applies to the
+ *			  given CPU. When PLZA is disabled for a CPU, the
+ *			  CLOSID and RMID association defined in the
+ *			  PQR_ASSOC MSR applies, regardless of the CPU's
+ *			  privilege level.
+ */
+union msr_pqr_plza_assoc {
+	struct {
+		unsigned long rmid	:12,
+			      reserved1	:19,

This is a pre-existing issue, but does this union truncate data on 32-> bit x86 builds? On 32-bit kernels, unsigned long is 32 bits, but the bitfields sum to 64 bits.

Privilege Level Zero Association (PLZA) allows the kernel to use a different CLOSID (and optionally RMID) than user mode on entry to kernel mode. The CLOSID/RMID association is programmed per CPU via

MSR_IA32_PQR_PLZA_ASSOC (0xc00003fc), using RMID/CLOSID values and their respective enable bits.

Add the MSR definition and union msr_pqr_plza_assoc to represent the MSR bitfield layout used by subsequent PLZA programming.

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

---
v4: Re-wrote the changelog and code comment.

v3: No code changes. Patch order changed. Improved changelog.

v2: No changes. Just rebasing on top of the latest tip branch.

---
 arch/x86/include/asm/msr-index.h       |  1 +
 arch/x86/kernel/cpu/resctrl/internal.h | 37 ++++++++++++++++++++++++++
 2 files changed, 38 insertions(+)

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

index 18c4be75e927..2503451a95fe 100644
@@ -1292,6 +1292,7 @@
 /* - 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/kernel/cpu/resctrl/internal.h +11 -0

index e3cfa0c10e92..020ebc2c8a1f 100644
@@ -222,6 +222,43 @@ union l3_qos_abmc_cfg {
 	unsigned long full;
 };
 
+/*
+ * Privilege Level Zero Association (PLZA) is configured by writing to
+ * MSR_IA32_PQR_PLZA_ASSOC. The MSR must be programmed on every CPU in
+ * the QoS domain. Each domain supports only one PLZA CLOSID and/or RMID
+ * association. All fields other than PLZA_EN must hold the same value
+ * across the domain for consistent operation.
+ *
+ * When PLZA_EN is set, the CLOSID/RMID association used at CPL 0 is
+ * taken from MSR_IA32_PQR_PLZA_ASSOC instead of MSR_IA32_PQR_ASSOC.
+ *
+ * @rmid		: RMID associated with PLZA.

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,

Hi Babu,

Quoted 3 lines · Babu Moger

Privilege Level Zero Association (PLZA) allows the kernel to use a different CLOSID (and optionally RMID) than user mode on entry to kernel mode. The CLOSID/RMID association is programmed per CPU via

CLOSID is also optional, no? I am not able to recall now why this is not made optional in this implementation though. Could you please remind me and add it to the changelog for next time?

Quoted 54 lines

MSR_IA32_PQR_PLZA_ASSOC (0xc00003fc), using RMID/CLOSID values and their respective enable bits.

Add the MSR definition and union msr_pqr_plza_assoc to represent the MSR bitfield layout used by subsequent PLZA programming.

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

---
v4: Re-wrote the changelog and code comment.

v3: No code changes. Patch order changed. Improved changelog.

v2: No changes. Just rebasing on top of the latest tip branch.

---
  arch/x86/include/asm/msr-index.h       |  1 +
  arch/x86/kernel/cpu/resctrl/internal.h | 37 ++++++++++++++++++++++++++
  2 files changed, 38 insertions(+)

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

index 18c4be75e927..2503451a95fe 100644
@@ -1292,6 +1292,7 @@
  /* - 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/kernel/cpu/resctrl/internal.h +15 -0

index e3cfa0c10e92..020ebc2c8a1f 100644
@@ -222,6 +222,43 @@ union l3_qos_abmc_cfg {
  	unsigned long full;
  };
 
+/*
+ * Privilege Level Zero Association (PLZA) is configured by writing to
+ * MSR_IA32_PQR_PLZA_ASSOC. The MSR must be programmed on every CPU in
+ * the QoS domain. Each domain supports only one PLZA CLOSID and/or RMID
+ * association. All fields other than PLZA_EN must hold the same value
+ * across the domain for consistent operation.
+ *
+ * When PLZA_EN is set, the CLOSID/RMID association used at CPL 0 is
+ * taken from MSR_IA32_PQR_PLZA_ASSOC instead of MSR_IA32_PQR_ASSOC.
+ *
+ * @rmid		: RMID associated with PLZA.
+ * @reserved1		: Reserved.
+ * @rmid_en		: Enable RMID association for PLZA.
+ * @closid		: CLOSID associated with PLZA.
+ * @reserved2		: Reserved.

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

Quoted 6 lines

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

+ * @closid_en		: Enable CLOSID association for PLZA.
+ * @reserved3		: Reserved.
+ * @plza_en		: Enable PLZA. When enabled, PLZA applies to the
+ *			  given CPU. When PLZA is disabled for a CPU, the
+ *			  CLOSID and RMID association defined in the
+ *			  PQR_ASSOC MSR applies, regardless of the CPU's

To support grep: "the PQR_ASSOC MSR" -> "MSR_IA32_PQR_ASSOC"

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

Quoted 2 lines

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

+ *			  privilege level.

Could this also please highlight the relationship between plza_en, rmid_en, and closid_en? For example, if I understand correctly, when "rmid_en" is 0 then RMID is taken from MSR_IA32_PQR_ASSOC, similarly, when "closid_en" is 0 then CLOSID is taken from MSR_IA32_PQR_ASSOC. Thus, plza_en could be 1, but if both "rmid_en" and "closid_en" are 0 then, the same behavior results as described for plza_en == 0: "CLOSID and RMID association defined in MSR_IA32_PQR_ASSOC applies, regardless of the CPU's privilege level".

Quoted 8 lines · Reinette Chatre

Quoted 3 lines · Babu Moger

Privilege Level Zero Association (PLZA) allows the kernel to use a different CLOSID (and optionally RMID) than user mode on entry to kernel mode. The CLOSID/RMID association is programmed per CPU via

CLOSID is also optional, no? I am not able to recall now why this is not made optional in this implementation though. Could you please remind me and add it to the changelog for next time?

Yes, CLOSID is optional as well. Since PLZA was primarily focused on allocation, I hadn't considered that use case initially. However, there may be scenarios where a user wants to monitor kernel activity without affecting or changing the existing allocation configuration. That would introduce an additional operating mode(See below).

INHERIT_CTRL_AND_MON:
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. This matches today's resctrl behavior.

GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:
Kernel work uses a globally assigned allocation while monitoring is inherited from the user space task. On x86 this means a CLOSID is assigned for kernel work and the RMID is inherited from the user space task. Default scope is all online CPUs; a subset may be selected via the resctrl group interface. A CTRL_MON group is bound to this mode.

GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU:
Kernel work uses globally assigned allocation and monitoring. On x86 this means both CLOSID and RMID are assigned for kernel work. Default scope is all online CPUs; a subset may be selected via the resctrl group interface. A CTRL_MON or MON group is bound to this mode.

GLOBAL_INHERIT_CTRL_ASSIGN_MON_PER_CPU:   <--- New mode Kernel work inherits the allocation from user task and monitoring is globally assigned for kernel work. On x86 this means that kernel work shares the same CLOSID as user task and kernel work user globally assigned RMID. A MON group is bound to this mode.

Hi Babu,

Quoted 11 lines · Babu Moger

Quoted 8 lines · Reinette Chatre

Quoted 3 lines · Babu Moger

Privilege Level Zero Association (PLZA) allows the kernel to use a different CLOSID (and optionally RMID) than user mode on entry to kernel mode. The CLOSID/RMID association is programmed per CPU via

CLOSID is also optional, no? I am not able to recall now why this is not made optional in this implementation though. Could you please remind me and add it to the changelog for next time?

Quoted 5 lines

Yes, CLOSID is optional as well. Since PLZA was primarily focused on allocation, I hadn't considered that use case initially. However, there may be scenarios where a user wants to monitor kernel activity without affecting or changing the existing allocation configuration. That would introduce an additional operating mode(See below).

ok.

I think doing so will simplify supporting the different modes across systems that may not support allocation or monitoring.

Quoted 18 lines

INHERIT_CTRL_AND_MON:
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. This matches today's resctrl behavior.

GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:
Kernel work uses a globally assigned allocation while monitoring is inherited from the user space task. On x86 this means a CLOSID is assigned for kernel work and the RMID is inherited from the user space task. Default scope is all online CPUs; a subset may be selected via the resctrl group interface. A CTRL_MON group is bound to this mode.

GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU:
Kernel work uses globally assigned allocation and monitoring. On x86 this means both CLOSID and RMID are assigned for kernel work. Default scope is all online CPUs; a subset may be selected via the resctrl group interface. A CTRL_MON or MON group is bound to this mode.

Quoted 5 lines

GLOBAL_INHERIT_CTRL_ASSIGN_MON_PER_CPU:   <--- New mode Kernel work inherits the allocation from user task and monitoring is globally assigned for kernel work. On x86 this means that kernel work shares the same CLOSID as user task and kernel work user globally assigned RMID. A MON group is bound to this mode.

I provided comments about this text in following patch. Apart from that, I think a CTRL_MON or MON group could be assigned to this mode?

Kernel-mode traffic can use a different allocation and monitoring context than the originating user task. On x86, Privilege Level Zero Association (PLZA) enables the kernel to switch to a different CLOSID (and optionally RMID) when entering kernel mode.

Architectures need a common way to name kernel-mode policies before resctrl can report what is active or what the platform supports.

Introduce enum resctrl_kernel_mode:
- INHERIT_CTRL_AND_MON: Kernel work inherits allocation and monitoring from the user task (current behavior).
- GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU: Assign allocation for kernel work; inherit monitoring from the user task.
- GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU: Assign a dedicated allocation and monitoring for kernel work.

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

---
v4: Updated the changelog to be generic as possible.
Moved the enum resctrl_kernel_mode to include/linux/resctrl.h. Updated the code comments to be generic.
Removed resctrl_kmode_cfg from the code. This definition can be fs specific only and architectures dont need to know. Changed enum name to resctrl_kernel_mode from resctrl_kernel_modes.

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 | 31 +++++++++++++++++++++++++++++++
  1 file changed, 31 insertions(+)

include/linux/resctrl.h +24 -0

index 73ff522448a0..c7abed51cd5f 100644
@@ -703,6 +703,37 @@ int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable);
   */
  bool resctrl_arch_get_io_alloc_enabled(struct rdt_resource *r);
 
+/**
+ * enum resctrl_kernel_mode - Kernel-mode control and monitor association
+ *			      policy.
+ *
+ * @INHERIT_CTRL_AND_MON:
+ *	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. This matches today's resctrl behavior.
+ *
+ * @GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:
+ *	Kernel work uses a globally assigned allocation while monitoring is
+ *	inherited from the user space task. On x86 this means a CLOSID is
+ *	assigned for kernel work and the RMID is inherited from the user space
+ *	task. Default scope is all online CPUs; a subset may be selected via
+ *	the resctrl group interface. A CTRL_MON group is bound to this mode.
+ *
+ * @GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU:
+ *	Kernel work uses globally assigned allocation and monitoring. On x86
+ *	this means both CLOSID and RMID are assigned for kernel work. Default
+ *	scope is all online CPUs; a subset may be selected via the resctrl
+ *	group interface. A CTRL_MON or MON group is bound to this mode.
+ */
+enum resctrl_kernel_mode {
+	INHERIT_CTRL_AND_MON,

include/linux/resctrl.h +0 -0

index 73ff522448a02..c7abed51cd5f0 100644

Kernel-mode traffic can use a different allocation and monitoring context than the originating user task. On x86, Privilege Level Zero Association (PLZA) enables the kernel to switch to a different CLOSID (and optionally RMID) when entering kernel mode.

Architectures need a common way to name kernel-mode policies before resctrl

can report what is active or what the platform supports.

Introduce enum resctrl_kernel_mode:
- INHERIT_CTRL_AND_MON: Kernel work inherits allocation and monitoring from the user task (current behavior).

- GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU: Assign allocation for kernel work; inherit monitoring from the user task.

- GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU: Assign a dedicated allocation and monitoring for kernel work.

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

---

include/linux/resctrl.h +0 -0

index 73ff522448a0..c7abed51cd5f 100644

Hi Babu,

Quoted 5 lines · Babu Moger

Kernel-mode traffic can use a different allocation and monitoring context than the originating user task. On x86, Privilege Level Zero Association (PLZA) enables the kernel to switch to a different CLOSID (and optionally RMID) when entering kernel mode.

Quoted 1 line

Architectures need a common way to name kernel-mode policies before resctrl

Please pick one term and stick with it. While reading through this series I have come across "kernel-mode policies", "kernel-mode binding", "kernel-mode configuration", and "kernel-mode association". Is the distinction even needed? Could all of these just instead be: "kernel mode"?

Quoted 6 lines

can report what is active or what the platform supports.

Introduce enum resctrl_kernel_mode:
- INHERIT_CTRL_AND_MON: Kernel work inherits allocation and monitoring from the user task (current behavior).

The issue with this "combination" mode becomes obvious in patch 7. I also see that sashiko hinted at this issue but I am not able to see from your response what the plan is to address this. As highlighted by patch 7 and sashiko the "allocation" and "monitoring" features of a system are independent - a system need not support/enable both. This should be easy to reproduce by, for example, booting a system with needed rdt= options disabling allocation or monitoring features.

I think it will be unexpected to a user on an allocation-only system to see interface like:

  # cat info/kernel_mode
   [inherit_ctrl_and_mon]
   global_assign_ctrl_inherit_mon_per_cpu:group=uninitialized
   global_assign_ctrl_assign_mon_per_cpu:group=uninitialized

Should it not rather be, for example:

  # cat info/kernel_mode
   [inherit_ctrl]
   global_assign_ctrl_per_cpu:group=uninitialized

Similarly the user input would not need to provide a monitor group when system only supports allocation.

Quoted 3 lines

- GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU: Assign allocation for kernel work; inherit monitoring from the user task.

I am not able to parse "Assign allocation for kernel work"

Quoted 7 lines

- GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU: Assign a dedicated allocation and monitoring for kernel work.

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

---

...

Quoted 8 lines

include/linux/resctrl.h +0 -0

index 73ff522448a0..c7abed51cd5f 100644
@@ -703,6 +703,37 @@ int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable);
   */
  bool resctrl_arch_get_io_alloc_enabled(struct rdt_resource *r);
 

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

Quoted 6 lines

include/linux/resctrl.h +6 -0

+/**
+ * enum resctrl_kernel_mode - Kernel-mode control and monitor association
+ *			      policy.
+ *
+ * @INHERIT_CTRL_AND_MON:
+ *	Kernel work inherits the allocation and monitoring from the user space

"inherits the allocation and monitoring" is very vague. I think it will help to make things clear if this is described as the control and monitor groups being assigned.

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

Quoted 2 lines

include/linux/resctrl.h +2 -0

+ *	task. On x86 this means that kernel work shares the same CLOSID and
+ *	RMID as the user space task. This matches today's resctrl behavior.

"This matches today's resctrl behavior." - This cannot be expected to age well and can be dropped.

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

Quoted 5 lines

include/linux/resctrl.h +4 -0

+ *
+ * @GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU:
+ *	Kernel work uses a globally assigned allocation while monitoring is
+ *	inherited from the user space task. On x86 this means a CLOSID is

(same comment as above)

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

Quoted 7 lines

include/linux/resctrl.h +6 -0

+ *	assigned for kernel work and the RMID is inherited from the user space
+ *	task. Default scope is all online CPUs; a subset may be selected via
+ *	the resctrl group interface. A CTRL_MON group is bound to this mode.
+ *
+ * @GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU:
+ *	Kernel work uses globally assigned allocation and monitoring. On x86

(same comment as above)

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

Quoted 10 lines

include/linux/resctrl.h +9 -0

+ *	this means both CLOSID and RMID are assigned for kernel work. Default
+ *	scope is all online CPUs; a subset may be selected via the resctrl
+ *	group interface. A CTRL_MON or MON group is bound to this mode.
+ */
+enum resctrl_kernel_mode {
+	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,

Please drop comma on a terminator line.

Quoted 24 lines · Reinette Chatre

Quoted 5 lines · Babu Moger

can report what is active or what the platform supports.

Introduce enum resctrl_kernel_mode:
   - INHERIT_CTRL_AND_MON: Kernel work inherits allocation and monitoring from the user task (current behavior).

The issue with this "combination" mode becomes obvious in patch 7. I also see that sashiko hinted at this issue but I am not able to see from your response what the plan is to address this. As highlighted by patch 7 and sashiko the "allocation" and "monitoring" features of a system are independent - a system need not support/enable both. This should be easy to reproduce by, for example, booting a system with needed rdt= options disabling allocation or monitoring features.

I think it will be unexpected to a user on an allocation-only system to see interface like:

  # cat info/kernel_mode
   [inherit_ctrl_and_mon]
   global_assign_ctrl_inherit_mon_per_cpu:group=uninitialized
   global_assign_ctrl_assign_mon_per_cpu:group=uninitialized

Quoted 7 lines

Should it not rather be, for example:

  # cat info/kernel_mode
   [inherit_ctrl]
   global_assign_ctrl_per_cpu:group=uninitialized

Similarly the user input would not need to provide a monitor group when system only supports allocation.

Ok. Yea. We need to separate control and monitor separately.

How about something like this?

 # cat info/kernel_mode
   [ctrl=inherit,mon=inherit]
   ctrl=assign,mon=inherit:group=uninitialized
   ctrl=assign,mon=assign:group=uninitialized
   ctrl=inherit,mon=assign:group=uninitialized

If allocation(ctrl) is only supported.

 # cat info/kernel_mode
   [ctrl=inherit]
   ctrl=assign:group=uninitialized

If monitor (mon) is only supported.

 # cat info/kernel_mode
   [mon=inherit]
   mon=assign:group=uninitialized

Hi Babu,

Quoted 50 lines · Babu

Quoted 24 lines · Reinette Chatre

Quoted 5 lines · Babu Moger

can report what is active or what the platform supports.

Introduce enum resctrl_kernel_mode:
   - INHERIT_CTRL_AND_MON: Kernel work inherits allocation and monitoring from the user task (current behavior).

The issue with this "combination" mode becomes obvious in patch 7. I also see that sashiko hinted at this issue but I am not able to see from your response what the plan is to address this. As highlighted by patch 7 and sashiko the "allocation" and "monitoring" features of a system are independent - a system need not support/enable both. This should be easy to reproduce by, for example, booting a system with needed rdt= options disabling allocation or monitoring features.

I think it will be unexpected to a user on an allocation-only system to see interface like:

   # cat info/kernel_mode
    [inherit_ctrl_and_mon]
    global_assign_ctrl_inherit_mon_per_cpu:group=uninitialized
    global_assign_ctrl_assign_mon_per_cpu:group=uninitialized

Quoted 7 lines

Should it not rather be, for example:

   # cat info/kernel_mode
    [inherit_ctrl]
    global_assign_ctrl_per_cpu:group=uninitialized

Similarly the user input would not need to provide a monitor group when system only supports allocation.

Ok. Yea. We need to separate control and monitor separately.

How about something like this?

  # cat info/kernel_mode
    [ctrl=inherit,mon=inherit]
    ctrl=assign,mon=inherit:group=uninitialized
    ctrl=assign,mon=assign:group=uninitialized
    ctrl=inherit,mon=assign:group=uninitialized

If allocation(ctrl) is only supported.

  # cat info/kernel_mode
    [ctrl=inherit]
    ctrl=assign:group=uninitialized

Quoted 7 lines

If monitor (mon) is only supported.

  # cat info/kernel_mode
    [mon=inherit]
    mon=assign:group=uninitialized

Please always keep in mind all the requirements and use cases we learned about during and after RFC v1 of this work.

For example, we already know that "per group" assignment is something resctrl needs to be ready for. Consider the example in
https://lore.kernel.org/lkml/[email protected]/

There may even be "per task" assignment in the future.

Constraining this feature to PLZA will make it harder to enable the capabilities that we know resctrl need to support in the future.

This is how we originally landed on the "global" assignment distinction
(https://lore.kernel.org/lkml/[email protected]/)
"global assignment" should be kept or replaced with a solution that continues to prepare resctrl for these other capabilities.

I am not able to see how resctrl could support "per group" assignment with the interface you propose above. If I am missing this, please highlight the solution.

resctrl may need to explicitly split kernel mode from kernel mode properties. For example, below shows an "assign_global_enable_per_cpu" as the kernel mode, now with three properties:
- "ctrl" - could be "assign" or "inherit"
- "mon" - could be "assign" or "inherit"
- "group" - required if "ctrl" or "mon" is set to "assign"

    # cat info/kernel_mode
    [inherit]
    assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=uninitialized

When resctrl needs to support "per-group" assignment "kernel_mode" could contain below with supporting documentation noting which per-resource group files will appear when "assign_per_group" is selected that user space can use to manage the assignments.

    # cat info/kernel_mode
    [inherit]
    assign_per_group

Quoted 8 lines · Reinette Chatre

Please always keep in mind all the requirements and use cases we learned about during and after RFC v1 of this work.

For example, we already know that "per group" assignment is something resctrl needs to be ready for. Consider the example in
https://lore.kernel.org/lkml/[email protected]/

There may even be "per task" assignment in the future.

Yes. That is correct.

Quoted 8 lines

Constraining this feature to PLZA will make it harder to enable the capabilities that we know resctrl need to support in the future.

This is how we originally landed on the "global" assignment distinction
(https://lore.kernel.org/lkml/[email protected]/)
"global assignment" should be kept or replaced with a solution that continues to prepare resctrl for these other capabilities.

Yes. Makes sense.

Quoted 10 lines

I am not able to see how resctrl could support "per group" assignment with the interface you propose above. If I am missing this, please highlight the solution.

resctrl may need to explicitly split kernel mode from kernel mode properties. For example, below shows an "assign_global_enable_per_cpu" as the kernel mode, now with three properties:
- "ctrl" - could be "assign" or "inherit"
- "mon" - could be "assign" or "inherit"
- "group" - required if "ctrl" or "mon" is set to "assign"

ok.

Quoted 4 lines

    # cat info/kernel_mode
    [inherit]
    assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=uninitialized

Shouldn't this be like below when default is inherit?

# cat info/kernel_mode
[inherit]
assign_global_enable_per_cpu

When the default changes to assign_global_enable_per_cpu:

# cat info/kernel_mode
inherit [assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=ctrl_mon1//]

Display the second mode with properties only when group is associated with it?

# cat info/kernel_mode
inherit
[assign_global_enable_per_cpu:mon=assign;group=ctrl1/mon1/]

Quoted 6 lines

When resctrl needs to support "per-group" assignment "kernel_mode" could contain below with supporting documentation noting which per-resource group files will appear when "assign_per_group" is selected that user space can use to manage the assignments.

Quoted 4 lines

    # cat info/kernel_mode
    [inherit]
    assign_per_group

I know it is future. What could be difference between assign_global_enable_per_cpu and assign_per_group?

Hi Babu,

Quoted 43 lines · Babu Moger

Quoted 8 lines · Reinette Chatre

Please always keep in mind all the requirements and use cases we learned about during and after RFC v1 of this work.

For example, we already know that "per group" assignment is something resctrl needs to be ready for. Consider the example in
https://lore.kernel.org/lkml/[email protected]/

There may even be "per task" assignment in the future.

Yes. That is correct.

Quoted 8 lines

Constraining this feature to PLZA will make it harder to enable the capabilities that we know resctrl need to support in the future.

This is how we originally landed on the "global" assignment distinction
(https://lore.kernel.org/lkml/[email protected]/)
"global assignment" should be kept or replaced with a solution that continues to prepare resctrl for these other capabilities.

Yes. Makes sense.

Quoted 10 lines

I am not able to see how resctrl could support "per group" assignment with the interface you propose above. If I am missing this, please highlight the solution.

resctrl may need to explicitly split kernel mode from kernel mode properties. For example, below shows an "assign_global_enable_per_cpu" as the kernel mode, now with three properties:
- "ctrl" - could be "assign" or "inherit"
- "mon" - could be "assign" or "inherit"
- "group" - required if "ctrl" or "mon" is set to "assign"

ok.

Quoted 4 lines

     # cat info/kernel_mode
     [inherit]
     assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=uninitialized

Quoted 6 lines

Shouldn't this be like below when default is inherit?

# cat info/kernel_mode
[inherit]
assign_global_enable_per_cpu

I think it will be useful to let the interface:
(a) show to user space which properties are available for each supported mode, and
(b) show user space what the default value of those properties will be if they are not set when the associated mode is enabled.

To (b), since the default resource group is used as default when the group is not provided it may be better to use "//" (or just "/", depending on system supporting just one of allocation or monitoring) instead of "uninitialized".

Quoted 7 lines

When the default changes to assign_global_enable_per_cpu:

# cat info/kernel_mode
inherit [assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=ctrl_mon1//]

Display the second mode with properties only when group is associated with it?

Please consider this from user space side. The user needs to enable the mode. How will the user know which properties are available and what the defaults are?

Hi Reinette,

Quoted 53 lines · Reinette Chatre

Hi Babu,

Quoted 49 lines · Babu Moger

Quoted 8 lines · Reinette Chatre

Please always keep in mind all the requirements and use cases we learned about during and after RFC v1 of this work.

For example, we already know that "per group" assignment is something resctrl needs to be ready for. Consider the example in
https://lore.kernel.org/lkml/[email protected]/

There may even be "per task" assignment in the future.

Yes. That is correct.

Quoted 8 lines

Constraining this feature to PLZA will make it harder to enable the capabilities that we know resctrl need to support in the future.

This is how we originally landed on the "global" assignment distinction
(https://lore.kernel.org/lkml/[email protected]/)
"global assignment" should be kept or replaced with a solution that continues to prepare resctrl for these other capabilities.

Yes. Makes sense.

Quoted 10 lines

I am not able to see how resctrl could support "per group" assignment with the interface you propose above. If I am missing this, please highlight the solution.

resctrl may need to explicitly split kernel mode from kernel mode properties. For example, below shows an "assign_global_enable_per_cpu" as the kernel mode, now with three properties:
- "ctrl" - could be "assign" or "inherit"
- "mon" - could be "assign" or "inherit"
- "group" - required if "ctrl" or "mon" is set to "assign"

ok.

Quoted 4 lines

     # cat info/kernel_mode
     [inherit]
     assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=uninitialized

Shouldn't this be like below when default is inherit?

# cat info/kernel_mode
[inherit]
assign_global_enable_per_cpu

Quoted 4 lines

I think it will be useful to let the interface:
  (a) show to user space which properties are available for each supported mode, and
  (b) show user space what the default value of those properties will be if they are not set when the associated mode is enabled.

The "inherit" is the default property if it is not explicitly set. Right?

# cat info/kernel_mode
[inherit]
assign_global_enable_per_cpu:ctrl=inherit;mon=inherit;group=uninitialized

If the intention is to display all supported values for each property, then we should do so consistently for all properties. For example:

# cat info/kernel_mode
[inherit]
assign_global_enable_per_cpu:ctrl=inherit,assign;mon=inherit,assign;group=uninitialized

Quoted 1 line

Quoted 4 lines

To (b), since the default resource group is used as default when the group is not provided it may be better to use "//" (or just "/", depending on system supporting just one of allocation or monitoring) instead of "uninitialized".

To me, showing the default group would be confusing. It could give the impression that only the default group is associated with the [inherit] mode, even when multiple resource groups exist.

Quoted 10 lines

Quoted 9 lines

When the default changes to assign_global_enable_per_cpu:

# cat info/kernel_mode
inherit [assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=ctrl_mon1//]

Display the second mode with properties only when group is associated with it?

Quoted 2 lines

Please consider this from user space side. The user needs to enable the mode. How will the user know which properties are available and what the defaults are?

To me, this may not be necessary. This interface is primarily intended for administrators, who are expected to understand the feature and its configuration. The documentation already covers the available modes and their behavior.

Hi Babu,

Quoted 61 lines · Babu Moger

Hi Reinette,

Quoted 57 lines · Reinette Chatre

Hi Babu,

Quoted 43 lines · Babu Moger

Quoted 8 lines · Reinette Chatre

Please always keep in mind all the requirements and use cases we learned about during and after RFC v1 of this work.

For example, we already know that "per group" assignment is something resctrl needs to be ready for. Consider the example in
https://lore.kernel.org/lkml/[email protected]/

There may even be "per task" assignment in the future.

Yes. That is correct.

Quoted 8 lines

Constraining this feature to PLZA will make it harder to enable the capabilities that we know resctrl need to support in the future.

This is how we originally landed on the "global" assignment distinction
(https://lore.kernel.org/lkml/[email protected]/)
"global assignment" should be kept or replaced with a solution that continues to prepare resctrl for these other capabilities.

Yes. Makes sense.

Quoted 10 lines

I am not able to see how resctrl could support "per group" assignment with the interface you propose above. If I am missing this, please highlight the solution.

resctrl may need to explicitly split kernel mode from kernel mode properties. For example, below shows an "assign_global_enable_per_cpu" as the kernel mode, now with three properties:
- "ctrl" - could be "assign" or "inherit"
- "mon" - could be "assign" or "inherit"
- "group" - required if "ctrl" or "mon" is set to "assign"

ok.

Quoted 4 lines

      # cat info/kernel_mode
      [inherit]
      assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=uninitialized

Quoted 6 lines

Shouldn't this be like below when default is inherit?

# cat info/kernel_mode
[inherit]
assign_global_enable_per_cpu

I think it will be useful to let the interface:
  (a) show to user space which properties are available for each supported mode, and
  (b) show user space what the default value of those properties will be if they are not set when the associated mode is enabled.

Quoted 1 line

The "inherit" is the default property if it is not explicitly set. Right?

"property" is different from "kernel mode"

Each "kernel mode" can have zero or more properties.
"inherit" is the default "kernel mode", but it could have a better/more descriptive name. For example, "inherit_from_user" or ...?

Quoted 10 lines

# cat info/kernel_mode
[inherit]
assign_global_enable_per_cpu:ctrl=inherit;mon=inherit;group=uninitialized

If the intention is to display all supported values for each property, then we should do so consistently for all properties. For example:

No. The intention is not to display all supported values for properties of the different kernel modes. Just display which properties are supported and what value resctrl would use if the user enables that mode without providing a value for a particular property. There may be properties that could have values for which it will be difficult to provide all supported values.

For example, if "kernel_mode" contains:

       # cat info/kernel_mode
       [inherit]
       assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=//

Then user space knows that if they enable "assign_global_enable_per_cpu" kernel mode without providing any properties then all kernel work will use the default resource group's allocation and monitoring. If that is not what user space wants then they can change the value of only the properties they need to change.

Quoted 14 lines

# cat info/kernel_mode
[inherit]
assign_global_enable_per_cpu:ctrl=inherit,assign;mon=inherit,assign;group=uninitialized

Quoted 5 lines

To (b), since the default resource group is used as default when the group is not provided it may be better to use "//" (or just "/", depending on system supporting just one of allocation or monitoring) instead of "uninitialized".

Quoted 3 lines

To me, showing the default group would be confusing. It could give the impression that only the default group is associated with the [inherit] mode, even when multiple resource groups exist.

I do not see how default group is associated with the "inherit" mode since inherit mode does not have a "group" property?

Quoted 5 lines · Reinette Chatre

Quoted 3 lines · Babu Moger

On 8/13/26 10:55, Reinette Chatre wrote:

The "inherit" is the default property if it is not explicitly set. Right?

Quoted 5 lines

"property" is different from "kernel mode"

Each "kernel mode" can have zero or more properties.
"inherit" is the default "kernel mode", but it could have a better/more descriptive name. For example, "inherit_from_user" or ...?

Or "user_inherit_kernel" ?

Quoted 16 lines

Quoted 8 lines

# cat info/kernel_mode
[inherit]
assign_global_enable_per_cpu:ctrl=inherit;mon=inherit;group=uninitialized

If the intention is to display all supported values for each property, then we should do so consistently for all properties. For example:

No. The intention is not to display all supported values for properties of the different kernel modes. Just display which properties are supported and what value resctrl would use if the user enables that mode without providing a value for a particular property. There may be properties that could have values for which it will be difficult to provide all supported values.

For example, if "kernel_mode" contains:

Quoted 8 lines

       # cat info/kernel_mode
       [inherit]
       assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=//

Then user space knows that if they enable "assign_global_enable_per_cpu" kernel mode without providing any properties then all kernel work will use the default resource group's allocation and monitoring. If that is not what user space wants then they can change the value of only the properties they need to change.

That sounds reasonable.

When the group is bound to the global mode,

# cat info/kernel_mode
  inherit
  [assign_global_enable_per_cpu:ctrl=assign;group=ctrl1//]

Hi Babu,

Quoted 12 lines · Babu Moger

Quoted 10 lines · Reinette Chatre

Quoted 3 lines · Babu Moger

On 8/13/26 10:55, Reinette Chatre wrote:

The "inherit" is the default property if it is not explicitly set. Right?

"property" is different from "kernel mode"

Each "kernel mode" can have zero or more properties.
"inherit" is the default "kernel mode", but it could have a better/more descriptive name. For example, "inherit_from_user" or ...?

Quoted 1 line

Or "user_inherit_kernel" ?

nit: to me this sounds as though user space inherits from kernel.

Also keep in mind that the filename is already "kernel_mode" so any text would be interpreted within that context so repeating "kernel" may not be necessary.

Quoted 29 lines

Quoted 18 lines

Quoted 10 lines

# cat info/kernel_mode
[inherit]
assign_global_enable_per_cpu:ctrl=inherit;mon=inherit;group=uninitialized

If the intention is to display all supported values for each property, then we should do so consistently for all properties. For example:

No. The intention is not to display all supported values for properties of the different kernel modes. Just display which properties are supported and what value resctrl would use if the user enables that mode without providing a value for a particular property. There may be properties that could have values for which it will be difficult to provide all supported values.

For example, if "kernel_mode" contains:

Quoted 8 lines

        # cat info/kernel_mode
        [inherit]
        assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=//

Then user space knows that if they enable "assign_global_enable_per_cpu" kernel mode without providing any properties then all kernel work will use the default resource group's allocation and monitoring. If that is not what user space wants then they can change the value of only the properties they need to change.

That sounds reasonable.

Quoted 6 lines

When the group is bound to the global mode,

# cat info/kernel_mode
   inherit
   [assign_global_enable_per_cpu:ctrl=assign;group=ctrl1//]

Looks good to me (while ignoring the "inherit" TBD naming change).

Kernel-mode policies defined by enum resctrl_kernel_mode must be applied to each affected CPU whenever a policy is selected or its scope changes. Generic resctrl therefore requires an architecture-specific interface to program allocation and monitoring associations in hardware across a given CPU mask.

Introduce a helper, resctrl_arch_configure_kmode(), to handle kernel-mode programming. On x86/AMD systems, this helper programs the MSR_IA32_PQR_PLZA_ASSOC register on all online CPUs in the specified mask via on_each_cpu_mask(). Also provide a no-op stub for MPAM systems.

Generic resctrl does not invoke this hook yet; it will be used when user space selects a kernel-mode policy or updates the associated CPU set.

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

---
v4: Added assign_mon parameter in resctrl_arch_configure_kmode() to program the RMID
as discussed in below.
https://lore.kernel.org/lkml/[email protected]/
Changed cpumask type to "const struct cpumask *cpu_mask".
Added MPAM stub to avoid any linking issues when resctrl_arch_configure_kmode() is called from FS layer. Thanks to Qinyun.
Re-wrote the changelog to be generic.
Updated code comments.

v3: Removed task based PLZA implementation so related changes are removed.
Removed handling of rmid_en as it is not required. The group type assigned will be different so the monitoring part is already taken care. Updated the change log with details.
Removed resctrl_arch_set_kmode() as arch only provides the modes supported. It is FS which decided which mode to apply.

v2: Updated the commit message to include the sequence of steps to enable PLZA.
Added mode code comments for clarity.
Added kmode to functin names to be generic.

---
  arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 36 +++++++++++++++++++++++
  drivers/resctrl/mpam_resctrl.c            |  5 ++++
  include/linux/resctrl.h                   | 15 ++++++++++
  3 files changed, 56 insertions(+)

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

index b20e705606b8..025f139434f2 100644
@@ -131,3 +131,39 @@ int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable)
 

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

Kernel-mode policies defined by enum resctrl_kernel_mode must be applied to

each affected CPU whenever a policy is selected or its scope changes.

Generic resctrl therefore requires an architecture-specific interface to program allocation and monitoring associations in hardware across a given CPU mask.

Introduce a helper, resctrl_arch_configure_kmode(), to handle kernel-mode programming. On x86/AMD systems, this helper programs the MSR_IA32_PQR_PLZA_ASSOC register on all online CPUs in the specified mask via on_each_cpu_mask(). Also provide a no-op stub for MPAM systems.

Generic resctrl does not invoke this hook yet; it will be used when user space selects a kernel-mode policy or updates the associated CPU set.

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

---
v4: Added assign_mon parameter in resctrl_arch_configure_kmode() to program the RMID
as discussed in below.
https://lore.kernel.org/lkml/[email protected]/
Changed cpumask type to "const struct cpumask *cpu_mask".
Added MPAM stub to avoid any linking issues when resctrl_arch_configure_kmode() is called from FS layer. Thanks to Qinyun.
Re-wrote the changelog to be generic.
Updated code comments.

v3: Removed task based PLZA implementation so related changes are removed.
Removed handling of rmid_en as it is not required. The group type assigned will be different so the monitoring part is already taken care. Updated the change log with details.
Removed resctrl_arch_set_kmode() as arch only provides the modes supported. It is FS which decided which mode to apply.

v2: Updated the commit message to include the sequence of steps to enable PLZA.
Added mode code comments for clarity.
Added kmode to functin names to be generic.

---
 arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 36 +++++++++++++++++++++++
 drivers/resctrl/mpam_resctrl.c            |  5 ++++
 include/linux/resctrl.h                   | 15 ++++++++++
 3 files changed, 56 insertions(+)

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

index b20e705606b8..025f139434f2 100644
@@ -131,3 +131,39 @@ int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable)
 
 	return 0;
 }
+
+static void resctrl_kmode_set_one_amd(void *arg)
+{
+	union msr_pqr_plza_assoc *plza = arg;
+
+	wrmsrq(MSR_IA32_PQR_PLZA_ASSOC, plza->full);
+}
+
+/*
+ * Program Privilege Level Zero Association (PLZA) on @cpu_mask.
+ *
+ * When @enable is true, CPL 0 allocation traffic on the targeted CPUs uses
+ * @closid from MSR_IA32_PQR_PLZA_ASSOC instead of the CLOSID from
+ * MSR_IA32_PQR_ASSOC. Monitoring is redirected to @rmid only when
+ * @assign_mon is true; otherwise kernel-mode monitoring continues to use the
+ * RMID associated with the current task.
+ *
+ * @cpu_mask:	CPUs whose PLZA MSR should be updated.
+ * @closid:	CLOSID to use for kernel-mode allocation when PLZA is enabled.
+ * @rmid:	RMID to use for kernel-mode monitoring when @assign_mon is true.
+ * @assign_mon:	Whether PLZA should provide the kernel-mode RMID.
+ * @enable:	Whether PLZA should provide the kernel-mode association.
+ */
+void resctrl_arch_configure_kmode(const struct cpumask *cpu_mask, u32 closid, u32 rmid,
+				  bool assign_mon, bool enable)
+{
+	union msr_pqr_plza_assoc plza = { 0 };
+
+	plza.split.rmid = rmid;
+	plza.split.rmid_en = assign_mon;
+	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);
+}

drivers/resctrl/mpam_resctrl.c +5 -0

index 226ff6f532fa..630b6cfc0269 100644
@@ -158,6 +158,11 @@ bool resctrl_arch_get_io_alloc_enabled(struct rdt_resource *r)
 	return false;
 }
 
+void resctrl_arch_configure_kmode(const struct cpumask *cpu_mask, u32 closid,
+				  u32 rmid, bool assign_mon, bool enable)
+{
+}
+
 void resctrl_arch_pre_mount(void)
 {
 }

include/linux/resctrl.h +0 -0

index c7abed51cd5f..47db34dd167e 100644

Hi Babu,

Quoted 1 line · Babu Moger

Kernel-mode policies defined by enum resctrl_kernel_mode must be applied to

"Kernel-mode policies" -> "Kernel modes"?

Quoted 2 lines

each affected CPU whenever a policy is selected or its scope changes.

What is an "affected CPU"?

policy -> "mode"? or rather: "whenever a policy is selected or its scope changes" -> "whenever user space switches the kernel mode or changes which CPUs are associated with the active kernel mode"?

Quoted 4 lines

Generic resctrl therefore requires an architecture-specific interface to program allocation and monitoring associations in hardware across a given CPU mask.

Quoted 4 lines

Introduce a helper, resctrl_arch_configure_kmode(), to handle kernel-mode programming. On x86/AMD systems, this helper programs the MSR_IA32_PQR_PLZA_ASSOC register on all online CPUs in the specified mask via on_each_cpu_mask(). Also provide a no-op stub for MPAM systems.

No need to describe the code details, please just make it high level of what the code accomplished as opposed to describing the code self.

Quoted 4 lines

Generic resctrl does not invoke this hook yet; it will be used when user space selects a kernel-mode policy or updates the associated CPU set.

Looking ahead how this arch helper is used it really is a "one size fits all" based on what AMD requires. Specifically, as I see it this architecture helper is called under three very different scenarios:
- A new kernel mode is activated
- CPUs are added/removed from an active kernel mode
- A kernel mode is de-activated.

There is no way for an architecture to distinguish these three scenarios. An architecture that, for example, needs to do some arch-specific init to support a particular mode will not know when it should do this.

This "one size fits all" may be ok for an initial approach until we learn what other architectures require, but the API needs to be clear on when and how architecture can expect it to be called from resctrl fs.

Consider, for example, the API description containing text/contract like:
- If a per-cpu kernel mode is active when user space switches to a new per-cpu kernel mode then resctrl_arch_configure_kmode() will first be called to de-activate the active kernel mode on all CPUs that the kernel mode is active on.
- When user space switches to a new per-cpu kernel mode then resctrl_arch_configure_kmode() is called with cpu_online_mask.
- When user space adds a CPU to an active per-cpu kernel mode ...
- When user space removes a CPU from to an active per-cpu kernel mode ...
- resctrl fs will always provide the same closid, rmid, and "assign_mon" parameters when activating a kernel mode, all interactions (adding/removing CPU) while the kernel mode is active, as well as when de-activating the kernel mode.

Quoted 54 lines

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

---
v4: Added assign_mon parameter in resctrl_arch_configure_kmode() to program the RMID
as discussed in below.
https://lore.kernel.org/lkml/[email protected]/
Changed cpumask type to "const struct cpumask *cpu_mask".
Added MPAM stub to avoid any linking issues when resctrl_arch_configure_kmode() is called from FS layer. Thanks to Qinyun.
Re-wrote the changelog to be generic.
Updated code comments.

v3: Removed task based PLZA implementation so related changes are removed.
Removed handling of rmid_en as it is not required. The group type assigned will be different so the monitoring part is already taken care. Updated the change log with details.
Removed resctrl_arch_set_kmode() as arch only provides the modes supported. It is FS which decided which mode to apply.

v2: Updated the commit message to include the sequence of steps to enable PLZA.
Added mode code comments for clarity.
Added kmode to functin names to be generic.

---
  arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 36 +++++++++++++++++++++++
  drivers/resctrl/mpam_resctrl.c            |  5 ++++
  include/linux/resctrl.h                   | 15 ++++++++++
  3 files changed, 56 insertions(+)

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

index b20e705606b8..025f139434f2 100644
@@ -131,3 +131,39 @@ int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable)
 
  	return 0;
  }
+
+static void resctrl_kmode_set_one_amd(void *arg)
+{
+	union msr_pqr_plza_assoc *plza = arg;
+
+	wrmsrq(MSR_IA32_PQR_PLZA_ASSOC, plza->full);
+}
+
+/*
+ * Program Privilege Level Zero Association (PLZA) on @cpu_mask.
+ *
+ * When @enable is true, CPL 0 allocation traffic on the targeted CPUs uses
+ * @closid from MSR_IA32_PQR_PLZA_ASSOC instead of the CLOSID from
+ * MSR_IA32_PQR_ASSOC. Monitoring is redirected to @rmid only when
+ * @assign_mon is true; otherwise kernel-mode monitoring continues to use the
+ * RMID associated with the current task.
+ *

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

Quoted 8 lines

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

+ * @cpu_mask:	CPUs whose PLZA MSR should be updated.
+ * @closid:	CLOSID to use for kernel-mode allocation when PLZA is enabled.
+ * @rmid:	RMID to use for kernel-mode monitoring when @assign_mon is true.
+ * @assign_mon:	Whether PLZA should provide the kernel-mode RMID.
+ * @enable:	Whether PLZA should provide the kernel-mode association.
+ */
+void resctrl_arch_configure_kmode(const struct cpumask *cpu_mask, u32 closid, u32 rmid,
+				  bool assign_mon, bool enable)

Quoted 33 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 = assign_mon;
+	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);
+}

drivers/resctrl/mpam_resctrl.c +5 -0

index 226ff6f532fa..630b6cfc0269 100644
@@ -158,6 +158,11 @@ bool resctrl_arch_get_io_alloc_enabled(struct rdt_resource *r)
  	return false;
  }
 
+void resctrl_arch_configure_kmode(const struct cpumask *cpu_mask, u32 closid,
+				  u32 rmid, bool assign_mon, bool enable)
+{
+}
+
  void resctrl_arch_pre_mount(void)
  {
  }

include/linux/resctrl.h +0 -0

index c7abed51cd5f..47db34dd167e 100644
@@ -734,6 +734,21 @@ enum resctrl_kernel_mode {
 

include/linux/resctrl.h enum resctrl_kernel_mode { · line 740

Quoted 6 lines

include/linux/resctrl.h +4 -0

  #define RESCTRL_NUM_KERNEL_MODES (RESCTRL_KMODE_LAST + 1)
 
+/**
+ * resctrl_arch_configure_kmode() - Program kernel-mode association on CPUs
+ * @cpu_mask:	CPUs to update; the architecture applies the change on the
+ *		online subset of this mask.

Could architecture not expect cpu_mask to only contain online CPUs ?

include/linux/resctrl.h enum resctrl_kernel_mode { · line 741

Quoted 2 lines

include/linux/resctrl.h +1 -0

+ * @closid:	Allocation class for kernel-mode traffic. On x86 this is the

"Allocation class" ? Care should only be taken when using "closid" outside of kernel. Please see all the other examples of arch API in this file that uses closid.

include/linux/resctrl.h enum resctrl_kernel_mode { · line 743

Quoted 3 lines

include/linux/resctrl.h +2 -0

+ *		CLOSID programmed when allocation is assigned for kernel work.
+ * @rmid:	Monitoring context for kernel-mode traffic. On x86 this is the

"Monitoring context" ? At this time it is quite clear to architectures how to do needed mapping.

Some archs will use closid/rmid separately, others will consider them together.

include/linux/resctrl.h enum resctrl_kernel_mode { · line 745

Quoted 3 lines

include/linux/resctrl.h +2 -0

+ *		RMID programmed when monitoring is assigned for kernel work.
+ * @assign_mon:	true to assign @rmid for kernel work; false to inherit

This is where the only distinction is required when considering other architectures. Note that, from user space perspective, it is a monitoring group, potentially identified with both closid/rmid that is assigned, not just an rmid.
This is thus not a request to "assign @rmid for kernel work" but instead something like "kernel work should be monitored by resource group identified by @rmid, or both @closid and @rmid, depending on the architecture"

include/linux/resctrl.h enum resctrl_kernel_mode { · line 747

Quoted 3 lines

include/linux/resctrl.h +2 -0

+ *		monitoring from the user task.
+ * @enable:	true to enable kernel-mode association on the targeted CPUs.

"the targeted CPUs" -> CPUs in @cpu_mask?
Please be explicit what is expected from architecture when "false" is provided.

Hi Reinette,

Quoted 6 lines · Reinette Chatre

Hi Babu,

Quoted 1 line · Babu Moger

Kernel-mode policies defined by enum resctrl_kernel_mode must be applied to

"Kernel-mode policies" -> "Kernel modes"?

Ack.

Quoted 1 line

Quoted 4 lines

Quoted 1 line

each affected CPU whenever a policy is selected or its scope changes.

What is an "affected CPU"?

Kernel mode policies defined by enum resctrl_kernel_mode must be applied to each CPU whenever user space changes the kernel mode or modifies the CPUs associated with the active kernel mode.

Hi Babu,

Quoted 12 lines · Babu

Hi Reinette,

Quoted 6 lines · Reinette Chatre

Hi Babu,

Quoted 1 line · Babu Moger

Kernel-mode policies defined by enum resctrl_kernel_mode must be applied to

"Kernel-mode policies" -> "Kernel modes"?

Ack.

Quoted 1 line

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

each affected CPU whenever a policy is selected or its scope changes.

What is an "affected CPU"?

Kernel mode policies defined by enum resctrl_kernel_mode must be applied to each CPU whenever user space changes the kernel mode or modifies the CPUs associated with the active kernel mode.

ok, could this thus just be "each CPU"? I find a lot of text in this series use unnecessary adjectives and then makes it worse by using inconsistent adjectives. This makes the text difficult to follow since it is never obvious if the text refers to the same thing as before. Please remove unnecessary words so that the writing becomes concise and easier to follow.

Architectures need a way to advertise which kernel-mode resctrl policies

they support before generic resctrl exposes those policies through the

filesystem.

Add the struct resctrl_kmode_cfg to define the default mode statically, and introduce resctrl_set_kmode_support() so architecture code can register supported kernel-mode policies during resctrl initialization. The INHERIT_CTRL_AND_MON policy is supported by default, so architectures only need to register any additional modes.

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

---
v4: New patch to initialize supported kernel-mode's.
https://lore.kernel.org/lkml/[email protected]/
Changed the kmode_cur to enum resctrl_kernel_mode in resctrl_kmode_cfg. Moved the resctrl_kmode_cfg to filesystem code.

---
 fs/resctrl/internal.h   | 12 ++++++++++++
 fs/resctrl/rdtgroup.c   | 23 +++++++++++++++++++++++
 include/linux/resctrl.h | 10 ++++++++++
 3 files changed, 45 insertions(+)

fs/resctrl/internal.h +0 -0

index 48af75b9dc85..178126bb2da5 100644

fs/resctrl/internal.h +3 -0

+	enum resctrl_kernel_mode	kmode_cur;
+	struct rdtgroup			*k_rdtgrp;
+};
 extern struct mutex rdtgroup_mutex;
 
 static inline const char *rdt_kn_name(const struct kernfs_node *kn)

fs/resctrl/rdtgroup.c +0 -0

index cc9966ff6cdf..0ee0dfaf9065 100644

Hi Babu,

Quoted 1 line · Babu Moger

Architectures need a way to advertise which kernel-mode resctrl policies

"kernel-mode resctrl policies" -> "kernel modes"?

Quoted 2 lines

they support before generic resctrl exposes those policies through the

"policies" -> "modes"
(this is related to the earlier "use consistent terminology comment" I will stop highlighting instances)

Quoted 8 lines

filesystem.

Add the struct resctrl_kmode_cfg to define the default mode statically, and introduce resctrl_set_kmode_support() so architecture code can register supported kernel-mode policies during resctrl initialization. The INHERIT_CTRL_AND_MON policy is supported by default, so architectures only need to register any additional modes.

Please keep changelog high level and not describe the code that can be seen from patch. When doing so, please write in imperative tone.

Quoted 22 lines

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

---
v4: New patch to initialize supported kernel-mode's.
https://lore.kernel.org/lkml/[email protected]/
Changed the kmode_cur to enum resctrl_kernel_mode in resctrl_kmode_cfg. Moved the resctrl_kmode_cfg to filesystem code.

---
  fs/resctrl/internal.h   | 12 ++++++++++++
  fs/resctrl/rdtgroup.c   | 23 +++++++++++++++++++++++
  include/linux/resctrl.h | 10 ++++++++++
  3 files changed, 45 insertions(+)

fs/resctrl/internal.h +0 -0

index 48af75b9dc85..178126bb2da5 100644
@@ -314,6 +314,18 @@ struct mbm_state {
  	u32	prev_bw;
  };
 

fs/resctrl/internal.h struct mbm_state { · line 318

Quoted 2 lines

fs/resctrl/internal.h +2 -0

+/**
+ * struct resctrl_kmode_cfg - Kernel-mode policy snapshot from architecture

"policy snapshot"? what does this mean? This is not just from architecture either.

fs/resctrl/internal.h struct mbm_state { · line 321

Quoted 4 lines

fs/resctrl/internal.h +3 -0

+ * @kmode:	Bitmap of supported &enum resctrl_kernel_mode values. Each
+ *		supported mode is represented by BIT(mode).
+ * @kmode_cur:	Currently selected kernel-mode policy.

How about "Active kernel mode"?

fs/resctrl/internal.h struct mbm_state { · line 322

Quoted 2 lines

fs/resctrl/internal.h +1 -0

+ * @k_rdtgrp:	Resource group backing global-assign modes when applicable;

(stray semi-colon)

fs/resctrl/internal.h struct mbm_state { · line 325

Quoted 4 lines

fs/resctrl/internal.h +3 -0

+ */
+struct resctrl_kmode_cfg {
+	unsigned long			kmode;

How about "kmode_sup" to complement the "kmode_cur"?

To make it obvious this is a bitmap you can use something like:
DECLARE_BITMAP(kmode_sup, RESCTRL_NUM_KERNEL_MODES)

Quoted 16 lines

fs/resctrl/internal.h +3 -0

+	enum resctrl_kernel_mode	kmode_cur;
+	struct rdtgroup			*k_rdtgrp;
+};
  extern struct mutex rdtgroup_mutex;
 
  static inline const char *rdt_kn_name(const struct kernfs_node *kn)

fs/resctrl/rdtgroup.c +0 -0

index cc9966ff6cdf..0ee0dfaf9065 100644
@@ -78,6 +78,16 @@ static void mon_put_kn_priv(void);
 
  struct dentry *debugfs_resctrl;
 

fs/resctrl/rdtgroup.c static void mon_put_kn_priv(void); · line 83

Quoted 3 lines

fs/resctrl/rdtgroup.c +3 -0

+/*
+ * Global kernel-mode resctrl policy. Architectures add supported modes before
+ * resctrl is mounted; @kmode_cur tracks the active policy after user selection.

ah - above it is referred to as "active". I find "active" to be more descriptive than "selected" as highlighted above. The "after user selection" seems distracting. "@kmode_cur is the active kernel mode" is all that is necessary, no?

fs/resctrl/rdtgroup.c static void mon_put_kn_priv(void); · line 89

Quoted 7 lines

fs/resctrl/rdtgroup.c +6 -0

+ */
+static struct resctrl_kmode_cfg resctrl_kcfg = {
+	.kmode = BIT(INHERIT_CTRL_AND_MON),
+	.kmode_cur = INHERIT_CTRL_AND_MON,
+	.k_rdtgrp = NULL
+};

This initialization needs to be reconsidered to take into account that system may not support allocation or monitoring.

Generic resctrl exposes kernel-mode policy options via sysfs only after architectures indicate the set of supported policies using resctrl_set_kmode_support().

On AMD systems, Privilege Level Zero Association (PLZA) provides two global assignment modes:

- GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU: Assigns the resource allocation for kernel work; but monitoring is inherited from the user task.
- GLOBAL_ASSIGN_CTRL_ASSIGN_MON_PER_CPU: Assigns a dedicated resource allocation and monitoring for kernel work.

Expose these modes during resource discovery when PLZA is available.

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

---
v4: New patch to set the supported features during arch init.

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

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

index 27e09cded829..df7e19fe6007 100644
@@ -962,6 +962,9 @@ static __init bool get_rdt_alloc_resources(void)
  	if (get_slow_mem_config())
  		ret = true;
 
+	if (ret && rdt_cpu_has(X86_FEATURE_PLZA))
+		resctrl_set_kmode_support(GLOBAL_ASSIGN_CTRL_INHERIT_MON_PER_CPU);
+
  	return ret;
  }
 

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

index 27e09cded8299..df7e19fe60078 100644

Kernel-mode resctrl policies define how kernel work is associated with resource allocation and monitoring relative to the user task. Generic resctrl tracks the supported policies, the active policy, and the resctrl group backing any global assignment policy. However, this information is not exposed to user space.

Introduce a new resctrl file, info/kernel_mode, to expose the global kernel-mode policy and its associated resource group (when applicable). This read-only sysfs file lists all supported policies, one per line, and highlights the active policy using square brackets.

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

fs/resctrl/rdtgroup.c +20 -0

+/**
+ * resctrl_kernel_mode_show() - Display supported and active kernel-mode policies
+ * @of: kernfs open file
+ * @seq: output seq_file
+ * @v: unused
+ *
+ * Displays one line per mode set in resctrl_kcfg.kmode. Bracket the active
+ * policy (resctrl_kcfg.kmode_cur).
+ *
+ * INHERIT_CTRL_AND_MON is displayed as "[inherit_ctrl_and_mon]" when active
+ * or "inherit_ctrl_and_mon" when supported but inactive, with no :group=
+ * suffix in either case.
+ *
+ * Global-assign modes append :group=. An inactive mode is emitted as
+ * "<mode>:group=uninitialized". An active mode with a bound group is emitted
+ * as "[<mode>:group=<ctrl>/<mon>/]", where <ctrl>/<mon>/ is derived from
+ * resctrl_kcfg.k_rdtgrp.
+ *
+ * Return: 0 on success, or -ENOENT on error.
+ */

fs/resctrl/rdtgroup.c +11 -0

+	for (mode = 0; mode < RESCTRL_NUM_KERNEL_MODES; mode++) {
+		if (!test_bit(mode, &resctrl_kcfg.kmode))
+			continue;
+
+		active = (resctrl_kcfg.kmode_cur == mode);
+
+		if (mode == INHERIT_CTRL_AND_MON) {
+			seq_printf(seq, active ? "[%s]\n" : "%s\n",
+				   resctrl_mode_str[mode]);
+			continue;
+		}

fs/resctrl/rdtgroup.c +19 -0

+		}
+
+		ctrl = "";
+		mon = "";
+		if (rdtgrp->type == RDTMON_GROUP) {
+			ctrl = rdt_kn_name(rdtgrp->mon.parent->kn);
+			mon = rdt_kn_name(rdtgrp->kn);
+		} else {
+			ctrl = rdt_kn_name(rdtgrp->kn);
+		}
+		seq_printf(seq, "[%s:group=%s/%s/]\n",
+			   resctrl_mode_str[mode], ctrl, mon);
+	}
+
+out_unlock:
+	mutex_unlock(&rdtgroup_mutex);
+	return ret;
+}
+
 void *rdt_kn_parent_priv(struct kernfs_node *kn)
 {
 	/*

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

Hi Babu,

Quoted 6 lines · Babu Moger

Kernel-mode resctrl policies define how kernel work is associated with resource allocation and monitoring relative to the user task. Generic resctrl tracks the supported policies, the active policy, and the resctrl group backing any global assignment policy. However, this information is not exposed to user space.

Quoted 4 lines

Introduce a new resctrl file, info/kernel_mode, to expose the global kernel-mode policy and its associated resource group (when applicable). This read-only sysfs file lists all supported policies, one per line, and highlights the active policy using square brackets.

(please rewrite with consistent terms)

Quoted 25 lines

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

fs/resctrl/rdtgroup.c +20 -0

+/**
+ * resctrl_kernel_mode_show() - Display supported and active kernel-mode policies
+ * @of: kernfs open file
+ * @seq: output seq_file
+ * @v: unused
+ *
+ * Displays one line per mode set in resctrl_kcfg.kmode. Bracket the active
+ * policy (resctrl_kcfg.kmode_cur).
+ *
+ * INHERIT_CTRL_AND_MON is displayed as "[inherit_ctrl_and_mon]" when active
+ * or "inherit_ctrl_and_mon" when supported but inactive, with no :group=
+ * suffix in either case.
+ *
+ * Global-assign modes append :group=. An inactive mode is emitted as
+ * "<mode>:group=uninitialized". An active mode with a bound group is emitted
+ * as "[<mode>:group=<ctrl>/<mon>/]", where <ctrl>/<mon>/ is derived from
+ * resctrl_kcfg.k_rdtgrp.
+ *
+ * Return: 0 on success, or -ENOENT on error.
+ */

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

Quoted 10 lines

fs/resctrl/rdtgroup.c +10 -0

+static int resctrl_kernel_mode_show(struct kernfs_open_file *of,
+				    struct seq_file *seq, void *v)
+{
+	enum resctrl_kernel_mode mode;
+	struct rdtgroup *rdtgrp;
+	const char *ctrl, *mon;
+	bool active;
+	int ret = 0;
+
+	mutex_lock(&rdtgroup_mutex);

The changes to make resctrl more robust have since been merged. Please consider:
2d77f9768850 ("fs/resctrl: Prevent deadlock and use-after-free in info file handlers")

When you rebase, please use the new info_kn_lock()/info_kn_unlock() helpers.

Quoted 16 lines

fs/resctrl/rdtgroup.c +15 -0

+	for (mode = 0; mode < RESCTRL_NUM_KERNEL_MODES; mode++) {
+		if (!test_bit(mode, &resctrl_kcfg.kmode))
+			continue;
+
+		active = (resctrl_kcfg.kmode_cur == mode);
+
+		if (mode == INHERIT_CTRL_AND_MON) {
+			seq_printf(seq, active ? "[%s]\n" : "%s\n",
+				   resctrl_mode_str[mode]);
+			continue;
+		}
+
+		if (!active) {
+			seq_printf(seq, "%s:group=uninitialized\n",
+				   resctrl_mode_str[mode]);

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

Quoted 6 lines

fs/resctrl/rdtgroup.c +6 -0

+			continue;
+		}
+
+		/*
+		 * There should be a valid group when any of the global
+		 * assign mode is active; otherwise, report an error.

This would indicate a resctrl bug, no?

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

Quoted 6 lines

fs/resctrl/rdtgroup.c +5 -0

+		 */
+		rdtgrp = resctrl_kcfg.k_rdtgrp;
+		if (!rdtgrp) {
+			ret = -ENOENT;
+			goto out_unlock;

If this fails there needs to be content in last_cmd_status. Otherwise this fails and then last_cmd_status reads "ok" or worse .. an old failure message.

Quoted 1 line · Reinette Chatre

On 7/7/26 2:50 PM, Babu Moger wrote:

Quoted 6 lines

Quoted 5 lines

+         */
+        rdtgrp = resctrl_kcfg.k_rdtgrp;
+        if (!rdtgrp) {
+            ret = -ENOENT;
+            goto out_unlock;

Quoted 2 lines

If this fails there needs to be content in last_cmd_status. Otherwise this fails and then last_cmd_status reads "ok" or worse .. an old failure message.

if (WARN_ON(!rdtgrp)) { rdt_last_cmd_puts("Invalid kernel mode group\n"); ret = -ENOENT;
    goto out_unlock;
}

Hi Babu,

Quoted 2 lines · Babu

Quoted 1 line · Reinette Chatre

On 7/7/26 2:50 PM, Babu Moger wrote:

...

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

+         */
+        rdtgrp = resctrl_kcfg.k_rdtgrp;
+        if (!rdtgrp) {
+            ret = -ENOENT;
+            goto out_unlock;

If this fails there needs to be content in last_cmd_status. Otherwise this fails and then last_cmd_status reads "ok" or worse .. an old failure message.

Quoted 5 lines

if (WARN_ON(!rdtgrp)) {
    rdt_last_cmd_puts("Invalid kernel mode group\n"); ret = -ENOENT;
    goto out_unlock;
}

It is not clear to me why the WARN_ON() was added. Is the resource group not being associated with kernel mode not a legitimate scenario if the kernel mode group was re-assigned while the reader of this file was blocked on the mutex?

Hi Reinette,

Quoted 17 lines · Reinette Chatre

Hi Babu,

Quoted 2 lines · Babu

Quoted 1 line · Reinette Chatre

On 7/7/26 2:50 PM, Babu Moger wrote:

...

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

+         */
+        rdtgrp = resctrl_kcfg.k_rdtgrp;
+        if (!rdtgrp) {
+            ret = -ENOENT;
+            goto out_unlock;

If this fails there needs to be content in last_cmd_status. Otherwise this fails and then last_cmd_status reads "ok" or worse .. an old failure message.

Quoted 9 lines

Quoted 5 lines

if (WARN_ON(!rdtgrp)) { rdt_last_cmd_puts("Invalid kernel mode group\n"); ret = -ENOENT;
     goto out_unlock;
}

It is not clear to me why the WARN_ON() was added. Is the resource group not being associated with kernel mode not a legitimate scenario if the kernel mode group was re-assigned while the reader of this file was blocked on the mutex?

A valid group is required whenever any global mode is enabled. Reaching this condition without one is unexpected and should be treated as a bug.

To help catch this, I added a WARN_ON() to log the issue. I think updating last_cmd_status is reasonable as well and should provide the necessary user-visible error indication.

Kernel-mode resctrl policies allow kernel work to be associated with a specific rdtgroup, optionally restricted to a subset of online CPUs.

While user space can query the active kernel-mode policy and its associated rdtgroup through info/kernel_mode, it currently lacks visibility into the CPU scope of that binding.

Introduce read-only kmode_cpus and kmode_cpus_list files for each rdtgroup.

These expose rdtgrp->kmode_cpu_mask in both bitmap and range-list formats, consistent with the existing cpus and cpus_list interfaces.

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

---

fs/resctrl/internal.h +0 -0

index 178126bb2da5..12db6933bc54 100644

fs/resctrl/internal.h +2 -0

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

@@ -229,6 +231,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 +9 -0

index 346aa4df62a4..0d5c94169d03 100644
@@ -392,6 +392,37 @@ static int rdtgroup_cpus_show(struct kernfs_open_file *of,
 	return ret;
 }
 
+/*
+ * Display per-rdtgroup CPU bindings for kernel-mode enabled groups.
+ * Supports both "kmode_cpus" (bitmap format) and "kmode_cpus_list"
+ * (range list format); the output format is selected accordingly.
+ *
+ * Returns -ENOENT if the group has been deleted, and -ENODEV for
+ * pseudo-locked groups, which cannot host a kernel-mode binding.
+ */
+static int rdtgroup_kmode_cpus_show(struct kernfs_open_file *of,

fs/resctrl/rdtgroup.c +20 -0

+		} else {
+			seq_printf(s, is_cpu_list(of) ? "%*pbl\n" : "%*pb\n",
+				   cpumask_pr_args(&rdtgrp->kmode_cpu_mask));
+		}
+	} else {
+		ret = -ENOENT;
+	}
+	rdtgroup_kn_unlock(of->kn);
+
+	return ret;
+}
+
 /*
  * Update the PGR_ASSOC MSR on all cpus in @cpu_mask,
  *

@@ -2181,6 +2212,21 @@ static struct rftype res_common_files[] = {
 		.flags		= RFTYPE_FLAGS_CPUS_LIST,
 		.fflags		= RFTYPE_BASE,
 	},
+	{
+		.name		= "kmode_cpus",
+		.mode		= 0444,
+		.kf_ops		= &rdtgroup_kf_single_ops,
+		.seq_show	= rdtgroup_kmode_cpus_show,
+		.fflags		= RFTYPE_BASE,
+	},
+	{

Hi Babu,

Quoted 7 lines · Babu Moger

Kernel-mode resctrl policies allow kernel work to be associated with a specific rdtgroup, optionally restricted to a subset of online CPUs.

While user space can query the active kernel-mode policy and its associated rdtgroup through info/kernel_mode, it currently lacks visibility into the CPU scope of that binding.

Quoted 1 line

Introduce read-only kmode_cpus and kmode_cpus_list files for each rdtgroup.

I think it will be easier to follow if this is deferred to not create these files in all resource groups by default. Instead, at the time they are created it should be obvious that they will only be visible in resource group associated with the active kernel mode.

Quoted 14 lines

These expose rdtgrp->kmode_cpu_mask in both bitmap and range-list formats, consistent with the existing cpus and cpus_list interfaces.

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

---

fs/resctrl/internal.h +0 -0

index 178126bb2da5..12db6933bc54 100644

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

Quoted 5 lines

fs/resctrl/internal.h +2 -0

@@ -216,6 +216,8 @@ 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 bound to a kernel-mode policy
+ * @kmode_cpu_mask:		CPU scope for this group's kernel-mode binding

"CPU scope" could be interpreted in various ways here. Could it be more specific to say something like "CPUs on which kernel mode is active"?

Quoted 38 lines

fs/resctrl/internal.h +2 -0

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

@@ -229,6 +231,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 +18 -0

index 346aa4df62a4..0d5c94169d03 100644
@@ -392,6 +392,37 @@ static int rdtgroup_cpus_show(struct kernfs_open_file *of,
  	return ret;
  }
 
+/*
+ * Display per-rdtgroup CPU bindings for kernel-mode enabled groups.
+ * Supports both "kmode_cpus" (bitmap format) and "kmode_cpus_list"
+ * (range list format); the output format is selected accordingly.
+ *
+ * Returns -ENOENT if the group has been deleted, and -ENODEV for
+ * pseudo-locked groups, which cannot host a kernel-mode binding.
+ */
+static int rdtgroup_kmode_cpus_show(struct kernfs_open_file *of,
+				    struct seq_file *s, void *v)
+{
+	struct rdtgroup *rdtgrp;
+	int ret = 0;
+
+	rdtgrp = rdtgroup_kn_lock_live(of->kn);
+
+	if (rdtgrp) {
+		if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED) {

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

Quoted 1 line

fs/resctrl/rdtgroup.c +1 -0

+			ret = -ENODEV;

sashiko also pointed something related out but it is not clear to me how the different group modes are planned to be accommodated. I think it should be possible to avoid sprinkling these mode checks into user space interactions if it is made explicit that (a) at the time a group is assigned to a kernel mode that group is required to be "shareable", and (b) it is not allowed to change the mode of a group that is assigned to a kernel mode.

Apart from that I do not think a test like this is sufficient to capture the various scenarios that may occur. For example, while waiting for the lock the group assigned to the kernel mode could have been re-assigned. Could a test on rdtgrp->kmode be more robust?

Hi Reinette,

Quoted 10 lines · Reinette Chatre

Hi Babu,

Quoted 7 lines · Babu Moger

Kernel-mode resctrl policies allow kernel work to be associated with a specific rdtgroup, optionally restricted to a subset of online CPUs.

While user space can query the active kernel-mode policy and its associated rdtgroup through info/kernel_mode, it currently lacks visibility into the CPU scope of that binding.

Quoted 6 lines

Quoted 1 line

Introduce read-only kmode_cpus and kmode_cpus_list files for each rdtgroup.

I think it will be easier to follow if this is deferred to not create these files in all resource groups by default. Instead, at the time they are created it should be obvious that they will only be visible in resource group associated with the active kernel mode.

I am not clear on this comment. Do you mean create these files when user associates the group to kernel mode? (during rdtgroup_config_kmode)