[PATCH v2 0/5] x86,fs/resctrl: Cleanups in preparation for multiple controls support

[PATCH v2 0/5] x86,fs/resctrl: Cleanups in preparation for multiple controls support

[Reinette Chatre]

Changes since v1:
  - v1: https://lore.kernel.org/lkml/cover.1788452481.git.reinette.chatre@intel.com/
  - Rebase on x86/cache branch of tip with HEAD at:
      50e5282df427 ("x86,fs/resctrl: Add event group descriptions for Intel Diamond Rapids")
  - Rework all changelogs. Most now explain why each change is safe and why it
    is needed independent of the multiple controls work. (Ben)
  - Make subject lines more specific and fix the prefix of the patch removing
    the non-linear bandwidth delay mapping.
  - Keep the informational message printed when an Intel system with non-linear
    MBA delay values is encountered, rewording it and adding the missing
    newline. Match the related warning to the same wording. (Chenyu)
  - Group the memory bandwidth property assignments during Intel MBA enumeration.
  - Clarify in kernel-doc that the MSR_IA32_L{2,3}_QOS_CFG scope property only
    applies to cache resources.
  - Add Reviewed-by tags from Chenyu and Ben.

Hi Everybody,

For resource allocation resctrl assumes there is only one way to allocate
portions of a resource. That is, every resource supporting allocation has a
single control in the schemata file that user space can use to allocate
portions of that resource.

All architectures supported by resctrl already support, or will soon support,
multiple controls per resource. For example, the memory bandwidth resource may
have a "maximum bandwidth" as well as a "minimum bandwidth" control.

Adding support for multiple controls to resctrl is a major endeavour. The goals
are described in [1] and summarized in the Linux Plumbers Conference 2025
slides [2]. The implementation is in progress, with the most recent PoC
available at [3].

This series contains the preparatory cleanups from the PoC that are ready to be
merged independently of the remaining work:
- Remove the unused support for non-linear Intel MBA delay values, including a
  user space configuration check that can never fail.
- Make the scope of MSR_IA32_L{2,3}_QOS_CFG a private x86 property instead of
  a resctrl filesystem cache property.
- Drop an unnecessary helper and an unnecessary function parameter.

The only intended functional change is a reworded informational message
printed if an Intel system with non-linear MBA delay values is encountered.

Changes since previous postings can be found in the individual patches.

[1] https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/
[2] https://lpc.events/event/19/contributions/2093/attachments/1958/4172/resctrl%20Microconference%20LPC%202025%20Tokyo.pdf
[3] https://lore.kernel.org/lkml/d258a32f-12d5-464d-abe9-4720fb3e44b3@intel.com/

Reinette Chatre (5):
  x86,fs/resctrl: Remove unused non-linear bandwidth delay mapping
  x86,fs/resctrl: Remove unnecessary non-linear MBA configuration check
  x86,fs/resctrl: Move MSR_IA32_L{2,3}_QOS_CFG scope property to x86 resource
  fs/resctrl: Drop unnecessary is_mba_linear() helper
  fs/resctrl: Drop unnecessary parameter from resctrl_io_alloc_parse_line()

 arch/x86/kernel/cpu/resctrl/core.c     | 72 ++++++++------------------
 arch/x86/kernel/cpu/resctrl/internal.h |  4 ++
 arch/x86/kernel/cpu/resctrl/rdtgroup.c |  4 +-
 fs/resctrl/ctrlmondata.c               | 15 ++----
 fs/resctrl/rdtgroup.c                  |  7 +--
 include/linux/resctrl.h                |  7 ---
 6 files changed, 33 insertions(+), 76 deletions(-)


base-commit: 50e5282df427830fcd810e553f0e355d9cccb3e2
-- 
2.55.0

[PATCH v2 1/5] x86,fs/resctrl: Remove unused non-linear bandwidth delay mapping

[Reinette Chatre]

Intel MBA throttles memory bandwidth with delay values, while resctrl
exposes memory bandwidth to user space as a percentage. When delay values
are linear there is a direct mapping between the two. Support for
non-linear delay values would need a pre-calibrated table mapping
percentages to delay values.

Commit

  05b93417ce5b ("x86/intel_rdt/mba: Add primary support for Memory Bandwidth Allocation (MBA)")

added a placeholder for such a table to the resctrl_membw structure, but
the table was never populated and never read. rdt_get_mb_table(), which
would provide it, always fails. As a result, an Intel MBA resource with
non-linear delay values is never marked as capable of allocation, and its
control values are never written to hardware.

Remove the unused mapping table and fold the linear percentage-to-delay
conversion into the function that writes the control values to hardware.

Keep the check that delay values are linear as a defensive measure in
preparation for supporting multiple controls, which turns the memory
bandwidth control into a generic scalar control that indicates whether it
requires linear values.

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
---
Changes since RFC v1:
- Also drop separate delay_bw_map() and instead integrate the only
  mapping to when control value is written.

