Re: [PATCH v1 1/4] x86,fs/resctrl: Make resctrl_arch_is_evt_configurable() aware of mbm_assign_mode

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Ben,

On 2/25/26 12:19 PM, Ben Horgan wrote:
> 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

Since the goal is to support MPAM I'd suggest that the first focus be on what
resctrl fs supports and exposes and how it does or does not work for MPAM.

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

Does MPAM support exactly these two features? Specifically, does MPAM support
a feature that allows user to configure events globally per domain and another
feature that allows user to configure events per PMG?

These different features are how I understand assignable counters and BMEC to
be and to support both at the same time requires a user interface that is
confusing since the user can concurrently configure events globally per-domain
and per resource group.

Could you please elaborate how event configuration work on MPAM? If find this
series quite cryptic. I think it will help if you could elaborate what MPAM
capabilities are and how you expect resctrl fs to expose these features to
an MPAM user and how said used is expected to interact with resctrl fs to use
the features.

> 
> 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..d35f4417d55e 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 assignable)
>  {
> -	if (!rdt_cpu_has(X86_FEATURE_BMEC))
> +	if (!assignable && !rdt_cpu_has(X86_FEATURE_BMEC))
>  		return false;
>  
> +	if (assignable && !rdt_cpu_has(X86_FEATURE_ABMC))
> +		return false;
> +

I find this very confusing. 

> +	/*
> +	 * 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);


Reinette