[PATCH v2 0/6] x86,fs/resctrl: Pave the way for MPAM counter assignment

[PATCH v2 0/6] x86,fs/resctrl: Pave the way for MPAM counter assignment

[Ben Horgan]

A little bit of preparatory work to get ready for MPAM counter
assignment. Resctrl gained support last year for counter assignment for AMD
machines supporting ABMC. Tighten a few things up, that weren't needed for
AMD, so that the MPAM driver can emulate ABMC and hence support counter
assignment.

Based on v7.0-rc3. The last patch is only there to resolve the conflict
in the case that the mpam resctrl glue series [1] is merged first.

Changes since v1:
  https://lore.kernel.org/lkml/20260225201905.3568624-1-ben.horgan@arm.com/

Update the commit message for adding resctrl_arch_is_evt_configurable()
and change the new argument name to per_cntr
Make the event_filter file read only rather than hiding it
Include resctrl arch hook for fixed counter assignment mode.
This replaces:
  https://lore.kernel.org/lkml/20260204161952.685921-1-ben.horgan@arm.com/
Include both new helpers in the mpam build fix

[1] https://lore.kernel.org/linux-arm-kernel/20260313144617.3420416-1-ben.horgan@arm.com/

Ben Horgan (6):
  x86,fs/resctrl: Make resctrl_arch_is_evt_configurable() aware of
    mbm_assign_mode
  fs/resctrl: Tidy up the error path in resctrl_mkdir_event_configs()
  fs/resctrl: Make 'event_filter' files read only if they're not
    configurable
  fs/resctrl: Disallow the software controller when mbm counters are
    assignable
  x86,fs/resctrl: Add resctrl_arch_mbm_cntr_assign_fixed()
  arm_mpam: resctrl: Adapt to new or changed resctrl arch functions

 arch/x86/kernel/cpu/resctrl/core.c    | 12 +++++++++--
 arch/x86/kernel/cpu/resctrl/monitor.c |  5 +++++
 drivers/resctrl/mpam_resctrl.c        |  7 ++++++-
 fs/resctrl/monitor.c                  | 18 +++++++++++++---
 fs/resctrl/rdtgroup.c                 | 30 ++++++++++++++++++++-------
 include/linux/resctrl.h               | 12 ++++++++++-
 6 files changed, 70 insertions(+), 14 deletions(-)

-- 
2.43.0

[PATCH v2 1/6] x86,fs/resctrl: Make resctrl_arch_is_evt_configurable() aware of mbm_assign_mode

[Ben Horgan]

The features BMEC and ABMC provide separate interfaces to configuring which
bandwidth types a counter tracks. Currently
resctrl_arch_is_evt_configurable() only ever returns true if BMEC is
supported.

ABMC is useful even when BMEC is supported as it also provides counter
assignment which reduces the number of hardware monitors a system
requires. It is an architectural detail that ABMC provides counter
configurability without requiring the prior feature, BMEC. On MPAM systems
these two features are independent and the bandwidth types are limited to a
choice of only read or write.

In order to give resctrl the information to support these features
independently extend resctrl_arch_is_evt_configurable() to report whether
events are configurable when using the mbm_event counter assignment mode.

Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
 arch/x86/kernel/cpu/resctrl/core.c | 12 ++++++++++--
 fs/resctrl/monitor.c               |  4 ++--
 include/linux/resctrl.h            |  2 +-
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index 7667cf7c4e94..8c041c5f07ab 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -877,11 +877,19 @@ bool rdt_cpu_has(int flag)
 	return ret;
 }
 
-bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt)
+bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt, bool per_cntr)
 {
-	if (!rdt_cpu_has(X86_FEATURE_BMEC))
+	if (!per_cntr && !rdt_cpu_has(X86_FEATURE_BMEC))
 		return false;
 
+	if (per_cntr && !rdt_cpu_has(X86_FEATURE_ABMC))
+		return false;
+
+	/*
+	 * When ABMC is used the mbm_local and mbm_total events are enabled
+	 * based on the equivalently named cpu features. (In order to allow
+	 * fallback to the default counter assignment mode).
+	 */
 	switch (evt) {
 	case QOS_L3_MBM_TOTAL_EVENT_ID:
 		return rdt_cpu_has(X86_FEATURE_CQM_MBM_TOTAL);
diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
index 49f3f6b846b2..d25622ee22c5 100644
--- a/fs/resctrl/monitor.c
+++ b/fs/resctrl/monitor.c
@@ -1854,12 +1854,12 @@ int resctrl_l3_mon_resource_init(void)
 	if (ret)
 		return ret;
 
-	if (resctrl_arch_is_evt_configurable(QOS_L3_MBM_TOTAL_EVENT_ID)) {
+	if (resctrl_arch_is_evt_configurable(QOS_L3_MBM_TOTAL_EVENT_ID, false)) {
 		mon_event_all[QOS_L3_MBM_TOTAL_EVENT_ID].configurable = true;
 		resctrl_file_fflags_init("mbm_total_bytes_config",
 					 RFTYPE_MON_INFO | RFTYPE_RES_CACHE);
 	}
-	if (resctrl_arch_is_evt_configurable(QOS_L3_MBM_LOCAL_EVENT_ID)) {
+	if (resctrl_arch_is_evt_configurable(QOS_L3_MBM_LOCAL_EVENT_ID, false)) {
 		mon_event_all[QOS_L3_MBM_LOCAL_EVENT_ID].configurable = true;
 		resctrl_file_fflags_init("mbm_local_bytes_config",
 					 RFTYPE_MON_INFO | RFTYPE_RES_CACHE);
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index 006e57fd7ca5..4ae63233b506 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -419,7 +419,7 @@ bool resctrl_enable_mon_event(enum resctrl_event_id eventid, bool any_cpu,
 
 bool resctrl_is_mon_event_enabled(enum resctrl_event_id eventid);
 
-bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt);
+bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt, bool per_cntr);
 
 static inline bool resctrl_is_mbm_event(enum resctrl_event_id eventid)
 {
-- 
2.43.0

[PATCH v2 2/6] fs/resctrl: Tidy up the error path in resctrl_mkdir_event_configs()

[Ben Horgan]

The error path in resctrl_mkdir_event_configs() is unnecessarily
complicated. Simplify it to just return directly on error.

Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
 fs/resctrl/rdtgroup.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 5da305bd36c9..4753841c2ca3 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -2331,20 +2331,19 @@ static int resctrl_mkdir_event_configs(struct rdt_resource *r, struct kernfs_nod
 		kn_subdir2 = kernfs_create_dir(kn_subdir, mevt->name, kn_subdir->mode, mevt);
 		if (IS_ERR(kn_subdir2)) {
 			ret = PTR_ERR(kn_subdir2);
-			goto out;
+			return ret;
 		}
 
 		ret = rdtgroup_kn_set_ugid(kn_subdir2);
 		if (ret)
-			goto out;
+			return ret;
 
 		ret = rdtgroup_add_files(kn_subdir2, RFTYPE_ASSIGN_CONFIG);
 		if (ret)
-			break;
+			return ret;
 	}
 
-out:
-	return ret;
+	return 0;
 }
 
 static int rdtgroup_mkdir_info_resdir(void *priv, char *name,
-- 
2.43.0

[PATCH v2 3/6] fs/resctrl: Make 'event_filter' files read only if they're not configurable

[Ben Horgan]

When the counter assignment mode is mbm_event resctrl assumes the mbm
events are configurable and exposes the 'event_filter' files. These files
live at info/L3_MON/event_configs/<event>/event_filter and are used to
display and set the event configuration. The MPAM driver has no support for
changing event configuration and so mbm_event mode can't be used.

In order to support mbm_event event with MPAM make the 'event_filter' files
read only if the event configuration can't be changed. A user can still
chmod the file and so also return an error from event_filter_write().

Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
 fs/resctrl/monitor.c  |  6 ++++++
 fs/resctrl/rdtgroup.c | 16 ++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
index d25622ee22c5..a2da771d82df 100644
--- a/fs/resctrl/monitor.c
+++ b/fs/resctrl/monitor.c
@@ -1414,6 +1414,12 @@ ssize_t event_filter_write(struct kernfs_open_file *of, char *buf, size_t nbytes
 
 	rdt_last_cmd_clear();
 
+	if (!resctrl_arch_is_evt_configurable(mevt->evtid, true)) {
+		rdt_last_cmd_printf("event_filter is not configurable for %s\n", mevt->name);
+		ret = -EPERM;
+		goto out_unlock;
+	}
+
 	r = resctrl_arch_get_resource(mevt->rid);
 	if (!resctrl_arch_mbm_cntr_assign_enabled(r)) {
 		rdt_last_cmd_puts("mbm_event counter assignment mode is not enabled\n");
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 4753841c2ca3..2f0a509b313a 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -2341,6 +2341,22 @@ static int resctrl_mkdir_event_configs(struct rdt_resource *r, struct kernfs_nod
 		ret = rdtgroup_add_files(kn_subdir2, RFTYPE_ASSIGN_CONFIG);
 		if (ret)
 			return ret;
+
+		if (!resctrl_arch_is_evt_configurable(mevt->evtid, true)) {
+			struct iattr iattr = {.ia_valid = ATTR_MODE,};
+			struct kernfs_node *kn;
+
+			kn = kernfs_find_and_get_ns(kn_subdir2, "event_filter", NULL);
+			if (!kn)
+				return -ENOENT;
+
+			iattr.ia_mode = S_IFREG | 0444;
+
+			ret = kernfs_setattr(kn, &iattr);
+			kernfs_put(kn);
+			if (ret)
+				return ret;
+		}
 	}
 
 	return 0;
-- 
2.43.0

[PATCH v2 4/6] fs/resctrl: Disallow the software controller when mbm counters are assignable

[Ben Horgan]

The software controller requires that there are free running mbm counters
for each control group in order to provide the feedback necessary to
control the memory bandwidth allocation for that control group.  Previous
to the introduction counter assignment support (ABMC) resctrl required this
in order to advertise support for mbm but now if the mbm counters are
assignable then this can't be guaranteed.

Currently, only AMD systems support counter assignment but the MBA is non
linear and so the software controller is never supported anyway. For MPAM
systems the MBA is linear and so the dependency on counters not being
assignable needs to made explicit. Hence, fail the mount if the user
requests the software controller, the mba_MBps option, and the mbm counters
are assignable.

Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
 fs/resctrl/rdtgroup.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 2f0a509b313a..21e6ca71e6e7 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -2535,7 +2535,8 @@ static bool supports_mba_mbps(void)
 
 	return (resctrl_is_mbm_enabled() &&
 		r->alloc_capable && is_mba_linear() &&
-		r->ctrl_scope == rmbm->mon_scope);
+		r->ctrl_scope == rmbm->mon_scope &&
+		!rmbm->mon.mbm_cntr_assignable);
 }
 
 /*
@@ -2950,7 +2951,7 @@ static int rdt_parse_param(struct fs_context *fc, struct fs_parameter *param)
 		ctx->enable_cdpl2 = true;
 		return 0;
 	case Opt_mba_mbps:
-		msg = "mba_MBps requires MBM and linear scale MBA at L3 scope";
+		msg = "mba_MBps requires dedicated MBM counters and linear scale MBA at L3 scope";
 		if (!supports_mba_mbps())
 			return invalfc(fc, msg);
 		ctx->enable_mba_mbps = true;
-- 
2.43.0

[PATCH v2 5/6] x86,fs/resctrl: Add resctrl_arch_mbm_cntr_assign_fixed()

[Ben Horgan]

Commit

  3b497c3f4f04 ("fs/resctrl: Introduce the interface to display monitoring modes")

introduced CONFIG_RESCTRL_ASSIGN_FIXED but left adding the Kconfig
entry until it was necessary. The counter assignment mode is fixed in
MPAM, even when there are assignable counters, and so addressing this
is needed to support MPAM.

To avoid the burden of another Kconfig entry, replace
CONFIG_RESCTRL_ASSIGN_FIXED with a new arch hook,
resctrl_arch_mbm_cntr_assign_fixed().

To enable better user reporting check use the new check in
resctrl_mbm_assign_mode_write().

Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
 arch/x86/kernel/cpu/resctrl/monitor.c |  5 +++++
 fs/resctrl/monitor.c                  |  8 +++++++-
 include/linux/resctrl.h               | 10 ++++++++++
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
index 9bd87bae4983..aa7f8f1ecd22 100644
--- a/arch/x86/kernel/cpu/resctrl/monitor.c
+++ b/arch/x86/kernel/cpu/resctrl/monitor.c
@@ -523,6 +523,11 @@ bool resctrl_arch_mbm_cntr_assign_enabled(struct rdt_resource *r)
 	return resctrl_to_arch_res(r)->mbm_cntr_assign_enabled;
 }
 
+bool resctrl_arch_mbm_cntr_assign_fixed(struct rdt_resource *r)
+{
+	return false;
+}
+
 static void resctrl_abmc_config_one_amd(void *info)
 {
 	union l3_qos_abmc_cfg *abmc_cfg = info;
diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
index a2da771d82df..62edb464410a 100644
--- a/fs/resctrl/monitor.c
+++ b/fs/resctrl/monitor.c
@@ -1455,7 +1455,7 @@ int resctrl_mbm_assign_mode_show(struct kernfs_open_file *of,
 		else
 			seq_puts(s, "[default]\n");
 
-		if (!IS_ENABLED(CONFIG_RESCTRL_ASSIGN_FIXED)) {
+		if (!resctrl_arch_mbm_cntr_assign_fixed(r)) {
 			if (enabled)
 				seq_puts(s, "default\n");
 			else
@@ -1506,6 +1506,12 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_open_file *of, char *buf,
 	}
 
 	if (enable != resctrl_arch_mbm_cntr_assign_enabled(r)) {
+		if (!resctrl_arch_mbm_cntr_assign_fixed(r)) {
+			ret = -EINVAL;
+			rdt_last_cmd_puts("Counter assignment mode is not configurable\n");
+			goto out_unlock;
+		}
+
 		ret = resctrl_arch_mbm_cntr_assign_set(r, enable);
 		if (ret)
 			goto out_unlock;
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index 4ae63233b506..c85176999eb2 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -500,6 +500,16 @@ bool resctrl_arch_mbm_cntr_assign_enabled(struct rdt_resource *r);
  */
 int resctrl_arch_mbm_cntr_assign_set(struct rdt_resource *r, bool enable);
 
+/**
+ * resctrl_arch_mbm_cntr_assign_fixed() - Check if MBM counter assignment mode
+ *					  can be configured.
+ * @r:		Pointer to the resource structure.
+ *
+ * Return:
+ * true if the assignment mode is fixed, false otherwise.
+ */
+bool resctrl_arch_mbm_cntr_assign_fixed(struct rdt_resource *r);
+
 /*
  * Update the ctrl_val and apply this config right now.
  * Must be called on one of the domain's CPUs.
-- 
2.43.0

[PATCH v2 6/6] arm_mpam: resctrl: Adapt to new or changed resctrl arch functions

[Ben Horgan]

Fix MPAM build after change to new version of
resctrl_arch_is_evt_configurable() and introduction of
resctrl_arch_mbm_cntr_assign_fixed().

Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
 drivers/resctrl/mpam_resctrl.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index a7691c66553a..86e899b89b58 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -97,7 +97,7 @@ bool resctrl_arch_mon_capable(void)
 	return l3->mon_capable;
 }
 
-bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt)
+bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt, bool assignable)
 {
 	return false;
 }
@@ -148,6 +148,11 @@ int resctrl_arch_mbm_cntr_assign_set(struct rdt_resource *r, bool enable)
 	return -EINVAL;
 }
 
+bool resctrl_arch_mbm_cntr_assign_fixed(struct rdt_resource *r)
+{
+	return true;
+}
+
 int resctrl_arch_io_alloc_enable(struct rdt_resource *r, bool enable)
 {
 	return -EOPNOTSUPP;
-- 
2.43.0

Re: [PATCH v2 3/6] fs/resctrl: Make 'event_filter' files read only if they're not configurable

[Luck, Tony]

On Fri, Mar 13, 2026 at 05:45:21PM +0000, Ben Horgan wrote:
> When the counter assignment mode is mbm_event resctrl assumes the mbm
> events are configurable and exposes the 'event_filter' files. These files
> live at info/L3_MON/event_configs/<event>/event_filter and are used to
> display and set the event configuration. The MPAM driver has no support for
> changing event configuration and so mbm_event mode can't be used.
> 
> In order to support mbm_event event with MPAM make the 'event_filter' files
> read only if the event configuration can't be changed. A user can still
> chmod the file and so also return an error from event_filter_write().
> +++ b/fs/resctrl/rdtgroup.c
> @@ -2341,6 +2341,22 @@ static int resctrl_mkdir_event_configs(struct rdt_resource *r, struct kernfs_nod
>  		ret = rdtgroup_add_files(kn_subdir2, RFTYPE_ASSIGN_CONFIG);
>  		if (ret)
>  			return ret;
> +
> +		if (!resctrl_arch_is_evt_configurable(mevt->evtid, true)) {
> +			struct iattr iattr = {.ia_valid = ATTR_MODE,};
> +			struct kernfs_node *kn;
> +
> +			kn = kernfs_find_and_get_ns(kn_subdir2, "event_filter", NULL);
> +			if (!kn)
> +				return -ENOENT;
> +
> +			iattr.ia_mode = S_IFREG | 0444;
> +
> +			ret = kernfs_setattr(kn, &iattr);
> +			kernfs_put(kn);
> +			if (ret)
> +				return ret;
> +		}


Instead of making the file writable, and then fixing the mode. Maybe
patch the mode in res_common_files[] before calling rdtgroup_add_files():


	if (!resctrl_arch_is_evt_configurable(mevt->evtid, true)) {
		struct rftype *rft;

		rft = rdtgroup_get_rftype_by_name("event_filter");
		if (rft)
			rft->mode = 0444;
	}

-Tony

Re: [PATCH v2 3/6] fs/resctrl: Make 'event_filter' files read only if they're not configurable

[Ben Horgan]

Hi Tony,

On 3/13/26 18:33, Luck, Tony wrote:
> On Fri, Mar 13, 2026 at 05:45:21PM +0000, Ben Horgan wrote:
>> When the counter assignment mode is mbm_event resctrl assumes the mbm
>> events are configurable and exposes the 'event_filter' files. These files
>> live at info/L3_MON/event_configs/<event>/event_filter and are used to
>> display and set the event configuration. The MPAM driver has no support for
>> changing event configuration and so mbm_event mode can't be used.
>>
>> In order to support mbm_event event with MPAM make the 'event_filter' files
>> read only if the event configuration can't be changed. A user can still
>> chmod the file and so also return an error from event_filter_write().
>> +++ b/fs/resctrl/rdtgroup.c
>> @@ -2341,6 +2341,22 @@ static int resctrl_mkdir_event_configs(struct rdt_resource *r, struct kernfs_nod
>>  		ret = rdtgroup_add_files(kn_subdir2, RFTYPE_ASSIGN_CONFIG);
>>  		if (ret)
>>  			return ret;
>> +
>> +		if (!resctrl_arch_is_evt_configurable(mevt->evtid, true)) {
>> +			struct iattr iattr = {.ia_valid = ATTR_MODE,};
>> +			struct kernfs_node *kn;
>> +
>> +			kn = kernfs_find_and_get_ns(kn_subdir2, "event_filter", NULL);
>> +			if (!kn)
>> +				return -ENOENT;
>> +
>> +			iattr.ia_mode = S_IFREG | 0444;
>> +
>> +			ret = kernfs_setattr(kn, &iattr);
>> +			kernfs_put(kn);
>> +			if (ret)
>> +				return ret;
>> +		}
> 
> 
> Instead of making the file writable, and then fixing the mode. Maybe
> patch the mode in res_common_files[] before calling rdtgroup_add_files():


I initially rejected this idea because res_common_files[] is global and the
read/write choice is per event type but we can safely save restore the mode as
we're holding the rdtgroup mutex. How about this?

 static int resctrl_mkdir_event_configs(struct rdt_resource *r, struct kernfs_node *l3_mon_kn)
 {
+       struct rftype *rft = rdtgroup_get_rftype_by_name("event_filter");
        struct kernfs_node *kn_subdir, *kn_subdir2;
        struct mon_evt *mevt;
        int ret;

+       if (!rft)
+               return -ENOENT;
+
        kn_subdir = kernfs_create_dir(l3_mon_kn, "event_configs", l3_mon_kn->mode, NULL);
        if (IS_ERR(kn_subdir))
                return PTR_ERR(kn_subdir);
@@ -2325,6 +2329,8 @@ static int resctrl_mkdir_event_configs(struct rdt_resource *r, struct kernfs_nod
                return ret;

        for_each_mon_event(mevt) {
+               umode_t saved_mode;
+
                if (mevt->rid != r->rid || !mevt->enabled || !resctrl_is_mbm_event(mevt->evtid))
                        continue;

@@ -2338,25 +2344,14 @@ static int resctrl_mkdir_event_configs(struct rdt_resource *r, struct kernfs_nod
                if (ret)
                        return ret;

+               saved_mode = rft->mode;
+               if (!resctrl_arch_is_evt_configurable(mevt->evtid, true))
+                       rft->mode = 0444;
+
                ret = rdtgroup_add_files(kn_subdir2, RFTYPE_ASSIGN_CONFIG);
+               rft->mode = saved_mode;
                if (ret)
                        return ret;

Thanks,

Ben


> 
> 
> 	if (!resctrl_arch_is_evt_configurable(mevt->evtid, true)) {
> 		struct rftype *rft;
> 
> 		rft = rdtgroup_get_rftype_by_name("event_filter");
> 		if (rft)
> 			rft->mode = 0444;
> 	}
> 
> -Tony

RE: [PATCH v2 3/6] fs/resctrl: Make 'event_filter' files read only if they're not configurable

[Luck, Tony]

> > Instead of making the file writable, and then fixing the mode. Maybe
> > patch the mode in res_common_files[] before calling rdtgroup_add_files():
>
>
> I initially rejected this idea because res_common_files[] is global and the
> read/write choice is per event type but we can safely save restore the mode as
> we're holding the rdtgroup mutex. How about this?

That seems more complicated. Is there an expectation that event_filter
needs to be writable on the "total" event but not on the "local" one?

-Tony

Re: [PATCH v2 3/6] fs/resctrl: Make 'event_filter' files read only if they're not configurable

[Ben Horgan]

Hi Tony,

On 3/16/26 16:27, Luck, Tony wrote:
>>> Instead of making the file writable, and then fixing the mode. Maybe
>>> patch the mode in res_common_files[] before calling rdtgroup_add_files():
>>
>>
>> I initially rejected this idea because res_common_files[] is global and the
>> read/write choice is per event type but we can safely save restore the mode as
>> we're holding the rdtgroup mutex. How about this?
> 
> That seems more complicated. Is there an expectation that event_filter
> needs to be writable on the "total" event but not on the "local" one?

No, at least not currently. For mpam only the total event is supported.

Another way of doing it could be to patch the mode in res_common_files[] from
resctrl_mkdir_event_configs() for both cases, 0444 and 0644, and change the
starting value to something invalid, e.g. 0.

Thanks,

Ben

Re: [PATCH v2 3/6] fs/resctrl: Make 'event_filter' files read only if they're not configurable

[Reinette Chatre]

Hi Ben,

On 3/16/26 10:02 AM, Ben Horgan wrote:
> Hi Tony,
> 
> On 3/16/26 16:27, Luck, Tony wrote:
>>>> Instead of making the file writable, and then fixing the mode. Maybe
>>>> patch the mode in res_common_files[] before calling rdtgroup_add_files():
>>>
>>>
>>> I initially rejected this idea because res_common_files[] is global and the
>>> read/write choice is per event type but we can safely save restore the mode as
>>> we're holding the rdtgroup mutex. How about this?
>>
>> That seems more complicated. Is there an expectation that event_filter
>> needs to be writable on the "total" event but not on the "local" one?
> 
> No, at least not currently. For mpam only the total event is supported.
> 
> Another way of doing it could be to patch the mode in res_common_files[] from
> resctrl_mkdir_event_configs() for both cases, 0444 and 0644, and change the
> starting value to something invalid, e.g. 0.

"event_filter"'s mode could be initialized similar to its fflags. Please see
resctrl_l3_mon_resource_init().

Stepping back, based on the v1 discussion I understand that BMEC does not
apply to MPAM so patching the BMEC specific resctrl_arch_is_evt_configurable() 
in patch #1 to support MPAM does not look right. From what I can tell we need a
new "configurable" property that is specific to assignable counters. I understand
naming is not ideal here but forcing the two independent features together like this
just because resctrl_arch_is_evt_configurable() has a generically relevant name is
not right.

Consider, for example, a new rdt_resource::resctrl_mon::mbm_cntr_configurable
property that arch can set. From resctrl fs side it would be a property that is
only considered if rdt_resource::resctrl_mon::mbm_cntr_assignable == true.

res_common_files[] can initialize the default mode of "event_filter" to be
read-only and resctrl_l3_mon_resource_init() can be expanded to to make
"event_filter" writable if both rdt_resource::resctrl_mon::mbm_cntr_assignable == true
AND rdt_resource::resctrl_mon::mbm_cntr_configurable == true.

Looking at this we do seem to have options between resctrl fs properties
and arch callbacks to do this and considering your earlier concern with
callbacks I wonder if resctrl fs properties would be better?
How about another new property, rdt_resource::resctrl_mon::mbm_cntr_assign_fixed
to replace resctrl_arch_mbm_cntr_assign_fixed()?

Reinette

Re: [PATCH v2 4/6] fs/resctrl: Disallow the software controller when mbm counters are assignable

[Reinette Chatre]

Hi Ben,

On 3/13/26 10:45 AM, Ben Horgan wrote:
> The software controller requires that there are free running mbm counters

How is "free running" defined?

(sidenote: please use upper case for acronyms throughout: mbm -> MBM)

> for each control group in order to provide the feedback necessary to
> control the memory bandwidth allocation for that control group.  Previous
> to the introduction counter assignment support (ABMC) resctrl required this

I am not able to parse this second sentence. "to the introduction" -> "to
the introduction of"? What does "this" refer to?

> in order to advertise support for mbm but now if the mbm counters are
> assignable then this can't be guaranteed.
> 
> Currently, only AMD systems support counter assignment but the MBA is non
> linear and so the software controller is never supported anyway. For MPAM
> systems the MBA is linear and so the dependency on counters not being
> assignable needs to made explicit. Hence, fail the mount if the user

It is not clear to me that software controller depends on counters not being
assignable. Is the problem not instead that the current implementation does not
support this since it allows the event used by software controller to not have a
counter assigned? So, instead of adding support for software controller by ensuring
that the event used by software controller has a counter assigned, this patch opts
for the simpler disabling of software controller when assignable counters are in use?

> requests the software controller, the mba_MBps option, and the mbm counters
> are assignable.

Reinette

Re: [PATCH v2 4/6] fs/resctrl: Disallow the software controller when mbm counters are assignable

[Ben Horgan]

Hi Reinette,

On 3/16/26 21:35, Reinette Chatre wrote:
> Hi Ben,
> 
> On 3/13/26 10:45 AM, Ben Horgan wrote:
>> The software controller requires that there are free running mbm counters
> 
> How is "free running" defined?

I mean that for each control group (and it's associated monitor groups) there are
dedicated MBM counters which are always present and always counting.
So, mon_event_count() always provides a value representative of the traffic
for that control group.

> 
> (sidenote: please use upper case for acronyms throughout: mbm -> MBM)

Ack

> 
>> for each control group in order to provide the feedback necessary to
>> control the memory bandwidth allocation for that control group.  Previous
>> to the introduction counter assignment support (ABMC) resctrl required this
> 
> I am not able to parse this second sentence. "to the introduction" -> "to
> the introduction of"? What does "this" refer to?

The 'this' was referring to the first sentence, that you need dedicated counters.

> 
>> in order to advertise support for mbm but now if the mbm counters are
>> assignable then this can't be guaranteed.
>>
>> Currently, only AMD systems support counter assignment but the MBA is non
>> linear and so the software controller is never supported anyway. For MPAM
>> systems the MBA is linear and so the dependency on counters not being
>> assignable needs to made explicit. Hence, fail the mount if the user
> 
> It is not clear to me that software controller depends on counters not being
> assignable. Is the problem not instead that the current implementation does not
> support this since it allows the event used by software controller to not have a
> counter assigned? So, instead of adding support for software controller by ensuring
> that the event used by software controller has a counter assigned, this patch opts
> for the simpler disabling of software controller when assignable counters are in use?

Yes, they are not fundamentally incompatible but it would require some changes
to the resctrl interface. Unless there are sufficient counters to have one per monitor
group it will always be the case that creating more groups will lead to missing a counter
for the software controller on one of the control groups. As I understand it, resctrl
doesn't have a way to indicate that you only get a control on certain control groups.

For MPAM it is possible to have counters that only match on PARTID and ignore PMG which
could reduce the counters needed to support the software controller. However, one
complication is that the (ignore PMG) counter doesn't match the count for the control
group if it has monitor groups with unassigned counters.

Thanks,

Ben
> 
>> requests the software controller, the mba_MBps option, and the mbm counters
>> are assignable.
> 
> Reinette
> 

Re: [PATCH v2 3/6] fs/resctrl: Make 'event_filter' files read only if they're not configurable

[Ben Horgan]

Hi Reinette,

On 3/16/26 17:29, Reinette Chatre wrote:
> Hi Ben,
> 
> On 3/16/26 10:02 AM, Ben Horgan wrote:
>> Hi Tony,
>>
>> On 3/16/26 16:27, Luck, Tony wrote:
>>>>> Instead of making the file writable, and then fixing the mode. Maybe
>>>>> patch the mode in res_common_files[] before calling rdtgroup_add_files():
>>>>
>>>>
>>>> I initially rejected this idea because res_common_files[] is global and the
>>>> read/write choice is per event type but we can safely save restore the mode as
>>>> we're holding the rdtgroup mutex. How about this?
>>>
>>> That seems more complicated. Is there an expectation that event_filter
>>> needs to be writable on the "total" event but not on the "local" one?
>>
>> No, at least not currently. For mpam only the total event is supported.
>>
>> Another way of doing it could be to patch the mode in res_common_files[] from
>> resctrl_mkdir_event_configs() for both cases, 0444 and 0644, and change the
>> starting value to something invalid, e.g. 0.
> 
> "event_filter"'s mode could be initialized similar to its fflags. Please see
> resctrl_l3_mon_resource_init().

Ok, this works if we shift to the rdt_resource::resctrl_mon::mbm_cntr_configurable
property you suggest below as that is scoped to all mbm events.

> 
> Stepping back, based on the v1 discussion I understand that BMEC does not
> apply to MPAM so patching the BMEC specific resctrl_arch_is_evt_configurable() 
> in patch #1 to support MPAM does not look right. From what I can tell we need a
> new "configurable" property that is specific to assignable counters. I understand
> naming is not ideal here but forcing the two independent features together like this
> just because resctrl_arch_is_evt_configurable() has a generically relevant name is
> not right.

Sure, we can consider them separately.

> 
> Consider, for example, a new rdt_resource::resctrl_mon::mbm_cntr_configurable
> property that arch can set. From resctrl fs side it would be a property that is
> only considered if rdt_resource::resctrl_mon::mbm_cntr_assignable == true.
> > res_common_files[] can initialize the default mode of "event_filter" to be
> read-only and resctrl_l3_mon_resource_init() can be expanded to to make
> "event_filter" writable if both rdt_resource::resctrl_mon::mbm_cntr_assignable == true
> AND rdt_resource::resctrl_mon::mbm_cntr_configurable == true.

Seems reasonable. I'll give this a go.

> 
> Looking at this we do seem to have options between resctrl fs properties
> and arch callbacks to do this and considering your earlier concern with
> callbacks I wonder if resctrl fs properties would be better?
> How about another new property, rdt_resource::resctrl_mon::mbm_cntr_assign_fixed
> to replace resctrl_arch_mbm_cntr_assign_fixed()?

As we've already got mbm_cntr_assignable and mbm_assign_on_mkdir in resctrl_mon
it won't seem out of place. I'll update this too.

> 
> Reinette

Thanks,

Ben

Re: [PATCH v2 4/6] fs/resctrl: Disallow the software controller when mbm counters are assignable

[Reinette Chatre]

Hi Ben,

On 3/17/26 4:13 AM, Ben Horgan wrote:
> Hi Reinette,
> 
> On 3/16/26 21:35, Reinette Chatre wrote:
>> Hi Ben,
>>
>> On 3/13/26 10:45 AM, Ben Horgan wrote:
>>> The software controller requires that there are free running mbm counters
>>
>> How is "free running" defined?
> 
> I mean that for each control group (and it's associated monitor groups) there are
> dedicated MBM counters which are always present and always counting.
> So, mon_event_count() always provides a value representative of the traffic
> for that control group.

This would be easier to parse if it was specific. For example, consider:
"there is one MBM counter per monitor group that is assigned to the event backing
the software controller (per mba_MBps_event)"

>> (sidenote: please use upper case for acronyms throughout: mbm -> MBM)
> 
> Ack
> 
>>
>>> for each control group in order to provide the feedback necessary to
>>> control the memory bandwidth allocation for that control group.  Previous
>>> to the introduction counter assignment support (ABMC) resctrl required this
>>
>> I am not able to parse this second sentence. "to the introduction" -> "to
>> the introduction of"? What does "this" refer to?
> 
> The 'this' was referring to the first sentence, that you need dedicated counters.

So "free running" means "dedicated"?

>>> in order to advertise support for mbm but now if the mbm counters are
>>> assignable then this can't be guaranteed.
>>>
>>> Currently, only AMD systems support counter assignment but the MBA is non
>>> linear and so the software controller is never supported anyway. For MPAM
>>> systems the MBA is linear and so the dependency on counters not being
>>> assignable needs to made explicit. Hence, fail the mount if the user
>>
>> It is not clear to me that software controller depends on counters not being
>> assignable. Is the problem not instead that the current implementation does not
>> support this since it allows the event used by software controller to not have a
>> counter assigned? So, instead of adding support for software controller by ensuring
>> that the event used by software controller has a counter assigned, this patch opts
>> for the simpler disabling of software controller when assignable counters are in use?
> 
> Yes, they are not fundamentally incompatible but it would require some changes
> to the resctrl interface. Unless there are sufficient counters to have one per monitor
> group it will always be the case that creating more groups will lead to missing a counter
> for the software controller on one of the control groups. As I understand it, resctrl
> doesn't have a way to indicate that you only get a control on certain control groups.

No, resctrl does not have a way to indicate that you only get a control on certain control
groups but I do not think this is relevant. The user provides the mba_MBps mount option and
that is when resctrl creates all files that includes automatic counter assignment, currently
only based on rdt_resource::resctrl_mon::mbm_assign_on_mkdir.
The dynamic assignment could take the software controller into account and fail the mount
if counters needed by software controller cannot be assigned. Similarly, counter assignment 
done after mount can take software controller into account to ensure the event used by software
controller always has a counter assigned.

I am not advocating for this support but instead noting that I do think that it is possible
to support software controller with assignable counters. If instead you still find that this
is a use case that you prefer not to support in MPAM then that is of course fine. When doing so
please let changelog be accurate regarding the choices instead of claiming MPAM cannot use software
controller because of assignable counters.

If you prefer this way then I think most accurate from resctrl fs perspective would be that the
mount should instead check whether assignable counter mode is *enabled* as opposed to supported
as this patch does, no? I understand this adds complexity since this would need to consider the
scenario where user space may later enable assignable counters after mounting resctrl with
software controller enabled though. It seems MPAM is attempting minimal resctrl changes to
reach a specific goal by using some generic motivations in changelog that are not accurate.

Finally, considering the message to user space:
"mba_MBps requires dedicated MBM counters and linear scale MBA at L3 scope"
upon reading above a user may attempt to explore how to solve the mount issue by fulfilling
the requirement of "dedicated MBM counters". How should a user interpred "dedicated MBM counters"?
It may be confusing to a user when a system indeed has sufficient counters but the mount
still fails.

How about instead something like below:
"mba_MBps requires MBM (assignable counters not supported) and linear scale MBA at L3 scope"
it is quite long so open to ideas.
 
Reinette

Re: [PATCH v2 4/6] fs/resctrl: Disallow the software controller when mbm counters are assignable

[Ben Horgan]

Hi Reinette,

On 3/17/26 17:17, Reinette Chatre wrote:
> Hi Ben,
> 
> On 3/17/26 4:13 AM, Ben Horgan wrote:
>> Hi Reinette,
>>
>> On 3/16/26 21:35, Reinette Chatre wrote:
>>> Hi Ben,
>>>
>>> On 3/13/26 10:45 AM, Ben Horgan wrote:
>>>> The software controller requires that there are free running mbm counters
>>>
>>> How is "free running" defined?
>>
>> I mean that for each control group (and it's associated monitor groups) there are
>> dedicated MBM counters which are always present and always counting.
>> So, mon_event_count() always provides a value representative of the traffic
>> for that control group.
> 
> This would be easier to parse if it was specific. For example, consider:
> "there is one MBM counter per monitor group that is assigned to the event backing
> the software controller (per mba_MBps_event)"
> 
>>> (sidenote: please use upper case for acronyms throughout: mbm -> MBM)
>>
>> Ack
>>
>>>
>>>> for each control group in order to provide the feedback necessary to
>>>> control the memory bandwidth allocation for that control group.  Previous
>>>> to the introduction counter assignment support (ABMC) resctrl required this
>>>
>>> I am not able to parse this second sentence. "to the introduction" -> "to
>>> the introduction of"? What does "this" refer to?
>>
>> The 'this' was referring to the first sentence, that you need dedicated counters.
> 
> So "free running" means "dedicated"?

Yes, continually running and counting the same thing.

> 
>>>> in order to advertise support for mbm but now if the mbm counters are
>>>> assignable then this can't be guaranteed.
>>>>
>>>> Currently, only AMD systems support counter assignment but the MBA is non
>>>> linear and so the software controller is never supported anyway. For MPAM
>>>> systems the MBA is linear and so the dependency on counters not being
>>>> assignable needs to made explicit. Hence, fail the mount if the user
>>>
>>> It is not clear to me that software controller depends on counters not being
>>> assignable. Is the problem not instead that the current implementation does not
>>> support this since it allows the event used by software controller to not have a
>>> counter assigned? So, instead of adding support for software controller by ensuring
>>> that the event used by software controller has a counter assigned, this patch opts
>>> for the simpler disabling of software controller when assignable counters are in use?
>>
>> Yes, they are not fundamentally incompatible but it would require some changes
>> to the resctrl interface. Unless there are sufficient counters to have one per monitor
>> group it will always be the case that creating more groups will lead to missing a counter
>> for the software controller on one of the control groups. As I understand it, resctrl
>> doesn't have a way to indicate that you only get a control on certain control groups.
> 
> No, resctrl does not have a way to indicate that you only get a control on certain control
> groups but I do not think this is relevant. The user provides the mba_MBps mount option and
> that is when resctrl creates all files that includes automatic counter assignment, currently
> only based on rdt_resource::resctrl_mon::mbm_assign_on_mkdir.
> The dynamic assignment could take the software controller into account and fail the mount
> if counters needed by software controller cannot be assigned. Similarly, counter assignment 
> done after mount can take software controller into account to ensure the event used by software
> controller always has a counter assigned.
> 
> I am not advocating for this support but instead noting that I do think that it is possible
> to support software controller with assignable counters. If instead you still find that this
> is a use case that you prefer not to support in MPAM then that is of course fine. When doing so
> please let changelog be accurate regarding the choices instead of claiming MPAM cannot use software
> controller because of assignable counters.
> 
> If you prefer this way then I think most accurate from resctrl fs perspective would be that the
> mount should instead check whether assignable counter mode is *enabled* as opposed to supported
> as this patch does, no? I understand this adds complexity since this would need to consider the
> scenario where user space may later enable assignable counters after mounting resctrl with
> software controller enabled though. It seems MPAM is attempting minimal resctrl changes to

Would disabling switching to mbm_event mode when the software controller is enabled be ok?

> reach a specific goal by using some generic motivations in changelog that are not accurate.

Apologies if the commit message aren't clear. I do see that I was confused in this one between
counters being assignable, i.e. mbm_event mode possible, and the user being the being able to
assign and unassign counters, i.e. mbm_event mode enabled. Do you prefer this as a commit message?

fs/resctrl: Disallow the software controller when using mbm_event mode

The software controller requires that there is one MBM counter, for each
domain, per monitor group that is assigned to the event backing the
software controller (the mba_MBps_event). When mbm_event mode is in use
this event backing cannot be guaranteed as there may be insufficient
counters, the user may unassign the counter or mbm_assign_on_mkdir may be
set to 0.

Currently, only AMD systems support counter assignment but the MBA is non
linear and so the software controller is never supported anyway. For MPAM
systems the MBA is linear and it could support the software controller.
Adding support would require guaranteeing that the events backing the
software controller are always assigned. In order to support mbm_event mode
for MPAM, which is needed to support memory bandwidth monitors, MBM, on
platforms with fewer bandwidth counters (per domain) than monitor groups,
take the pragmatic approach and fail the mount if the user requests the
software controller, the mba_MBps option, when the mbm_event mode is
enabled. Furthermore, disable switching to mbm_event mode when the software
controller is enabled. If, in the future, a way for mbm_event mode and the
software controller to function at the same time is introduced these
restrictions can be adapted.

> 
> Finally, considering the message to user space:
> "mba_MBps requires dedicated MBM counters and linear scale MBA at L3 scope"
> upon reading above a user may attempt to explore how to solve the mount issue by fulfilling
> the requirement of "dedicated MBM counters". How should a user interpred "dedicated MBM counters"?
> It may be confusing to a user when a system indeed has sufficient counters but the mount
> still fails.
> 
> How about instead something like below:
> "mba_MBps requires MBM (assignable counters not supported) and linear scale MBA at L3 scope"
> it is quite long so open to ideas.

How about mentioning the mbm_assign_mode to be more explicit. Maybe this?
"mba_MBps requires MBM (mbm_event mode not supported) and linear scale MBA at L3 scope"

>  
> Reinette
> 

Re: [PATCH v2 4/6] fs/resctrl: Disallow the software controller when mbm counters are assignable

[Ben Horgan]

Hi Reinette,

On 3/18/26 15:44, Ben Horgan wrote:

> 
> Apologies if the commit message aren't clear. I do see that I was confused in this one between
> counters being assignable, i.e. mbm_event mode possible, and the user being the being able to
> assign and unassign counters, i.e. mbm_event mode enabled. Do you prefer this as a commit message?
> 
> fs/resctrl: Disallow the software controller when using mbm_event mode
> 
> The software controller requires that there is one MBM counter, for each
> domain, per monitor group that is assigned to the event backing the
> software controller (the mba_MBps_event). When mbm_event mode is in use
> this event backing cannot be guaranteed as there may be insufficient
> counters, the user may unassign the counter or mbm_assign_on_mkdir may be
> set to 0.

Another case which could be mentioned here and  results in unassigned events
is when mbm_assign_on_mkdir is set to 1 but one of the domains was offline
when the monitor group was created.

> 
> Currently, only AMD systems support counter assignment but the MBA is non
> linear and so the software controller is never supported anyway. For MPAM
> systems the MBA is linear and it could support the software controller.
> Adding support would require guaranteeing that the events backing the
> software controller are always assigned. In order to support mbm_event mode
> for MPAM, which is needed to support memory bandwidth monitors, MBM, on
> platforms with fewer bandwidth counters (per domain) than monitor groups,
> take the pragmatic approach and fail the mount if the user requests the
> software controller, the mba_MBps option, when the mbm_event mode is
> enabled. Furthermore, disable switching to mbm_event mode when the software
> controller is enabled. If, in the future, a way for mbm_event mode and the
> software controller to function at the same time is introduced these
> restrictions can be adapted.
Thanks,

Ben

Re: [PATCH v2 4/6] fs/resctrl: Disallow the software controller when mbm counters are assignable

[Reinette Chatre]

Hi Ben,

On 3/18/26 8:44 AM, Ben Horgan wrote:

> 
> Apologies if the commit message aren't clear. I do see that I was confused in this one between
> counters being assignable, i.e. mbm_event mode possible, and the user being the being able to
> assign and unassign counters, i.e. mbm_event mode enabled. Do you prefer this as a commit message?

Since MPAM does not support switching between assignment modes it sounds as though MPAM 
treats support of assignable counters and enabling of assignable counters as
synonyms. As you hint in the new changelog there is a difference between what is technically
most correct and accurate and what is most pragmatic. It is ok to start with the pragmatic
approach but please do not disguise it as the one and only correct solution.

So, specifically, I think it is ok to use the check of mbm_cntr_assignable as you have in this
patch since it eliminates the unnecessary (because no architecture would run this code)
complication of additional post-mount checks of assignable mode and software controller
interactions. Please just be clear about the trade-offs and decisions in changelog.

> 
> fs/resctrl: Disallow the software controller when using mbm_event mode
> 
> The software controller requires that there is one MBM counter, for each
> domain, per monitor group that is assigned to the event backing the
> software controller (the mba_MBps_event). When mbm_event mode is in use
> this event backing cannot be guaranteed as there may be insufficient
> counters, the user may unassign the counter or mbm_assign_on_mkdir may be
> set to 0.
> 
> Currently, only AMD systems support counter assignment but the MBA is non
> linear and so the software controller is never supported anyway. For MPAM
> systems the MBA is linear and it could support the software controller.
> Adding support would require guaranteeing that the events backing the
> software controller are always assigned. In order to support mbm_event mode
> for MPAM, which is needed to support memory bandwidth monitors, MBM, on
> platforms with fewer bandwidth counters (per domain) than monitor groups,
> take the pragmatic approach and fail the mount if the user requests the

This changelog is a bit hard to parse ... note how it jumps from "Adding
support would require guaranteeing that the events backing the software
controller are always assigned." to "take the pragmatic approach and fail
the mount if the user requests the software controller."

> software controller, the mba_MBps option, when the mbm_event mode is
> enabled. Furthermore, disable switching to mbm_event mode when the software
> controller is enabled. If, in the future, a way for mbm_event mode and the
> software controller to function at the same time is introduced these
> restrictions can be adapted.
> 
>>
>> Finally, considering the message to user space:
>> "mba_MBps requires dedicated MBM counters and linear scale MBA at L3 scope"
>> upon reading above a user may attempt to explore how to solve the mount issue by fulfilling
>> the requirement of "dedicated MBM counters". How should a user interpred "dedicated MBM counters"?
>> It may be confusing to a user when a system indeed has sufficient counters but the mount
>> still fails.
>>
>> How about instead something like below:
>> "mba_MBps requires MBM (assignable counters not supported) and linear scale MBA at L3 scope"
>> it is quite long so open to ideas.
> 
> How about mentioning the mbm_assign_mode to be more explicit. Maybe this?
> "mba_MBps requires MBM (mbm_event mode not supported) and linear scale MBA at L3 scope"
Sounds good.

Reinette