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

[Luck, Tony]

Hi Reinette,

On Fri, Sep 25, 2026 at 09:39:13AM -0700, Reinette Chatre wrote:
> 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.

My apologies. I should have included in the version change log from v11
to v12 that I replaced "resctrl_arch_system_max_rmid_idx() > 0" because
it is the wrong thing to do.

I'll try to be more complete in the change logs.

-Tony