The kcpuid CSV file will soon be updated with CPUID indices that are only
valid for certain CPU vendors, such as Centaur or Transmeta.  Thus,
introduce rudimentary x86 vendor detection to kcpuid.

Associate each known CPUID index range with a bitmask indicating its
compatible CPU vendors.  Define CPU vendor markers for Intel, AMD,
Centaur, and Transmeta.  Since fine-grained vendor detection is not
needed, classify Hygon CPUs under AMD and Zhaoxin CPUs under Centaur.

Mark standard (0x0) and extended (0x80000000) CPUID index ranges as valid
for all vendors, including unknown ones.  This ensures that kcpuid still
works in case of an x86 vendor detection failure.

Save the result of CPU vendor detection at a "this_cpu_vendor" global,
which will be utilized in next commits.

Note, to avoid needlessly complicating the kcpuid code, implement vendor
detection only in terms of leaf 0x0's EDX register.  Complete x86 vendor
detection can be later added if needed.

Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
---
 tools/arch/x86/kcpuid/kcpuid.c | 65 +++++++++++++++++++++++++++++++---
 1 file changed, 61 insertions(+), 4 deletions(-)

diff --git a/tools/arch/x86/kcpuid/kcpuid.c b/tools/arch/x86/kcpuid/kcpuid.c
index 6a4c845bc1de..36efcb753b77 100644
--- a/tools/arch/x86/kcpuid/kcpuid.c
+++ b/tools/arch/x86/kcpuid/kcpuid.c
@@ -8,12 +8,16 @@
 #include <stdlib.h>
 #include <string.h>
 
+typedef unsigned int u32;
+typedef unsigned long long u64;
+
 #define ARRAY_SIZE(x)	(sizeof(x) / sizeof((x)[0]))
+#define BIT(x)		(1UL << (x))
 #define min(a, b)	(((a) < (b)) ? (a) : (b))
 #define __noreturn	__attribute__((__noreturn__))
 
-typedef unsigned int u32;
-typedef unsigned long long u64;
+#define fourcc(a, b, c, d)	\
+	((u32)(a) | ((u32)(b) << 8) | ((u32)(c) << 16) | ((u32)(d) << 24))
 
 char *def_csv = "/usr/share/misc/cpuid.csv";
 char *user_csv;
@@ -65,6 +69,17 @@ struct cpuid_func {
 	int nr;
 };
 
+enum cpu_vendor {
+	VENDOR_INTEL		= BIT(0),
+	VENDOR_AMD		= BIT(1),	/* includes Hygon */
+	VENDOR_CENTAUR		= BIT(2),	/* includes Zhaoxin */
+	VENDOR_TRANSMETA	= BIT(3),
+	VENDOR_UNKNOWN		= BIT(15),
+	VENDOR_ALL		= ~0UL,
+};
+
+static enum cpu_vendor this_cpu_vendor;
+
 enum range_index {
 	RANGE_STD = 0,			/* Standard */
 	RANGE_EXT = 0x80000000,		/* Extended */
@@ -79,11 +94,17 @@ struct cpuid_range {
 	/* number of valid leafs */
 	int nr;
 	enum range_index index;
+	/* compatible cpu vendors */
+	enum cpu_vendor vendors;
 };
 
 static struct cpuid_range ranges[] = {
-	{	.index		= RANGE_STD,	},
-	{	.index		= RANGE_EXT,	},
+	{	.index		= RANGE_STD,
+		.vendors	= VENDOR_ALL,
+	},
+	{	.index		= RANGE_EXT,
+		.vendors	= VENDOR_ALL,
+	},
 };
 
 static char *range_to_str(struct cpuid_range *range)
@@ -145,6 +166,40 @@ static inline bool has_subleafs(u32 f)
 	return false;
 }
 
