On 10/22/24 04:57, Borislav Petkov wrote: > +enum x86_topology_cpu_type get_intel_cpu_type(struct cpuinfo_x86 *c) > +{ > + switch (c->topo.intel_type) { > + case 0x20: return TOPO_CPU_TYPE_EFFICIENCY; > + case 0x40: return TOPO_CPU_TYPE_PERFORMANCE; > + } > + return TOPO_CPU_TYPE_UNKNOWN; > +} This makes me feel a _bit_ uneasy. 0x20 here really does mean "Atom microarchitecture" and 0x40 means "Core microarchitecture". We want to encourage folks to use this new ABI when they want to find the fastest core to run on. But we don't want them to use it to bind to a CPU and then deploy Atom-specific optimizations. We *also* don't want the in-kernel code to do be doing things like: if (get_intel_cpu_type() == TOPO_CPU_TYPE_EFFICIENCY) setup_force_cpu_bug(FOO); That would fall over if Intel ever mixed fast and slow core types with the same microarchitecture, which is what AMD is doing today. Having: TOPO_CPU_TYPE_EFFICIENCY, and TOPO_CPU_TYPE_PERFORMANCE is totally fine in generic code. But we also need to preserve the: TOPO_HW_CPU_TYPE_INTEL_ATOM TOPO_HW_CPU_TYPE_INTEL_CORE values also for use in vendor-specific code. In the ABI, I think we should probably make this an explicit power/performance interface rather than "cpu_type". As much as I like the human readable "performance" and "efficiency", I'm worried it won't be flexible enough for future maniacal hardware designers. To be 100% clear, all the hardware designs that I know of would fit in a two-bucket ("performance" and "efficiency") scheme. But we've got to decide whether to commit to that forever.