Changes since RFC v2:
- Rework changelog.

Changes since v1:
- Rewrite changelog, fix subject prefix.
- Match error message about linear support with similar message during
  enumeration added in next patch.
- Add Chenyu's Reviewed-by tag
---
 arch/x86/kernel/cpu/resctrl/core.c | 23 +++++++----------------
 include/linux/resctrl.h            |  2 --
 2 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index 55214d6fdc49..f9677e52790e 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -323,29 +323,20 @@ static void mba_wrmsr_amd(struct msr_param *m)
 		wrmsrq(hw_res->msr_base + i, hw_dom->ctrl_val[i]);
 }
 
-/*
- * Map the memory b/w percentage value to delay values
- * that can be written to QOS_MSRs.
- * There are currently no SKUs which support non linear delay values.
- */
-static u32 delay_bw_map(unsigned long bw, struct rdt_resource *r)
-{
-	if (r->membw.delay_linear)
-		return MAX_MBA_BW - bw;
-
-	pr_warn_once("Non Linear delay-bw map not supported but queried\n");
-	return MAX_MBA_BW;
-}
-
 static void mba_wrmsr_intel(struct msr_param *m)
 {
 	struct rdt_hw_ctrl_domain *hw_dom = resctrl_to_arch_ctrl_dom(m->dom);
 	struct rdt_hw_resource *hw_res = resctrl_to_arch_res(m->res);
 	unsigned int i;
 
-	/*  Write the delay values for mba. */
+	if (!m->res->membw.delay_linear) {
+		pr_warn_once("Non-linear MBA delay values not supported\n");
+		return;
+	}
+
+	/* Program bandwidth percentage mapped to linear delay value. */
 	for (i = m->low; i < m->high; i++)
-		wrmsrq(hw_res->msr_base + i, delay_bw_map(hw_dom->ctrl_val[i], m->res));
+		wrmsrq(hw_res->msr_base + i, MAX_MBA_BW - hw_dom->ctrl_val[i]);
 }
 
 static void cat_wrmsr(struct msr_param *m)
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index 10dfdca7f4bf..b63dc62690ca 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -253,7 +253,6 @@ enum membw_throttle_mode {
  * @throttle_mode:	Bandwidth throttling mode when threads request
  *			different memory bandwidths
  * @mba_sc:		True if MBA software controller(mba_sc) is enabled
- * @mb_map:		Mapping of memory B/W percentage to memory B/W delay
  */
 struct resctrl_membw {
 	u32				min_bw;
@@ -263,7 +262,6 @@ struct resctrl_membw {
 	bool				arch_needs_linear;
 	enum membw_throttle_mode	throttle_mode;
 	bool				mba_sc;
-	u32				*mb_map;
 };
 
 struct resctrl_schema;
-- 
2.55.0

[PATCH v2 2/5] x86,fs/resctrl: Remove unnecessary non-linear MBA configuration check

[Reinette Chatre]

Writing a bandwidth value from user space is rejected if the MBA resource
has non-linear delay values while the architecture indicates (via
resctrl_membw::arch_needs_linear) it can only configure resources with
linear delay values. Intel indicates this for MBA while AMD and MPAM do not.

This check can never fail. No Intel SKU supports non-linear delay values,
and the placeholder for such support, rdt_get_mb_table(), is only called
during enumeration and always fails. A non-linear Intel MBA resource is
thus never marked as capable of allocation, and resctrl never exposes it
to user space or attempts to configure it. Every Intel MBA resource capable
of allocation has linear delay values, and AMD and MPAM never indicate a
need for them.

Fail enumeration of a non-linear Intel MBA resource directly to make clear
that it is not supported, and remove the check together with the
resctrl_membw::arch_needs_linear property it relies on.

Keep the informational message printed when such a system is encountered.
While moving it, reword it to no longer refer to the removed mapping table,
add the missing newline, and label the printed family value "family" instead
of "cpu".

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
Changes since RFC v1:
- Fix typo in changelog

Changes since RFC v2:
- Rework changelog.
- Group all r->membw assignments together.

Changes since v1:
- Keep (and fix) existing pr_info() message if a non-linear platform
  appears. (Chenyu)
- Rework changelog.
- Group rdt_resource::membw assignments together.
---
 arch/x86/kernel/cpu/resctrl/core.c | 42 +++++++-----------------------
 fs/resctrl/ctrlmondata.c           |  8 ------
 include/linux/resctrl.h            |  2 --
 3 files changed, 10 insertions(+), 42 deletions(-)

diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index f9677e52790e..f96f7cf255d0 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -181,27 +181,6 @@ static inline void cache_alloc_hsw_probe(void)
 	rdt_alloc_capable = true;
 }
 
-/*
- * rdt_get_mb_table() - get a mapping of bandwidth(b/w) percentage values
- * exposed to user interface and the h/w understandable delay values.
- *
- * The non-linear delay values have the granularity of power of two
- * and also the h/w does not guarantee a curve for configured delay
- * values vs. actual b/w enforced.
- * Hence we need a mapping that is pre calibrated so the user can
- * express the memory b/w as a percentage value.
- */
-static inline bool rdt_get_mb_table(struct rdt_resource *r)
-{
-	/*
-	 * There are no Intel SKUs as of now to support non-linear delay.
-	 */
-	pr_info("MBA b/w map not implemented for cpu:%d, model:%d",
-		boot_cpu_data.x86, boot_cpu_data.x86_model);
-
-	return false;
-}
-
 static __init bool __get_mem_config_intel(struct rdt_resource *r)
 {
 	struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r);
@@ -212,18 +191,18 @@ static __init bool __get_mem_config_intel(struct rdt_resource *r)
 	cpuid_count(0x00000010, 3, &eax.full, &ebx, &ecx, &edx.full);
 	hw_res->num_closid = edx.split.cos_max + 1;
 	max_delay = eax.split.max_delay + 1;
-	r->membw.max_bw = MAX_MBA_BW;
-	r->membw.arch_needs_linear = true;
-	if (ecx & MBA_IS_LINEAR) {
-		r->membw.delay_linear = true;
-		r->membw.min_bw = MAX_MBA_BW - max_delay;
-		r->membw.bw_gran = MAX_MBA_BW - max_delay;
-	} else {
-		if (!rdt_get_mb_table(r))
-			return false;
-		r->membw.arch_needs_linear = false;
+
+	if (!(ecx & MBA_IS_LINEAR)) {
+		pr_info("Non-linear MBA delay values not supported for family:%d, model:%d\n",
+			boot_cpu_data.x86, boot_cpu_data.x86_model);
+		return false;
 	}
 
+	r->membw.delay_linear = true;
+	r->membw.max_bw = MAX_MBA_BW;
+	r->membw.min_bw = MAX_MBA_BW - max_delay;
+	r->membw.bw_gran = MAX_MBA_BW - max_delay;
+
 	if (boot_cpu_has(X86_FEATURE_PER_THREAD_MBA))
 		r->membw.throttle_mode = THREAD_THROTTLE_PER_THREAD;
 	else
@@ -255,7 +234,6 @@ static __init bool __rdt_get_mem_config_amd(struct rdt_resource *r)
 
 	/* AMD does not use delay */
 	r->membw.delay_linear = false;
-	r->membw.arch_needs_linear = false;
 
 	/*
 	 * AMD does not use memory delay throttle model to control
diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index cafebdff70dc..4562072b8ba6 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -45,14 +45,6 @@ static bool bw_validate(char *buf, u32 *data, struct rdt_resource *r)
 	int ret;
 	u32 bw;
 
-	/*
-	 * Only linear delay values is supported for current Intel SKUs.
-	 */
-	if (!r->membw.delay_linear && r->membw.arch_needs_linear) {
-		rdt_last_cmd_puts("No support for non-linear MB domains\n");
-		return false;
-	}
-
 	ret = kstrtou32(buf, 10, &bw);
 	if (ret) {
 		rdt_last_cmd_printf("Invalid MB value %s\n", buf);
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index b63dc62690ca..66dc9813c888 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -249,7 +249,6 @@ enum membw_throttle_mode {
  * @max_bw:		Maximum memory bandwidth value, used as the reset value
  * @bw_gran:		Granularity at which the memory bandwidth is allocated
  * @delay_linear:	True if memory B/W delay is in linear scale
- * @arch_needs_linear:	True if we can't configure non-linear resources
  * @throttle_mode:	Bandwidth throttling mode when threads request
  *			different memory bandwidths
  * @mba_sc:		True if MBA software controller(mba_sc) is enabled
@@ -259,7 +258,6 @@ struct resctrl_membw {
 	u32				max_bw;
 	u32				bw_gran;
 	u32				delay_linear;
-	bool				arch_needs_linear;
 	enum membw_throttle_mode	throttle_mode;
 	bool				mba_sc;
 };
-- 
2.55.0

[PATCH v2 3/5] x86,fs/resctrl: Move MSR_IA32_L{2,3}_QOS_CFG scope property to x86 resource

[Reinette Chatre]

MSR_IA32_L{2,3}_QOS_CFG enable code and data prioritization on x86. On
Intel the registers have the scope of the associated cache while on AMD
they have CPU scope. The scope is recorded as a property of the cache
resource's control, of which each cache resource currently supports only
one.

The scope of MSR_IA32_L{2,3}_QOS_CFG is only relevant to x86. Even so, the
property is found among the resctrl filesystem's cache properties while only
x86 code sets and reads it. Keeping the property with the cache control
properties would also duplicate it across all controls of a resource when
resources support multiple controls.

Make the scope of MSR_IA32_L{2,3}_QOS_CFG a property of the x86 hardware
resource and name it for the registers it describes now that it no longer
needs to be generic.

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
Changes since RFC v1:
- Remove stray ";" in kernel-doc comment.

Changes since RFC v2:
- Rewrite changelog, shorten subject.
- Rework comment instead of copy&paste the original.
- Rename property to be more specific now that it does not need to aim
  for generic resctrl filesystem support.

Changes since v1:
- Update kernel-doc to make clear property is only relevant to cache
  resources.
- Rewrite changelog.
---
 arch/x86/kernel/cpu/resctrl/core.c     | 7 ++++---
 arch/x86/kernel/cpu/resctrl/internal.h | 4 ++++
 arch/x86/kernel/cpu/resctrl/rdtgroup.c | 4 +++-
 include/linux/resctrl.h                | 3 ---
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index f96f7cf255d0..e647c3aa065a 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -444,6 +444,7 @@ static int get_domain_id_from_scope(int cpu, enum resctrl_scope scope)
 
 static void domain_add_cpu_ctrl(int cpu, struct rdt_resource *r)
 {
+	struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r);
 	int id = get_domain_id_from_scope(cpu, r->ctrl_scope);
 	struct rdt_hw_ctrl_domain *hw_dom;
 	struct list_head *add_pos = NULL;
@@ -466,7 +467,7 @@ static void domain_add_cpu_ctrl(int cpu, struct rdt_resource *r)
 		d = container_of(hdr, struct rdt_ctrl_domain, hdr);
 
 		cpumask_set_cpu(cpu, &d->hdr.cpu_mask);
-		if (r->cache.arch_has_per_cpu_cfg)
+		if (hw_res->qos_cfg_has_cpu_scope)
 			rdt_domain_reconfigure_cdp(r);
 		return;
 	}
@@ -1001,7 +1002,7 @@ static __init void rdt_init_res_defs_intel(void)
 
 		if (r->rid == RDT_RESOURCE_L3 ||
 		    r->rid == RDT_RESOURCE_L2) {
-			r->cache.arch_has_per_cpu_cfg = false;
+			hw_res->qos_cfg_has_cpu_scope = false;
 			r->cache.min_cbm_bits = 1;
 		} else if (r->rid == RDT_RESOURCE_MBA) {
 			hw_res->msr_base = MSR_IA32_MBA_THRTL_BASE;
@@ -1020,8 +1021,8 @@ static __init void rdt_init_res_defs_amd(void)
 
 		if (r->rid == RDT_RESOURCE_L3 ||
 		    r->rid == RDT_RESOURCE_L2) {
+			hw_res->qos_cfg_has_cpu_scope = true;
 			r->cache.arch_has_sparse_bitmasks = true;
-			r->cache.arch_has_per_cpu_cfg = true;
 			r->cache.min_cbm_bits = 0;
 		} else if (r->rid == RDT_RESOURCE_MBA) {
 			hw_res->msr_base = MSR_IA32_MBA_BW_BASE;
diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
index e3cfa0c10e92..670ce9272b51 100644
--- a/arch/x86/kernel/cpu/resctrl/internal.h
+++ b/arch/x86/kernel/cpu/resctrl/internal.h
@@ -125,6 +125,9 @@ struct msr_param {
  * @mon_scale:		cqm counter * mon_scale = occupancy in bytes
  * @mbm_width:		Monitor width, to detect and correct for overflow.
  * @cdp_enabled:	CDP state of this resource
+ * @qos_cfg_has_cpu_scope:	Only for the L2 and L3 resources: true if
+ *				MSR_IA32_L{2,3}_QOS_CFG has CPU scope, false if
+ *				the scope matches the associated cache.
  * @mbm_cntr_assign_enabled:	ABMC feature is enabled
  * @sdciae_enabled:	SDCIAE feature (backing "io_alloc") is enabled.
  *
@@ -140,6 +143,7 @@ struct rdt_hw_resource {
 	unsigned int		mon_scale;
 	unsigned int		mbm_width;
 	bool			cdp_enabled;
+	bool			qos_cfg_has_cpu_scope;
 	bool			mbm_cntr_assign_enabled;
 	bool			sdciae_enabled;
 };
diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
index 5ffa39fa86fa..6e4eeccd4891 100644
--- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
+++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
@@ -131,6 +131,7 @@ static void l2_qos_cfg_update(void *arg)
 
 static int set_cache_qos_cfg(int level, bool enable)
 {
+	struct rdt_hw_resource *hw_res;
 	void (*update)(void *arg);
 	struct rdt_ctrl_domain *d;
 	struct rdt_resource *r_l;
@@ -151,8 +152,9 @@ static int set_cache_qos_cfg(int level, bool enable)
 		return -ENOMEM;
 
 	r_l = &rdt_resources_all[level].r_resctrl;
+	hw_res = resctrl_to_arch_res(r_l);
 	list_for_each_entry_rcu(d, &r_l->ctrl_domains, hdr.list, lockdep_is_cpus_held()) {
-		if (r_l->cache.arch_has_per_cpu_cfg)
+		if (hw_res->qos_cfg_has_cpu_scope)
 			/* Pick all the CPUs in the domain instance */
 			for_each_cpu(cpu, &d->hdr.cpu_mask)
 				cpumask_set_cpu(cpu, cpu_mask);
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index 66dc9813c888..b6b4519a5190 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -215,8 +215,6 @@ struct rdt_l3_mon_domain {
  * @shareable_bits:	Bitmask of shareable resource with other
  *			executing entities
  * @arch_has_sparse_bitmasks:	True if a bitmask like f00f is valid.
- * @arch_has_per_cpu_cfg:	True if QOS_CFG register for this cache
- *				level has CPU scope.
  * @io_alloc_capable:	True if portion of the cache can be configured
  *			for I/O traffic.
  */
@@ -225,7 +223,6 @@ struct resctrl_cache {
 	unsigned int	min_cbm_bits;
 	unsigned int	shareable_bits;
 	bool		arch_has_sparse_bitmasks;
-	bool		arch_has_per_cpu_cfg;
 	bool		io_alloc_capable;
 };
 
-- 
2.55.0

[PATCH v2 4/5] fs/resctrl: Drop unnecessary is_mba_linear() helper

[Reinette Chatre]

is_mba_linear() assumes it operates on the MBA resource and returns whether
the resource's delay values are linear. There is only one caller that
separately makes the same assumption.

Avoid duplicating the resource assumptions and let the only caller access
the needed property directly.

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
---
Changes from RFC v1:
- RFC v1 made bandwidth delay a resource property. That change was dropped
  and this cleanup is all that remained.

Changes since v1:
- Add Chenyu and Ben's Reviewed-by tags.
- Clarify "resource is linear" vs. "resource's delay values are linear".
---
 fs/resctrl/rdtgroup.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 68be9b903ac6..821c6e2b10f4 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -2577,11 +2577,6 @@ mongroup_create_dir(struct kernfs_node *parent_kn, struct rdtgroup *prgrp,
 	return ret;
 }
 
-static inline bool is_mba_linear(void)
-{
-	return resctrl_arch_get_resource(RDT_RESOURCE_MBA)->membw.delay_linear;
-}
-
 static int mba_sc_domain_allocate(struct rdt_resource *r, struct rdt_ctrl_domain *d)
 {
 	u32 num_closid = resctrl_arch_get_num_closid(r);
@@ -2621,7 +2616,7 @@ static bool supports_mba_mbps(void)
 	struct rdt_resource *r = resctrl_arch_get_resource(RDT_RESOURCE_MBA);
 
 	return (resctrl_is_mbm_enabled() &&
-		r->alloc_capable && is_mba_linear() &&
+		r->alloc_capable && r->membw.delay_linear &&
 		r->ctrl_scope == rmbm->mon_scope &&
 		!rmbm->mon.mbm_cntr_assignable);
 }
-- 
2.55.0

[PATCH v2 5/5] fs/resctrl: Drop unnecessary parameter from resctrl_io_alloc_parse_line()

[Reinette Chatre]

resctrl_io_alloc_parse_line() parses a line written to the io_alloc_cbm file.
It receives both a schema and a pointer to the schema's resource. Its only
caller looks up the resource from the schema just to pass both.

Passing the resource separately is redundant and allows a caller to pass a
resource that does not belong to the schema. parse_line(), which parses lines
written to the schemata file, already receives only the schema and determines
the resource from it.

Pass only the schema to resctrl_io_alloc_parse_line() and have it determine
the resource itself, matching parse_line() and in preparation for passing
additional information when supporting multiple controls.

No functional change.

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
---
Changes since RFC v2:
- Rework changelog.

Changes since v1:
- Rework changelog.
- Add justification for the change. (Ben)
- Add Ben's Reviewed-by tag.
---
 fs/resctrl/ctrlmondata.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index 4562072b8ba6..69123b2a3274 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -955,11 +955,12 @@ int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of, struct seq_file *seq,
 	return ret;
 }
 
-static int resctrl_io_alloc_parse_line(char *line,  struct rdt_resource *r,
-				       struct resctrl_schema *s, u32 closid)
+static int resctrl_io_alloc_parse_line(char *line, struct resctrl_schema *s,
+				       u32 closid)
 {
 	enum resctrl_conf_type peer_type;
 	unsigned long dom_id = ULONG_MAX;
+	struct rdt_resource *r = s->res;
 	struct rdt_parse_data data;
 	struct rdt_ctrl_domain *d;
 	bool update_all = false;
@@ -1052,7 +1053,7 @@ ssize_t resctrl_io_alloc_cbm_write(struct kernfs_open_file *of, char *buf,
 	io_alloc_closid = resctrl_io_alloc_closid(r);
 
 	rdt_staged_configs_clear();
-	ret = resctrl_io_alloc_parse_line(buf, r, s, io_alloc_closid);
+	ret = resctrl_io_alloc_parse_line(buf, s, io_alloc_closid);
 	if (ret)
 		goto out_clear_configs;
 
-- 
2.55.0

Re: [PATCH v2 2/5] x86,fs/resctrl: Remove unnecessary non-linear MBA configuration check

[Chen Yu]

On Wed, Oct 07, 2026 at 02:06:44PM -0700, Reinette Chatre wrote:
> Writing a bandwidth value from user space is rejected if the MBA resource
> has non-linear delay values while the architecture indicates (via
> resctrl_membw::arch_needs_linear) it can only configure resources with
> linear delay values. Intel indicates this for MBA while AMD and MPAM do not.
> 
> This check can never fail. No Intel SKU supports non-linear delay values,
> and the placeholder for such support, rdt_get_mb_table(), is only called
> during enumeration and always fails. A non-linear Intel MBA resource is
> thus never marked as capable of allocation, and resctrl never exposes it
> to user space or attempts to configure it. Every Intel MBA resource capable
> of allocation has linear delay values, and AMD and MPAM never indicate a
> need for them.
> 
> Fail enumeration of a non-linear Intel MBA resource directly to make clear
> that it is not supported, and remove the check together with the
> resctrl_membw::arch_needs_linear property it relies on.
> 
> Keep the informational message printed when such a system is encountered.
> While moving it, reword it to no longer refer to the removed mapping table,
> add the missing newline, and label the printed family value "family" instead
> of "cpu".
> 
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
>

Reviewed-by: Chen Yu <yu.c.chen@intel.com>

thanks,
Chenyu

Re: [PATCH v2 0/5] x86,fs/resctrl: Cleanups in preparation for multiple controls support

[Luck, Tony]

> The only intended functional change is a reworded informational message
> printed if an Intel system with non-linear MBA delay values is encountered.

I set r->membw.delay_linear = false; and booted to check. Console
message during boot now includes:

[    7.372455] resctrl: Non-linear MBA delay values not supported

Attempting to mount resctrl with the mba_MBps option fails (as expected)
with:

mount: /sys/fs/resctrl: fsconfig system call failed: resctrl: mba_MBps requires MBM (mbm_event mode not supported) and linear scale MBA at L3 scope.

I've been using the older versions of these patches from

git://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git resctrl/controls_rfc_v2.4

and haven't seen any issues.


Series:

Reviewed-by: Tony Luck <tony.luck@intel.com>

-Tony

Re: [PATCH v2 0/5] x86,fs/resctrl: Cleanups in preparation for multiple controls support

[Reinette Chatre]

On 10/8/26 9:12 AM, Luck, Tony wrote:
>> The only intended functional change is a reworded informational message
>> printed if an Intel system with non-linear MBA delay values is encountered.
> 
> I set r->membw.delay_linear = false; and booted to check. Console
> message during boot now includes:
> 
> [    7.372455] resctrl: Non-linear MBA delay values not supported
> 
> Attempting to mount resctrl with the mba_MBps option fails (as expected)
> with:
> 
> mount: /sys/fs/resctrl: fsconfig system call failed: resctrl: mba_MBps requires MBM (mbm_event mode not supported) and linear scale MBA at L3 scope.
> 
> I've been using the older versions of these patches from
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git resctrl/controls_rfc_v2.4
> 
> and haven't seen any issues.
> 
> 
> Series:
> 
> Reviewed-by: Tony Luck <tony.luck@intel.com>
Thank you very much Tony.

Reinette

Re: [PATCH v2 3/5] x86,fs/resctrl: Move MSR_IA32_L{2,3}_QOS_CFG scope property to x86 resource

[Chen Yu]

Hi Reinette,

On Wed, Oct 07, 2026 at 02:06:45PM -0700, Reinette Chatre wrote:
> 
> MSR_IA32_L{2,3}_QOS_CFG enable code and data prioritization on x86. On
> Intel the registers have the scope of the associated cache while on AMD
> they have CPU scope. The scope is recorded as a property of the cache
> resource's control, of which each cache resource currently supports only
> one.
> 
> The scope of MSR_IA32_L{2,3}_QOS_CFG is only relevant to x86. Even so, the
> property is found among the resctrl filesystem's cache properties while only
> x86 code sets and reads it. Keeping the property with the cache control
> properties would also duplicate it across all controls of a resource when
> resources support multiple controls.
> 
> Make the scope of MSR_IA32_L{2,3}_QOS_CFG a property of the x86 hardware
> resource and name it for the registers it describes now that it no longer
> needs to be generic.
> 
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>

[ ... ]

> @@ -140,6 +143,7 @@ struct rdt_hw_resource {
>  	unsigned int		mon_scale;
>  	unsigned int		mbm_width;
>  	bool			cdp_enabled;
> +	bool			qos_cfg_has_cpu_scope;
>  	bool			mbm_cntr_assign_enabled;
>  	bool			sdciae_enabled;
>  };

It seems that some flags are in resource scope, while others are in the controller's scope,
cache's flags are in the resource scope, MB's flags are in controller's scope, for example "linear".
For now, there is only one controller under the L2/L3 cache resource, so it might
not be duplicated if we keep qos_cfg_has_cpu_scope in the controller scope to keep consistence? Or do
you mean if in the future there are multiple controllers under this cache resource, all controllers'
flags (e.g., qos_cfg_has_cpu_scope) would still share the same value, so it is OK to put the flag in
the cache resource? If yes, the code looks good to me,

Review-by: Chen Yu <yu.c.chen@intel.com>

thanks,
Chenyu

Re: [PATCH v2 5/5] fs/resctrl: Drop unnecessary parameter from resctrl_io_alloc_parse_line()

[Chen Yu]

On Wed, Oct 07, 2026 at 02:06:47PM -0700, Reinette Chatre wrote:
> 
> resctrl_io_alloc_parse_line() parses a line written to the io_alloc_cbm file.
> It receives both a schema and a pointer to the schema's resource. Its only
> caller looks up the resource from the schema just to pass both.
> 
> Passing the resource separately is redundant and allows a caller to pass a
> resource that does not belong to the schema. parse_line(), which parses lines
> written to the schemata file, already receives only the schema and determines
> the resource from it.
> 
> Pass only the schema to resctrl_io_alloc_parse_line() and have it determine
> the resource itself, matching parse_line() and in preparation for passing
> additional information when supporting multiple controls.
> 
> No functional change.
> 
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> Reviewed-by: Ben Horgan <ben.horgan@arm.com>
>

Reviewed-by: Chen Yu <yu.c.chen@intel.com>

thanks,
Chenyu 

Re: [PATCH v2 3/5] x86,fs/resctrl: Move MSR_IA32_L{2,3}_QOS_CFG scope property to x86 resource

[Reinette Chatre]

Hi Chenyu,

On 10/18/26 10:40 AM, Chen Yu wrote:
> On Wed, Oct 07, 2026 at 02:06:45PM -0700, Reinette Chatre wrote:
>>
>> MSR_IA32_L{2,3}_QOS_CFG enable code and data prioritization on x86. On
>> Intel the registers have the scope of the associated cache while on AMD
>> they have CPU scope. The scope is recorded as a property of the cache
>> resource's control, of which each cache resource currently supports only
>> one.
>>
>> The scope of MSR_IA32_L{2,3}_QOS_CFG is only relevant to x86. Even so, the
>> property is found among the resctrl filesystem's cache properties while only
>> x86 code sets and reads it. Keeping the property with the cache control
>> properties would also duplicate it across all controls of a resource when
>> resources support multiple controls.
>>
>> Make the scope of MSR_IA32_L{2,3}_QOS_CFG a property of the x86 hardware
>> resource and name it for the registers it describes now that it no longer
>> needs to be generic.
>>
>> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> 
> [ ... ]
> 
>> @@ -140,6 +143,7 @@ struct rdt_hw_resource {
>>  	unsigned int		mon_scale;
>>  	unsigned int		mbm_width;
>>  	bool			cdp_enabled;
>> +	bool			qos_cfg_has_cpu_scope;
>>  	bool			mbm_cntr_assign_enabled;
>>  	bool			sdciae_enabled;
>>  };
> 
> It seems that some flags are in resource scope, while others are in the controller's scope,
> cache's flags are in the resource scope, MB's flags are in controller's scope, for example "linear".

The goal of this change is to move this information into the only (x86) architectural driver where it
is relevant.

These "flags" are different in a couple of ways:
a) qos_cfg_has_cpu_scope is specific to x86 architecture (thus located in struct rdt_hw_resource of
   x86 driver, not struct rdt_resource belonging to resctrl fs) - this information is not exposed
   to user space nor is it of use to resctrl filesystem. This is just information internal to
   architecture whether the x86 MSR has CPU or domain scope to accommodate this difference between
   AMD and Intel.
b) the MB controller flags like scalar and linear are associated with the controller,
   exposed to user space, and managed by resctrl filesystem.

To me this qos_cfg_has_cpu_scope flag is closer to the architectural support you are working on
that contains within x86 architecture driver the decision whether it should use ACPI or MSR than
it is to control flags.

> For now, there is only one controller under the L2/L3 cache resource, so it might
> not be duplicated if we keep qos_cfg_has_cpu_scope in the controller scope to keep consistence? Or do

I do not see how qos_cfg_has_cpu_scope is related to properties of controls exposed via resctrl fs.
resctrl filesystem may request CDP to be enabled/disabled on a control but how that enabling is done, whether
the architecture uses MMIO, CPU scope MSR, or domain scope MSR, that knowledge is private to the
architecture.

> you mean if in the future there are multiple controllers under this cache resource, all controllers'
> flags (e.g., qos_cfg_has_cpu_scope) would still share the same value, so it is OK to put the flag in
> the cache resource? If yes, the code looks good to me,

This patch is not about moving a cache control flag into the resource but instead about making
an architecture specific flag (unrelated to a control) invisible to resctrl filesystem. 
 
> Review-by: Chen Yu <yu.c.chen@intel.com>
Thanks, but I do not think we have the same view of this change. Please let me know if you
still feel this patch is ok after this discussion.

Reinette

Re: [PATCH v2 3/5] x86,fs/resctrl: Move MSR_IA32_L{2,3}_QOS_CFG scope property to x86 resource

[Chen Yu]

Hi Reinette,

On Mon, Oct 19, 2026 at 04:06:35PM -0700, Reinette Chatre wrote:
> Hi Chenyu,
> 
> On 10/18/26 10:40 AM, Chen Yu wrote:
> > On Wed, Oct 07, 2026 at 02:06:45PM -0700, Reinette Chatre wrote:
> >>
> >> MSR_IA32_L{2,3}_QOS_CFG enable code and data prioritization on x86. On
> >> Intel the registers have the scope of the associated cache while on AMD
> >> they have CPU scope. The scope is recorded as a property of the cache
> >> resource's control, of which each cache resource currently supports only
> >> one.
> >>
> >> The scope of MSR_IA32_L{2,3}_QOS_CFG is only relevant to x86. Even so, the
> >> property is found among the resctrl filesystem's cache properties while only
> >> x86 code sets and reads it. Keeping the property with the cache control
> >> properties would also duplicate it across all controls of a resource when
> >> resources support multiple controls.
> >>
> >> Make the scope of MSR_IA32_L{2,3}_QOS_CFG a property of the x86 hardware
> >> resource and name it for the registers it describes now that it no longer
> >> needs to be generic.
> >>
> >> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> > 
> > [ ... ]
> > 
> >> @@ -140,6 +143,7 @@ struct rdt_hw_resource {
> >>  	unsigned int		mon_scale;
> >>  	unsigned int		mbm_width;
> >>  	bool			cdp_enabled;
> >> +	bool			qos_cfg_has_cpu_scope;
> >>  	bool			mbm_cntr_assign_enabled;
> >>  	bool			sdciae_enabled;
> >>  };
> > 
> > It seems that some flags are in resource scope, while others are in the controller's scope,
> > cache's flags are in the resource scope, MB's flags are in controller's scope, for example "linear".
> 
> The goal of this change is to move this information into the only (x86) architectural driver where it
> is relevant.
> 
> These "flags" are different in a couple of ways:
> a) qos_cfg_has_cpu_scope is specific to x86 architecture (thus located in struct rdt_hw_resource of
>    x86 driver, not struct rdt_resource belonging to resctrl fs) - this information is not exposed
>    to user space nor is it of use to resctrl filesystem. This is just information internal to
>    architecture whether the x86 MSR has CPU or domain scope to accommodate this difference between
>    AMD and Intel.
> b) the MB controller flags like scalar and linear are associated with the controller,
>    exposed to user space, and managed by resctrl filesystem.
>

I see, the hardware-specific attributes/indicators could be in the hardware resource
scope(and usually they are global settings), while the MB controller's flag is not hardware
specific, and they are not global settings.

> To me this qos_cfg_has_cpu_scope flag is closer to the architectural support you are working on
> that contains within x86 architecture driver the decision whether it should use ACPI or MSR than
> it is to control flags.
>

It seems to be a little different in the control_mode case, currently control_mode is in the
struct rdt_resource, but its callback resctrl_arch_control_mode_set() is x86 architecture driver
specific.

> > For now, there is only one controller under the L2/L3 cache resource, so it might
> > not be duplicated if we keep qos_cfg_has_cpu_scope in the controller scope to keep consistence? Or do
> 
> I do not see how qos_cfg_has_cpu_scope is related to properties of controls exposed via resctrl fs.
> resctrl filesystem may request CDP to be enabled/disabled on a control but how that enabling is done, whether
> the architecture uses MMIO, CPU scope MSR, or domain scope MSR, that knowledge is private to the
> architecture.
>

I agree.

> > you mean if in the future there are multiple controllers under this cache resource, all controllers'
> > flags (e.g., qos_cfg_has_cpu_scope) would still share the same value, so it is OK to put the flag in
> > the cache resource? If yes, the code looks good to me,
> 
> This patch is not about moving a cache control flag into the resource but instead about making
> an architecture specific flag (unrelated to a control) invisible to resctrl filesystem. 
>  
> > Review-by: Chen Yu <yu.c.chen@intel.com>
> Thanks, but I do not think we have the same view of this change. Please let me know if you
> still feel this patch is ok after this discussion.
>

Yes, thanks for the detailed explanation. This patch is OK with me.

thanks,
Chenyu

> Reinette
>