+/*
+ * Leaf 0x0 EDX output, CPU vendor ID string bytes 4 - 7.
+ */
+enum {
+	EDX_INTEL	= fourcc('i', 'n', 'e', 'I'),	/* Genu_ineI_ntel */
+	EDX_AMD		= fourcc('e', 'n', 't', 'i'),	/* Auth_enti_cAMD */
+	EDX_HYGON	= fourcc('n', 'G', 'e', 'n'),	/* Hygo_nGen_uine */
+	EDX_TRANSMETA	= fourcc('i', 'n', 'e', 'T'),	/* Genu_ineT_Mx86 */
+	EDX_CENTAUR	= fourcc('a', 'u', 'r', 'H'),	/* Cent_aurH_auls */
+	EDX_ZHAOXIN	= fourcc('a', 'n', 'g', 'h'),	/*   Sh_angh_ai	  */
+};
+
+static enum cpu_vendor identify_cpu_vendor(void)
+{
+	u32 eax = 0, ebx, ecx = 0, edx;
+
+	cpuid(&eax, &ebx, &ecx, &edx);
+
+	switch (edx) {
+	case EDX_INTEL:
+		return VENDOR_INTEL;
+	case EDX_AMD:
+	case EDX_HYGON:
+		return VENDOR_AMD;
+	case EDX_TRANSMETA:
+		return VENDOR_TRANSMETA;
+	case EDX_CENTAUR:
+	case EDX_ZHAOXIN:
+		return VENDOR_CENTAUR;
+	default:
+		return VENDOR_UNKNOWN;
+	}
+}
+
 static void leaf_print_raw(struct subleaf *leaf)
 {
 	if (has_subleafs(leaf->index)) {
@@ -671,6 +726,8 @@ int main(int argc, char *argv[])
 
 	parse_options(argc, argv);
 
+	this_cpu_vendor = identify_cpu_vendor();
+
 	/* Setup the cpuid leafs of current platform */
 	for_each_cpuid_range(range)
 		setup_cpuid_range(range);
-- 
2.48.1

On 3/6/25 12:49, Ahmed S. Darwish wrote:
> The kcpuid CSV file will soon be updated with CPUID indices that are only
> valid for certain CPU vendors, such as Centaur or Transmeta.  Thus,
> introduce rudimentary x86 vendor detection to kcpuid.

Do we really need the vendor detection? For example, look at the end of
cpuid(1)'s output:

   # cpuid -1 --raw
   ...
   0x20000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000
edx=0x00000000
   ...
   0x80860000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000
edx=0x00000000
   0xc0000000 0x00: eax=0x00000000 ebx=0x00000000 ecx=0x00000000
edx=0x00000000

It seems to just blindly poke at all of the CPUID regions. There are
only a handful of these and there's no hard in poking at them other
than an extra couple of executions of CPUID.

Hi,

On Fri, 07 Mar 2025, Dave Hansen wrote:
>
> Do we really need the vendor detection? For example, look at the end of
> cpuid(1)'s output:
>
...
>
> It seems to just blindly poke at all of the CPUID regions. There are
> only a handful of these and there's no hard in poking at them other
> than an extra couple of executions of CPUID.
>

Good point, thanks a lot.

I've checked the cpuid(1) code now.  Indeed, it just tries its luck for
all CPUID ranges.  If the returned CPUID range max function "does not
make sense" (i.e., smaller than the range's start index), it silently
ignores the whole range.

I'll do something similar in v2 then.

(After removing kcpuid's vendor check, its first run, where CPUID is
 invoked, will need a minor change.  kcpuid's second run, where the CSV
 file is parsed line by line, won't need any changes.  So, not adding CPU
 vendor checks is indeed a win.)

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH

On 3/6/25 12:49, Ahmed S. Darwish wrote:
> +/*
> + * Leaf 0x0 EDX output, CPU vendor ID string bytes 4 - 7.
> + */
> +enum {
> +	EDX_INTEL	= fourcc('i', 'n', 'e', 'I'),	/* Genu_ineI_ntel */
> +	EDX_AMD		= fourcc('e', 'n', 't', 'i'),	/* Auth_enti_cAMD */
> +	EDX_HYGON	= fourcc('n', 'G', 'e', 'n'),	/* Hygo_nGen_uine */
> +	EDX_TRANSMETA	= fourcc('i', 'n', 'e', 'T'),	/* Genu_ineT_Mx86 */
> +	EDX_CENTAUR	= fourcc('a', 'u', 'r', 'H'),	/* Cent_aurH_auls */
> +	EDX_ZHAOXIN	= fourcc('a', 'n', 'g', 'h'),	/*   Sh_angh_ai	  */
> +};

So, this is cute and all. But isn't it a _wee_ bit too clever for its
own good?

Why not just have a dumb array:

	{ INTEL, "GenuineIntel" },
	{ AMD,   "AuthenticAMD" ],
	...

Are we really looking to save a few dozen CPU cycles in this thing? It
took me at least a minute or two of staring at this thing to figure out
what the heck it was doing.

On Thu, 06 Mar 2025, Dave Hansen wrote:
>
> So, this is cute and all. But isn't it a _wee_ bit too clever for its
> own good?
>

That was funny, thanks for the laugh :)

> Why not just have a dumb array:
>
> 	{ INTEL, "GenuineIntel" },
> 	{ AMD,   "AuthenticAMD" ],
> 	...
>
> Are we really looking to save a few dozen CPU cycles in this thing? It
> took me at least a minute or two of staring at this thing to figure out
> what the heck it was doing.
>

Indeed.

For some reason I forgot that this is all little-endian and a simple
strcmp() like what the kernel does at get_cpu_vendor() would suffice.

I'll fix it in v2.

Thanks!
Ahmed

On March 7, 2025 5:48:03 AM PST, "Ahmed S. Darwish" <darwi@linutronix.de> wrote:
>On Thu, 06 Mar 2025, Dave Hansen wrote:
>>
>> So, this is cute and all. But isn't it a _wee_ bit too clever for its
>> own good?
>>
>
>That was funny, thanks for the laugh :)
>
>> Why not just have a dumb array:
>>
>> 	{ INTEL, "GenuineIntel" },
>> 	{ AMD,   "AuthenticAMD" ],
>> 	...
>>
>> Are we really looking to save a few dozen CPU cycles in this thing? It
>> took me at least a minute or two of staring at this thing to figure out
>> what the heck it was doing.
>>
>
>Indeed.
>
>For some reason I forgot that this is all little-endian and a simple
>strcmp() like what the kernel does at get_cpu_vendor() would suffice.
>
>I'll fix it in v2.
>
>Thanks!
>Ahmed

