Re: [RFC PATCH] arm_mpam: resctrl: Separate MPAM domains

[Reinette Chatre]

Hi Ben,

On 9/11/26 1:56 AM, Ben Horgan wrote:
> On 10/09/2026 19:10, Reinette Chatre wrote:

>>
>> Do (admittedly crude) guardrails like below capture the existing driver requirements?
>>
>> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
>> index 9d223057953a..dbd06371890c 100644
>> --- a/drivers/resctrl/mpam_resctrl.c
>> +++ b/drivers/resctrl/mpam_resctrl.c
>> @@ -1681,11 +1681,18 @@ mpam_resctrl_alloc_domain(unsigned int cpu, struct mpam_resctrl_res *res)
>>  				continue;       // dummy resource
>>  
>>  			mon_comp = find_component(mon->class, cpu);
>> +			if (!mon_comp) {
>> +				WARN_ON_ONCE(0);
>> +				err = -EFAULT;
>> +				goto offline_ctrl_domain;
>> +			}
>>  			dom->mon_comp[eventid] = mon_comp;
>> -			if (mon_comp)
>> -				any_mon_comp = mon_comp;
>> +			any_mon_comp = mon_comp;
> 
> This first part which ensures that if there is a class for the monitor then a component can always
> be found for the given CPU.
> 
>>  		}
>> -		if (!any_mon_comp) {
> 
> The any_mon_comp check could still be useful to confirm that if r->mon_capable then there is a
> component for at least one of the events.

resctrl fs does not handle such scenario. r->mon_capable guides whether the resource
supports monitoring and if it is then all domains belonging to the resource is expected to
support all monitoring events associated with the resource. resctrl fs will expose all the
monitoring event files based on r->mon_capable and which monitoring events are enabled, there
is no finer grained support to expose/hide events per domain.

If any_mon_comp is true while one of the mon_comp is NULL then resctrl will still expose the
event to user space and pass attempts to read the data to MPAM driver.

Is this a scenario that the MPAM driver needs to support? That is, users will see event files
but reading the data will succeed in some domains but fail in others? 
>> +
>> +		/* hack */
>> +		if (!cpumask_equal(&dom->mon_comp[QOS_L3_OCCUP_EVENT_ID]->affinity,
>> +				   &dom->mon_comp[QOS_L3_MBM_TOTAL_EVENT_ID]->affinity)) {
> 
> There doesn't necessary need to be a monitoring class associated with any particular event. If there
> are classes and so components for each of the two supported events then this check looks correct.
> You could ensure that by checking existence:
> 
> if (dom->mon_comp[QOS_L3_OCCUP_EVENT_ID] && dom->mon_comp[QOS_L3_MBM_TOTAL_EVENT_ID] &&
>     !cpumask_equal(&dom->mon_comp[QOS_L3_OCCUP_EVENT_ID]->affinity,
> 	           &dom->mon_comp[QOS_L3_MBM_TOTAL_EVENT_ID]->affinity))

Right thanks, this needs to be more robust. Essentially this is the finer grained check that
ensures that if the domain supports both events then the backing components have the same "shape".

Reinette