Re: [PATCH v12 15/25] x86,fs/resctrl: Handle systems where AET is the only resource

[Reinette Chatre]

Hi Tony,

On 9/25/26 8:50 AM, Luck, Tony wrote:
> On Fri, Sep 25, 2026 at 07:37:20AM -0700, Reinette Chatre wrote:
>> Hi Tony,
>>
>> On 9/24/26 5:06 PM, Luck, Tony wrote:
>>> On Thu, Sep 24, 2026 at 01:41:48PM -0700, Reinette Chatre wrote:
>>>> On 9/16/26 4:13 PM, Tony Luck wrote:
>>
>>>>> @@ -1001,27 +1001,29 @@ static __init bool get_rdt_mon_resources(void)
>>>>>  
>>>>>  	/* Any of the L3 monitoring features? */
>>>>>  	if (!cpu_feature_enabled(X86_FEATURE_CQM_LLC))
>>>>> -		return false;
>>>>> +		goto skip_l3_feature_checks;
>>>>
>>>> This goto looks unnecessary. Why not just "return true"? Even so, this 
>>>> also changes behavior from the previous version in a way that is not clear
>>>> to me. I was expecting this to consider the number of RMIDs supported by the system,
>>>> now that this function added:
>>>>
>>>> 	pqr_assoc_num_rmid = cpuid_ebx(0xf) + 1;
>>>>
>>>> Should this be:
>>>>
>>>> 	if (!cpu_feature_enabled(X86_FEATURE_CQM_LLC))
>>>> 		return pqr_assoc_num_rmid > 1;
>>>>
>>>> Although ... looking at this closer it does look strange for pqr_assoc_num_rmid
>>>> to be 1, thus reflecting that the system supports one RMID, when zero may be more
>>>> accurate?
>>>
>>> If X86_FEATURE_CQM_LLC is set, then monitoring is supported and the system
>>> must support at least one RMID. I don't see a need to insist on more than one
>>> RMID as a precondition for using resctrl. It wouldn't be super interesting
>>
>> My suggestion was not to use "more than one RMID as a precondition". By copying the
>> relevant code not shown in the hunk
>>
>> 	pqr_assoc_num_rmid = cpuid_ebx(0xf) + 1;
>>
>> I aimed to highlight that if the system returns zero then pqr_assoc_num_rmid
>> will contain 1. The "pqr_assoc_num_rmid > 1" is thus not a check for "more
>> than one RMID" but instead a check that the system did not return zero.
> 
> Architecturally the cpuid_ebx(0xf) can legally return 0 meaning that the
> system supports one RMID. Here's the description from SDM Volume 1 Table
> 21-38 "Leaf 0FH.00H Intel® Resource Director Technology (Intel® RDT) Monitoring":
> 
> 	Register	Field Name	Description
> 	EBX[31:0]	MAX_RMID	Maximum range (zero-based) of RMID within
> 					this physical processor of all types.
> 
> This code path is only executed if the test for X86_FEATURE_CQM
> succeeded. That should guarantee that leaf 0xF exists[1]. There's
> no way for leaf 0xF to indicate zero RMIDs because the MAX_RMID
> field gives a zero-based result.
> 
> So a test for "pqr_assoc_num_rmid > 1" really is checking that two or
> more RMIDs are supported.
> 
> If you want resctrl to refuse to support a crazy system with only one
> RMID, then the check should as soon as pqr_assoc_num_rmid is set:
> 
> 	pqr_assoc_num_rmid = cpuid_ebx(0xf) + 1;
> 
> 	/* Systems with only one RMID can't usefully support resctrl */
> 	if (pqr_assoc_num_rmid == 1)
> 		return false;

Up to you. I already highlighted in

	https://lore.kernel.org/lkml/39582d24-0fc1-4d5e-bc05-01c2f29ddfb1@xxxxxxxxx/

that my goal is simply to align this version to the previous 

	https://lore.kernel.org/lkml/20260831174421.13921-14-tony.luck@xxxxxxxxx/

that used 

	return resctrl_arch_system_max_rmid_idx() > 0

to determine if AET can supported.

Ignoring this simple question in

	https://lore.kernel.org/lkml/arW6xlQWVWkixiWe@agluck-desk3/

you instead use the SDM to argue against me for some reason.

Reinette