Re: [PATCH v9 06/12] arm,x86,fs/resctrl: Handle change in number of RMIDs on each mount

["Luck, Tony" <tony.luck@intel.com>]

On Tue, Jul 14, 2026 at 09:45:04AM -0700, Reinette Chatre wrote:
> Hi Tony,

... trimming to open issue ...

> >> How much to rely on CPUID is not clear to me. The direction seems to
> >> be to move away from CPUID, which makes adding new CPUID dependencies
> >> less ideal? 

Where is this direction to move away from CPUID coming from?

> > Here's my current work-in-progress version:
> > 
> > u32 resctrl_arch_system_max_rmid_idx(void)
> > {
> > 	struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl;
> > 	u32 ret;
> > 
> > 	/* CPUID provides maximum possible RMID value */
> > 	ret = cpuid_ebx(0xf) + 1;
> 
> There is also boot_cpu_data.x86_cache_max_rmid initialized in resctrl_cpu_detect() that
> could be used directly? Looks like resctrl_cpu_detect() already scales the number of
> RMID down if needed when L3 monitoring is supported, but it does not take SNC into account.

I looked at that, but rejected it because it isn't adjusted for SNC.

> 
> > 
> > 	/*
> > 	 * if system is capable of L3 monitoring the maximum RMID value may
> > 	 * be lower that system maximum. Either because the L3 monitoring
> > 	 * feature supports fewer RMIDs (CPUID(0xF, 0x1).ECX), or because SNC
> > 	 * (Sub-NUMA Cluster) is enabled and divides RMIDs per cluster.
> > 	 */
> > 	if (r->mon_capable)
> > 		ret = r->mon.num_rmid;
> > 
> > 	return ret;
> > }
> > 
> > CPUID seems unavoidable in the case that the platform doesn't support
> > (or has disabled the various L3 monitoring events). In that case using
> 
> Since L3 monitoring is the only CPUID supported monitoring resource I do not
> think cpuid_ebx(0xf) can be used if the platform does not support L3 monitoring.
> I expect that would mean that leaf 0x7 would indicate that monitoring is
> not supported which would make leaf 0xf invalid? Interestingly resctrl does
> not seem to consider X86_FEATURE_CQM from leaf 0x7 at all and just goes straight
> to leaf 0xf.

I disagree. The definition of IA32_PQR_ASSOC says:

1) The MSR exists if either of CPUID.07H.00H:EBX[12] or CPUID.07H.00H:EBX[15] is set
   (in this case bit 12 for monitoring, It does appear to be a bug that resctrl is
   not checking bit 12 before looking at leaf 0xF).

2) The supported width of the RMID field is Ceil(Log2 (CPUID.0FH.00H:EBX[31:0] +1))

So I believe that a theoretical system that supported AET (or some other
monitoring) but didn't support L3 monitoring, would have to set CPUID.07H.00H:EBX[12]
and provide the max RMID value in CPUID.0FH.00H:EBX[31:0].

For resctrl we have the practical case of booting with "rdt=!cmt,!mbmtotal,!mbmlocal"
to software disable all L3 monitoring.

-Tony