Re: [PATCH] x86/topo: Map vendor CPU types to generic Linux such types

On Wed, Jul 22, 2026 at 11:31:52AM -0700, Borislav Petkov wrote:
> On Wed, Jul 22, 2026 at 11:09:58AM -0700, Pawan Gupta wrote:
> > > +enum x86_topology_cpu_type {
> > > +	/* X86_CPU_TYPE_ANY */
> > > +	TOPO_CPU_TYPE_ANY = 0,
> > 
> > I don't really understand the purpose of TOPO_CPU_TYPE_ANY here. In the cpu
> > matching infrastructure, X86_CPU_TYPE_ANY makes sense. Here I fail to
> > understand how is TOPO_CPU_TYPE_ANY different from UNKNOWN? A table passed
> > to x86_match_cpu() with X86_CPU_TYPE_ANY entry will match any CPU type
> > including TOPO_CPU_TYPE_UNKNOWN.
> 
> This will go away in future patches. We do one logical thing per patch and
> removing UNKNOWN is not it. I have it on my TODO list to clean up everything
> here.

Unless I am misreading, TOPO_CPU_TYPE_ANY is introduced in this patch.
X86_*_ANY in x86_match_cpu() are much needed wildcards, I dont really
understand why x86_topology_cpu_type needs to carry a wildcard. It should
reflect the true state, PERFORMANCE, EFFICIENCY or UNKNOWN.

Between ANY and UNKNOWN, I would prefer UNKNOWN when CPU did not report a
type.

> > 
> > > +	TOPO_CPU_TYPE_PERFORMANCE,
> > > +	TOPO_CPU_TYPE_EFFICIENCY,
> > > +	TOPO_CPU_TYPE_UNKNOWN,
> > > +};
> 
> ...
> 
> > > @@ -81,7 +53,7 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
> > >  			continue;
> > >  		if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
> > >  			continue;
> > > -		if (!x86_match_vendor_cpu_type(c, m))
> > > +		if (m->type != X86_CPU_TYPE_ANY && c->topo.cpu_type != m->type)
> > 
> > In line with what Thomas pointed that cpu_type is not a system property, I
> > suggest matching cpu_type should be dropped from x86_match_cpu(). More so
> > because it only uses boot_cpu_data and misses the other types of secondary
> > CPUs. I feel it is not a reliable way to match CPU types. Thoughts?
> 
> How do you suggest we match CPU types on the whole system?
> 
> I.e., "do this workaround only on the performance cores", for example.
> 
> c->topo.cpu_type is perfect for that then.

Ya. If need be, a mask of each possible cpu_type can be built for
dispatching work selectively.