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

[Ben Horgan]

Hi Reinette,

On 14/09/2026 16:16, Reinette Chatre wrote:
> 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.

Yes. I wasn't intending to suggest anything different. If r->mon_capable then the MPAM driver does
support all enabled events. Maybe I would would have been more to correct to just say if
r->mon_capable is true we confirm that we can do some monitoring.

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

No, we don't expect the MPAM driver to support any features inconsistently across resctrl domains.
If the hardware did happen to be mismatched then we sanitize it, in __class_props_mismatch() we
ensure the class only exposes the features that are common to all the child components.

Thanks,

Ben

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