Re: [PATCH 1/2] x86/topology: Name the AMD core-type values

[Thomas Gleixner]

On Tue, Jul 07 2026 at 10:52, Pawan Gupta wrote:
> On Mon, Jul 06, 2026 at 05:47:13PM -0700, Borislav Petkov wrote:
>> On Mon, Jul 06, 2026 at 11:29:07AM -0700, Pawan Gupta wrote:
>> > >  /**
>> > >   * x86_match_cpu - match current CPU against an array of x86_cpu_ids
>> > >   * @match: Pointer to array of x86_cpu_ids. Last entry terminated with
>> > > @@ -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)
>> > 
>> > ... matching a hybrid CPU to any cpu_type.
>> 
>> I don't know what you mean here.
>
> Vulnerability enumeration is done on the BSP, for a hybrid system with BSP
> as a performance-core, a vulnerability that only affects efficiency-cores
> would not be enumerated. So, x86_match_cpu() currently returns a match for
> any cpu-type on a hybrid system.

Abusing the type, which enumerates performance properties, for
vulnerability crystal ball logic is simply broken.

The type is a per CPU property and has nothing to do with hybrid or
not. Hybrid is a packet property.

Just because it is convenient does not make it more correct. If you need
to enable mitigations on hybrid systems, then explicitely check for the
hybrid property.

Thanks,

        tglx