[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9534B53F-7B91-4525-97DC-889EC3836658@alien8.de>
Date: Mon, 21 Oct 2024 15:38:06 +0200
From: Borislav Petkov <bp@...en8.de>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
daniel.sneddon@...ux.intel.com, tony.luck@...el.com,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
linux-perf-users@...r.kernel.org, Josh Poimboeuf <jpoimboe@...nel.org>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>,
"Liang, Kan" <kan.liang@...ux.intel.com>,
Andrew Cooper <andrew.cooper3@...rix.com>,
Brice Goglin <brice.goglin@...il.com>,
Mario Limonciello <mario.limonciello@....com>,
Perry Yuan <Perry.Yuan@....com>, Dapeng Mi <dapeng1.mi@...ux.intel.com>
Subject: Re: [PATCH v4 02/10] x86/cpu/topology: Add CPU type to struct cpuinfo_topology
On October 18, 2024 10:30:53 PM GMT+02:00, Pawan Gupta <pawan.kumar.gupta@...ux.intel.com> wrote:
>I will drop "core", but can we keep "native"? "native" is used in SDM to
>define this field. Also model_id could be confused with model number.
>
> From Intel SDM Vol. 2A:
>
> Bits 23-00: Native model ID of the core. The core-type and native model
> ID can be used to uniquely identify the microarchitecture of the core.
> This native model ID is not unique across core types, and not related to
> the model ID reported in CPUID leaf 01H, and does not identify the SOC.
I'm still not clear on what "native" is supposed to mean here?
The core is born this way and then it changes... so this is its native model ID? Weird...
>Yes, topo.hw_cpu_type is initialized to TOPO_HW_CPU_TYPE_UNKNOWN. We should
>not ideally need the vendor check at all. As long as topo.hw_cpu_type has
>the core type, returning it should be enough here. For Intel hw_cpu_type
>also has the native_model_id, that is why we need the vendor check.
>
>If AMD or other vendors have similar use case, it makes sense to add the
>explicit vendor check. Please let me know if thats the likely case.
Yes, it either needs to be vendor-agnostic or you need to accommodate all vendors. Former sounds cleaner...
--
Sent from a small device: formatting sucks and brevity is inevitable.
Powered by blists - more mailing lists