linux-kernel - Re: [PATCH v2 4/5] x86/cpu: Add CPU type to struct cpuinfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4476c7a5-bc48-4686-b815-3fae0838b7f9@intel.com>
Date: Tue, 22 Oct 2024 09:03:12 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Borislav Petkov <bp@...en8.de>,
 Mario Limonciello <mario.limonciello@....com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
 "H . Peter Anvin" <hpa@...or.com>, "Rafael J . Wysocki" <rafael@...nel.org>,
 "Gautham R . Shenoy" <gautham.shenoy@....com>,
 Perry Yuan <perry.yuan@....com>, Brijesh Singh <brijesh.singh@....com>,
 Peter Zijlstra <peterz@...radead.org>, Li RongQing <lirongqing@...du.com>,
 "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
 <linux-kernel@...r.kernel.org>, "open list:ACPI"
 <linux-acpi@...r.kernel.org>,
 "open list:AMD PSTATE DRIVER" <linux-pm@...r.kernel.org>,
 Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
Subject: Re: [PATCH v2 4/5] x86/cpu: Add CPU type to struct cpuinfo_topology

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.