memcmp()

On 06/03/2025 8:49 pm, Ahmed S. Darwish wrote:
> @@ -145,6 +166,40 @@ static inline bool has_subleafs(u32 f)
>  	return false;
>  }
>  
> +/*
> + * Leaf 0x0 EDX output, CPU vendor ID string bytes 4 - 7.
> + */
> +enum {
> +	EDX_INTEL	= fourcc('i', 'n', 'e', 'I'),	/* Genu_ineI_ntel */
> +	EDX_AMD		= fourcc('e', 'n', 't', 'i'),	/* Auth_enti_cAMD */
> +	EDX_HYGON	= fourcc('n', 'G', 'e', 'n'),	/* Hygo_nGen_uine */
> +	EDX_TRANSMETA	= fourcc('i', 'n', 'e', 'T'),	/* Genu_ineT_Mx86 */
> +	EDX_CENTAUR	= fourcc('a', 'u', 'r', 'H'),	/* Cent_aurH_auls */
> +	EDX_ZHAOXIN	= fourcc('a', 'n', 'g', 'h'),	/*   Sh_angh_ai	  */
> +};
> +
> +static enum cpu_vendor identify_cpu_vendor(void)
> +{
> +	u32 eax = 0, ebx, ecx = 0, edx;
> +
> +	cpuid(&eax, &ebx, &ecx, &edx);
> +
> +	switch (edx) {
> +	case EDX_INTEL:
> +		return VENDOR_INTEL;
> +	case EDX_AMD:
> +	case EDX_HYGON:
> +		return VENDOR_AMD;
> +	case EDX_TRANSMETA:
> +		return VENDOR_TRANSMETA;
> +	case EDX_CENTAUR:
> +	case EDX_ZHAOXIN:
> +		return VENDOR_CENTAUR;
> +	default:
> +		return VENDOR_UNKNOWN;
> +	}

Many CPUs have ways of overriding the vendor string, thanks to
GenuineIntel being hardcoded in too many pieces of software.

I suggest you check all registers, lest you find yourself on a CPU
claiming EBX=0x68747541, ECX=0x6C65746E, EDX=0x6E65476E

~Andrew

On Thu, 06 Mar 2025, Andrew Cooper wrote:
>
> Many CPUs have ways of overriding the vendor string, thanks to
> GenuineIntel being hardcoded in too many pieces of software.
>
> I suggest you check all registers, lest you find yourself on a CPU
> claiming EBX=0x68747541, ECX=0x6C65746E, EDX=0x6E65476E
>

Indeed; will do.

Thanks,
Ahmed