Re: [PATCH v13 04/25] x86/resctrl: Centralize monitoring feature enumeration

[Luck, Tony]

On Mon, Oct 19, 2026 at 11:41:08PM +0800, Chen Yu wrote:
> Hi Tony,
> 
> On Mon, Sep 28, 2026 at 03:14:48PM -0700, Tony Luck wrote:
> > The original implementation of Intel Cache QoS Monitoring (CQM) planned
> > to integrate with the "perf" and "cgroup" subsystems. With that plan it
> > made sense for parameters from CPUID to be stored in fields of the
> > cpuinfo_x86 structure. But that plan was abandoned and the resctrl file
> > system user interface replaced it.
> > 
> > Centralize all L3 monitoring enumeration within resctrl in preparation for
> > removal of resctrl fields from struct cpuinfo_x86.
> > 
> > Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx>
> 
> [ ... ]
> 
> > @@ -132,11 +133,9 @@ static inline void __resctrl_sched_in(struct task_struct *tsk)
> >  
> >  static inline unsigned int resctrl_arch_round_mon_val(unsigned int val)
> >  {
> > -	unsigned int scale = boot_cpu_data.x86_cache_occ_scale;
> > -
> > -	/* h/w works in units of "boot_cpu_data.x86_cache_occ_scale" */
> > -	val /= scale;
> > -	return val * scale;
> > +	/* Round down to nearest h/w monitoring unit */
> > +	val /= rdt_l3_mon_scale;
> 
> I wonder if we should take this chance to check if rdt_l3_mon_scale is
> 0 on broken hardware?

RDT has now been on several generations of CPUs and so far h/w hasn't
been broken in this way.

> > +	return val * rdt_l3_mon_scale;
> >  }
> >  
> > + */
> > +unsigned int __ro_after_init rdt_l3_mon_scale;
> > +
> >  #define CF(cf)	((unsigned long)(1048576 * (cf) + 0.5))
> >  
> >  static int snc_nodes_per_l3_cache = 1;
> > @@ -418,16 +423,37 @@ static __init int snc_get_config(void)
> >  
> >  int __init rdt_get_l3_mon_config(struct rdt_resource *r)
> >  {
> > -	unsigned int mbm_offset = boot_cpu_data.x86_cache_mbm_width_offset;
> >  	struct rdt_hw_resource *hw_res = resctrl_to_arch_res(r);
> > +	unsigned int mbm_offset;
> >  	unsigned int threshold;
> >  	u32 eax, ebx, ecx, edx;
> > +	u32 num_rmid;
> > +
> > +	/* Resource monitoring leaf is 0xf. L3 monitoring details in subleaf 1 */
> > +	cpuid_count(0xf, 1, &eax, &ebx, &ecx, &edx);
> > +	mbm_offset = eax & GENMASK(7, 0);
> > +	rdt_l3_mon_scale = ebx;
> >
> 
> Sashiko warns me that ebx might be 0, would 
> rdt_l3_mon_scale = max(ebx, 1);
> be doable?

That would silently hide this theoretical problem and give strange results
to the user in ways that might be hard to debug.  Better to crash the
kernel with the divide by zero. Debugging that would be easy and quickly
point to h/w as the culprit.

> thanks,
> Chenyu

-Tony