[PATCH 0/5] x86/cpu: Introduce <asm/cpuid/types.h> and <asm/cpuid/api.h> and clean them up

[PATCH 0/5] x86/cpu: Introduce <asm/cpuid/types.h> and <asm/cpuid/api.h> and clean them up

[mingo]

From: Ingo Molnar <mingo@kernel.org>

This series contains Ahmed S. Darwish's splitting up of <asm/cpuid.h>
into <asm/cpuid/types.h> and <asm/cpuid/api.h>, followed by a couple
of cleanups that create a more maintainable base.

[ This is a resend with a proper SMTP setup. Apologies for the duplication. ]

Thanks,

	Ingo

================>
Ahmed S. Darwish (1):
  x86/cpuid: Refactor <asm/cpuid.h>

Ingo Molnar (4):
  x86/cpuid: Clean up <asm/cpuid/types.h>
  x86/cpuid: Clean up <asm/cpuid/api.h>
  x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>
  x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

 arch/x86/include/asm/cpuid.h       | 217 +--------------------------------------------------------
 arch/x86/include/asm/cpuid/api.h   | 210 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/cpuid/types.h |  32 +++++++++
 3 files changed, 243 insertions(+), 216 deletions(-)
 create mode 100644 arch/x86/include/asm/cpuid/api.h
 create mode 100644 arch/x86/include/asm/cpuid/types.h

-- 
2.45.2

[PATCH 1/5] x86/cpuid: Refactor <asm/cpuid.h>

[mingo]

From: "Ahmed S. Darwish" <darwi@linutronix.de>

In preparation for future commits where CPUID headers will be expanded,
refactor the CPUID header <asm/cpuid.h> into:

    asm/cpuid/
    ├── api.h
    └── types.h

Move the CPUID data structures into <asm/cpuid/types.h> and the access
APIs into <asm/cpuid/api.h>.  Let <asm/cpuid.h> be just an include of
<asm/cpuid/api.h> so that existing call sites do not break.

Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250317164745.4754-3-darwi@linutronix.de
---
 arch/x86/include/asm/cpuid.h       | 217 +--------------------------------------------------------
 arch/x86/include/asm/cpuid/api.h   | 208 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/x86/include/asm/cpuid/types.h |  29 ++++++++
 3 files changed, 238 insertions(+), 216 deletions(-)

diff --git a/arch/x86/include/asm/cpuid.h b/arch/x86/include/asm/cpuid.h
index a92e4b08820a..d5749b25fa10 100644
--- a/arch/x86/include/asm/cpuid.h
+++ b/arch/x86/include/asm/cpuid.h
@@ -1,223 +1,8 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-/*
- * CPUID-related helpers/definitions
- */
 
 #ifndef _ASM_X86_CPUID_H
 #define _ASM_X86_CPUID_H
 
-#include <linux/build_bug.h>
-#include <linux/types.h>
-
-#include <asm/string.h>
-
-struct cpuid_regs {
-	u32 eax, ebx, ecx, edx;
-};
-
-enum cpuid_regs_idx {
-	CPUID_EAX = 0,
-	CPUID_EBX,
-	CPUID_ECX,
-	CPUID_EDX,
-};
-
-#define CPUID_LEAF_MWAIT	0x5
-#define CPUID_LEAF_DCA		0x9
-#define CPUID_LEAF_XSTATE	0x0d
-#define CPUID_LEAF_TSC		0x15
-#define CPUID_LEAF_FREQ		0x16
-#define CPUID_LEAF_TILE		0x1d
-
-#ifdef CONFIG_X86_32
-bool have_cpuid_p(void);
-#else
-static inline bool have_cpuid_p(void)
-{
-	return true;
-}
-#endif
-static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
-				unsigned int *ecx, unsigned int *edx)
-{
-	/* ecx is often an input as well as an output. */
-	asm volatile("cpuid"
-	    : "=a" (*eax),
-	      "=b" (*ebx),
-	      "=c" (*ecx),
-	      "=d" (*edx)
-	    : "0" (*eax), "2" (*ecx)
-	    : "memory");
-}
-
-#define native_cpuid_reg(reg)					\
-static inline unsigned int native_cpuid_##reg(unsigned int op)	\
-{								\
-	unsigned int eax = op, ebx, ecx = 0, edx;		\
-								\
-	native_cpuid(&eax, &ebx, &ecx, &edx);			\
-								\
-	return reg;						\
-}
-
-/*
- * Native CPUID functions returning a single datum.
- */
-native_cpuid_reg(eax)
-native_cpuid_reg(ebx)
-native_cpuid_reg(ecx)
-native_cpuid_reg(edx)
-
-#ifdef CONFIG_PARAVIRT_XXL
-#include <asm/paravirt.h>
-#else
-#define __cpuid			native_cpuid
-#endif
-
-/*
- * Generic CPUID function
- * clear %ecx since some cpus (Cyrix MII) do not set or clear %ecx
- * resulting in stale register contents being returned.
- */
-static inline void cpuid(unsigned int op,
-			 unsigned int *eax, unsigned int *ebx,
-			 unsigned int *ecx, unsigned int *edx)
-{
-	*eax = op;
-	*ecx = 0;
-	__cpuid(eax, ebx, ecx, edx);
-}
-
-/* Some CPUID calls want 'count' to be placed in ecx */
-static inline void cpuid_count(unsigned int op, int count,
-			       unsigned int *eax, unsigned int *ebx,
-			       unsigned int *ecx, unsigned int *edx)
-{
-	*eax = op;
-	*ecx = count;
-	__cpuid(eax, ebx, ecx, edx);
-}
-
-/*
- * CPUID functions returning a single datum
- */
-static inline unsigned int cpuid_eax(unsigned int op)
-{
-	unsigned int eax, ebx, ecx, edx;
-
-	cpuid(op, &eax, &ebx, &ecx, &edx);
-
-	return eax;
-}
-
-static inline unsigned int cpuid_ebx(unsigned int op)
-{
-	unsigned int eax, ebx, ecx, edx;
-
-	cpuid(op, &eax, &ebx, &ecx, &edx);
-
-	return ebx;
-}
-
-static inline unsigned int cpuid_ecx(unsigned int op)
-{
-	unsigned int eax, ebx, ecx, edx;
-
-	cpuid(op, &eax, &ebx, &ecx, &edx);
-
-	return ecx;
-}
-
-static inline unsigned int cpuid_edx(unsigned int op)
-{
-	unsigned int eax, ebx, ecx, edx;
-
-	cpuid(op, &eax, &ebx, &ecx, &edx);
-
-	return edx;
-}
-
-static inline void __cpuid_read(unsigned int leaf, unsigned int subleaf, u32 *regs)
-{
-	regs[CPUID_EAX] = leaf;
-	regs[CPUID_ECX] = subleaf;
-	__cpuid(regs + CPUID_EAX, regs + CPUID_EBX, regs + CPUID_ECX, regs + CPUID_EDX);
-}
-
-#define cpuid_subleaf(leaf, subleaf, regs) {		\
-	static_assert(sizeof(*(regs)) == 16);		\
-	__cpuid_read(leaf, subleaf, (u32 *)(regs));	\
-}
-
-#define cpuid_leaf(leaf, regs) {			\
-	static_assert(sizeof(*(regs)) == 16);		\
-	__cpuid_read(leaf, 0, (u32 *)(regs));		\
-}
-
-static inline void __cpuid_read_reg(unsigned int leaf, unsigned int subleaf,
-				    enum cpuid_regs_idx regidx, u32 *reg)
-{
-	u32 regs[4];
-
-	__cpuid_read(leaf, subleaf, regs);
-	*reg = regs[regidx];
-}
-
-#define cpuid_subleaf_reg(leaf, subleaf, regidx, reg) {		\
-	static_assert(sizeof(*(reg)) == 4);			\
-	__cpuid_read_reg(leaf, subleaf, regidx, (u32 *)(reg));	\
-}
-
-#define cpuid_leaf_reg(leaf, regidx, reg) {			\
-	static_assert(sizeof(*(reg)) == 4);			\
-	__cpuid_read_reg(leaf, 0, regidx, (u32 *)(reg));	\
-}
-
-static __always_inline bool cpuid_function_is_indexed(u32 function)
-{
-	switch (function) {
-	case 4:
-	case 7:
-	case 0xb:
-	case 0xd:
-	case 0xf:
-	case 0x10:
-	case 0x12:
-	case 0x14:
-	case 0x17:
-	case 0x18:
-	case 0x1d:
-	case 0x1e:
-	case 0x1f:
-	case 0x24:
-	case 0x8000001d:
-		return true;
-	}
-
-	return false;
-}
-
-#define for_each_possible_hypervisor_cpuid_base(function) \
-	for (function = 0x40000000; function < 0x40010000; function += 0x100)
-
-static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
-{
-	uint32_t base, eax, signature[3];
-
-	for_each_possible_hypervisor_cpuid_base(base) {
-		cpuid(base, &eax, &signature[0], &signature[1], &signature[2]);
-
-		/*
-		 * This must not compile to "call memcmp" because it's called
-		 * from PVH early boot code before instrumentation is set up
-		 * and memcmp() itself may be instrumented.
-		 */
-		if (!__builtin_memcmp(sig, signature, 12) &&
-		    (leaves == 0 || ((eax - base) >= leaves)))
-			return base;
-	}
-
-	return 0;
-}
+#include <asm/cpuid/api.h>
 
 #endif /* _ASM_X86_CPUID_H */
diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
new file mode 100644
index 000000000000..4d1da9cc8b6f
--- /dev/null
+++ b/arch/x86/include/asm/cpuid/api.h
@@ -0,0 +1,208 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_X86_CPUID_API_H
+#define _ASM_X86_CPUID_API_H
+
+#include <linux/build_bug.h>
+#include <linux/types.h>
+
+#include <asm/cpuid/types.h>
+#include <asm/string.h>
+
+/*
+ * Raw CPUID accessors
+ */
+
+#ifdef CONFIG_X86_32
+bool have_cpuid_p(void);
+#else
+static inline bool have_cpuid_p(void)
+{
+	return true;
+}
+#endif
+static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
+				unsigned int *ecx, unsigned int *edx)
+{
+	/* ecx is often an input as well as an output. */
+	asm volatile("cpuid"
+	    : "=a" (*eax),
+	      "=b" (*ebx),
+	      "=c" (*ecx),
+	      "=d" (*edx)
+	    : "0" (*eax), "2" (*ecx)
+	    : "memory");
+}
+
+#define native_cpuid_reg(reg)					\
+static inline unsigned int native_cpuid_##reg(unsigned int op)	\
+{								\
+	unsigned int eax = op, ebx, ecx = 0, edx;		\
+								\
+	native_cpuid(&eax, &ebx, &ecx, &edx);			\
+								\
+	return reg;						\
+}
+
+/*
+ * Native CPUID functions returning a single datum.
+ */
+native_cpuid_reg(eax)
+native_cpuid_reg(ebx)
+native_cpuid_reg(ecx)
+native_cpuid_reg(edx)
+
+#ifdef CONFIG_PARAVIRT_XXL
+#include <asm/paravirt.h>
+#else
+#define __cpuid			native_cpuid
+#endif
+
+/*
+ * Generic CPUID function
+ * clear %ecx since some cpus (Cyrix MII) do not set or clear %ecx
+ * resulting in stale register contents being returned.
+ */
+static inline void cpuid(unsigned int op,
+			 unsigned int *eax, unsigned int *ebx,
+			 unsigned int *ecx, unsigned int *edx)
+{
+	*eax = op;
+	*ecx = 0;
+	__cpuid(eax, ebx, ecx, edx);
+}
+
+/* Some CPUID calls want 'count' to be placed in ecx */
+static inline void cpuid_count(unsigned int op, int count,
+			       unsigned int *eax, unsigned int *ebx,
+			       unsigned int *ecx, unsigned int *edx)
+{
+	*eax = op;
+	*ecx = count;
+	__cpuid(eax, ebx, ecx, edx);
+}
+
+/*
+ * CPUID functions returning a single datum
+ */
+
+static inline unsigned int cpuid_eax(unsigned int op)
+{
+	unsigned int eax, ebx, ecx, edx;
+
+	cpuid(op, &eax, &ebx, &ecx, &edx);
+
+	return eax;
+}
+
+static inline unsigned int cpuid_ebx(unsigned int op)
+{
+	unsigned int eax, ebx, ecx, edx;
+
+	cpuid(op, &eax, &ebx, &ecx, &edx);
+
+	return ebx;
+}
+
+static inline unsigned int cpuid_ecx(unsigned int op)
+{
+	unsigned int eax, ebx, ecx, edx;
+
+	cpuid(op, &eax, &ebx, &ecx, &edx);
+
+	return ecx;
+}
+
+static inline unsigned int cpuid_edx(unsigned int op)
+{
+	unsigned int eax, ebx, ecx, edx;
+
+	cpuid(op, &eax, &ebx, &ecx, &edx);
+
+	return edx;
+}
+
+static inline void __cpuid_read(unsigned int leaf, unsigned int subleaf, u32 *regs)
+{
+	regs[CPUID_EAX] = leaf;
+	regs[CPUID_ECX] = subleaf;
+	__cpuid(regs + CPUID_EAX, regs + CPUID_EBX, regs + CPUID_ECX, regs + CPUID_EDX);
+}
+
+#define cpuid_subleaf(leaf, subleaf, regs) {		\
+	static_assert(sizeof(*(regs)) == 16);		\
+	__cpuid_read(leaf, subleaf, (u32 *)(regs));	\
+}
+
+#define cpuid_leaf(leaf, regs) {			\
+	static_assert(sizeof(*(regs)) == 16);		\
+	__cpuid_read(leaf, 0, (u32 *)(regs));		\
+}
+
+static inline void __cpuid_read_reg(unsigned int leaf, unsigned int subleaf,
+				    enum cpuid_regs_idx regidx, u32 *reg)
+{
+	u32 regs[4];
+
+	__cpuid_read(leaf, subleaf, regs);
+	*reg = regs[regidx];
+}
+
+#define cpuid_subleaf_reg(leaf, subleaf, regidx, reg) {		\
+	static_assert(sizeof(*(reg)) == 4);			\
+	__cpuid_read_reg(leaf, subleaf, regidx, (u32 *)(reg));	\
+}
+
+#define cpuid_leaf_reg(leaf, regidx, reg) {			\
+	static_assert(sizeof(*(reg)) == 4);			\
+	__cpuid_read_reg(leaf, 0, regidx, (u32 *)(reg));	\
+}
+
+static __always_inline bool cpuid_function_is_indexed(u32 function)
+{
+	switch (function) {
+	case 4:
+	case 7:
+	case 0xb:
+	case 0xd:
+	case 0xf:
+	case 0x10:
+	case 0x12:
+	case 0x14:
+	case 0x17:
+	case 0x18:
+	case 0x1d:
+	case 0x1e:
+	case 0x1f:
+	case 0x24:
+	case 0x8000001d:
+		return true;
+	}
+
+	return false;
+}
+
+#define for_each_possible_hypervisor_cpuid_base(function) \
+	for (function = 0x40000000; function < 0x40010000; function += 0x100)
+
+static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
+{
+	uint32_t base, eax, signature[3];
+
+	for_each_possible_hypervisor_cpuid_base(base) {
+		cpuid(base, &eax, &signature[0], &signature[1], &signature[2]);
+
+		/*
+		 * This must not compile to "call memcmp" because it's called
+		 * from PVH early boot code before instrumentation is set up
+		 * and memcmp() itself may be instrumented.
+		 */
+		if (!__builtin_memcmp(sig, signature, 12) &&
+		    (leaves == 0 || ((eax - base) >= leaves)))
+			return base;
+	}
+
+	return 0;
+}
+
+#endif /* _ASM_X86_CPUID_API_H */
diff --git a/arch/x86/include/asm/cpuid/types.h b/arch/x86/include/asm/cpuid/types.h
new file mode 100644
index 000000000000..724002aaff4d
--- /dev/null
+++ b/arch/x86/include/asm/cpuid/types.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_CPUID_TYPES_H
+#define _ASM_X86_CPUID_TYPES_H
+
+#include <linux/types.h>
+
+/*
+ * Types for raw CPUID access
+ */
+
+struct cpuid_regs {
+	u32 eax, ebx, ecx, edx;
+};
+
+enum cpuid_regs_idx {
+	CPUID_EAX = 0,
+	CPUID_EBX,
+	CPUID_ECX,
+	CPUID_EDX,
+};
+
+#define CPUID_LEAF_MWAIT	0x5
+#define CPUID_LEAF_DCA		0x9
+#define CPUID_LEAF_XSTATE	0x0d
+#define CPUID_LEAF_TSC		0x15
+#define CPUID_LEAF_FREQ		0x16
+#define CPUID_LEAF_TILE		0x1d
+
+#endif /* _ASM_X86_CPUID_TYPES_H */
-- 
2.45.2

[PATCH 2/5] x86/cpuid: Clean up <asm/cpuid/types.h>

[mingo]

From: Ingo Molnar <mingo@kernel.org>

 - We have 0x0d, 0x9 and 0x1d as literals for the CPUID_LEAF definitions,
   pick a single, consistent style of 0xZZ literals.

 - Likewise, harmonize the style of the 'struct cpuid_regs' list of
   registers with that of 'enum cpuid_regs_idx'. Because while computers
   don't care about unnecessary visual noise, humans do.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ahmed S. Darwish <darwi@linutronix.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250317164745.4754-3-darwi@linutronix.de
---
 arch/x86/include/asm/cpuid/types.h | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/cpuid/types.h b/arch/x86/include/asm/cpuid/types.h
index 724002aaff4d..8582e27e836d 100644
--- a/arch/x86/include/asm/cpuid/types.h
+++ b/arch/x86/include/asm/cpuid/types.h
@@ -5,11 +5,14 @@
 #include <linux/types.h>
 
 /*
- * Types for raw CPUID access
+ * Types for raw CPUID access:
  */
 
 struct cpuid_regs {
-	u32 eax, ebx, ecx, edx;
+	u32 eax;
+	u32 ebx;
+	u32 ecx;
+	u32 edx;
 };
 
 enum cpuid_regs_idx {
@@ -19,8 +22,8 @@ enum cpuid_regs_idx {
 	CPUID_EDX,
 };
 
-#define CPUID_LEAF_MWAIT	0x5
-#define CPUID_LEAF_DCA		0x9
+#define CPUID_LEAF_MWAIT	0x05
+#define CPUID_LEAF_DCA		0x09
 #define CPUID_LEAF_XSTATE	0x0d
 #define CPUID_LEAF_TSC		0x15
 #define CPUID_LEAF_FREQ		0x16
-- 
2.45.2

[PATCH 3/5] x86/cpuid: Clean up <asm/cpuid/api.h>

[mingo]

From: Ingo Molnar <mingo@kernel.org>

 - Include <asm/cpuid/types.h> first, as is customary. This also has
   the side effect of build-testing the header dependency assumptions
   in the types header.

 - No newline necessary after the SPDX line

 - Newline necessary after inline function definitions

 - Rename native_cpuid_reg() to NATIVE_CPUID_REG(): it's a CPP macro,
   whose name we capitalize in such cases.

 - Prettify the CONFIG_PARAVIRT_XXL inclusion block a bit

 - Standardize register references in comments to EAX/EBX/ECX/etc.,
   from the hodgepodge of references.

 - s/cpus/CPUs because why add noise to common acronyms?

 - Use u32 instead of uint32_t in hypervisor_cpuid_base(). Yes, I realize
   uint32_t is used in Xen code, but this is a core x86 architecture header
   and we should standardize on the type that is being used overwhelmingly
   in x86 architecture code. The two types are the same so there should be
   no build warnings.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ahmed S. Darwish <darwi@linutronix.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250317164745.4754-3-darwi@linutronix.de
---
 arch/x86/include/asm/cpuid/api.h | 30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
index 4d1da9cc8b6f..f26926ba5289 100644
--- a/arch/x86/include/asm/cpuid/api.h
+++ b/arch/x86/include/asm/cpuid/api.h
@@ -1,16 +1,16 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-
 #ifndef _ASM_X86_CPUID_API_H
 #define _ASM_X86_CPUID_API_H
 
+#include <asm/cpuid/types.h>
+
 #include <linux/build_bug.h>
 #include <linux/types.h>
 
-#include <asm/cpuid/types.h>
 #include <asm/string.h>
 
 /*
- * Raw CPUID accessors
+ * Raw CPUID accessors:
  */
 
 #ifdef CONFIG_X86_32
@@ -21,6 +21,7 @@ static inline bool have_cpuid_p(void)
 	return true;
 }
 #endif
+
 static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
 				unsigned int *ecx, unsigned int *edx)
 {
@@ -34,7 +35,7 @@ static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
 	    : "memory");
 }
 
-#define native_cpuid_reg(reg)					\
+#define NATIVE_CPUID_REG(reg)					\
 static inline unsigned int native_cpuid_##reg(unsigned int op)	\
 {								\
 	unsigned int eax = op, ebx, ecx = 0, edx;		\
@@ -45,22 +46,23 @@ static inline unsigned int native_cpuid_##reg(unsigned int op)	\
 }
 
 /*
- * Native CPUID functions returning a single datum.
+ * Native CPUID functions returning a single datum:
  */
-native_cpuid_reg(eax)
-native_cpuid_reg(ebx)
-native_cpuid_reg(ecx)
-native_cpuid_reg(edx)
+NATIVE_CPUID_REG(eax)
+NATIVE_CPUID_REG(ebx)
+NATIVE_CPUID_REG(ecx)
+NATIVE_CPUID_REG(edx)
 
 #ifdef CONFIG_PARAVIRT_XXL
-#include <asm/paravirt.h>
+# include <asm/paravirt.h>
 #else
-#define __cpuid			native_cpuid
+# define __cpuid native_cpuid
 #endif
 
 /*
  * Generic CPUID function
- * clear %ecx since some cpus (Cyrix MII) do not set or clear %ecx
+ *
+ * Clear ECX since some CPUs (Cyrix MII) do not set or clear ECX
  * resulting in stale register contents being returned.
  */
 static inline void cpuid(unsigned int op,
@@ -72,7 +74,7 @@ static inline void cpuid(unsigned int op,
 	__cpuid(eax, ebx, ecx, edx);
 }
 
-/* Some CPUID calls want 'count' to be placed in ecx */
+/* Some CPUID calls want 'count' to be placed in ECX */
 static inline void cpuid_count(unsigned int op, int count,
 			       unsigned int *eax, unsigned int *ebx,
 			       unsigned int *ecx, unsigned int *edx)
@@ -83,7 +85,7 @@ static inline void cpuid_count(unsigned int op, int count,
 }
 
 /*
- * CPUID functions returning a single datum
+ * CPUID functions returning a single datum:
  */
 
 static inline unsigned int cpuid_eax(unsigned int op)
-- 
2.45.2

[PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>

[mingo]

From: Ingo Molnar <mingo@kernel.org>

Convert all uses of 'unsigned int' to 'u32' in <asm/cpuid/api.h>.

This is how a lot of the call sites are doing it, and the two
types are equivalent in the C sense - but 'u32' better expresses
that these are expressions of an immutable hardware ABI.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ahmed S. Darwish <darwi@linutronix.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250317164745.4754-3-darwi@linutronix.de
---
 arch/x86/include/asm/cpuid/api.h | 40 ++++++++++++++++++++--------------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
index f26926ba5289..356db1894588 100644
--- a/arch/x86/include/asm/cpuid/api.h
+++ b/arch/x86/include/asm/cpuid/api.h
@@ -22,8 +22,8 @@ static inline bool have_cpuid_p(void)
 }
 #endif
 
-static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
-				unsigned int *ecx, unsigned int *edx)
+static inline void native_cpuid(u32 *eax, u32 *ebx,
+				u32 *ecx, u32 *edx)
 {
 	/* ecx is often an input as well as an output. */
 	asm volatile("cpuid"
@@ -36,9 +36,9 @@ static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
 }
 
 #define NATIVE_CPUID_REG(reg)					\
-static inline unsigned int native_cpuid_##reg(unsigned int op)	\
+static inline u32 native_cpuid_##reg(u32 op)	\
 {								\
-	unsigned int eax = op, ebx, ecx = 0, edx;		\
+	u32 eax = op, ebx, ecx = 0, edx;		\
 								\
 	native_cpuid(&eax, &ebx, &ecx, &edx);			\
 								\
@@ -65,9 +65,9 @@ NATIVE_CPUID_REG(edx)
  * Clear ECX since some CPUs (Cyrix MII) do not set or clear ECX
  * resulting in stale register contents being returned.
  */
-static inline void cpuid(unsigned int op,
-			 unsigned int *eax, unsigned int *ebx,
-			 unsigned int *ecx, unsigned int *edx)
+static inline void cpuid(u32 op,
+			 u32 *eax, u32 *ebx,
+			 u32 *ecx, u32 *edx)
 {
 	*eax = op;
 	*ecx = 0;
@@ -75,9 +75,9 @@ static inline void cpuid(unsigned int op,
 }
 
 /* Some CPUID calls want 'count' to be placed in ECX */
-static inline void cpuid_count(unsigned int op, int count,
-			       unsigned int *eax, unsigned int *ebx,
-			       unsigned int *ecx, unsigned int *edx)
+static inline void cpuid_count(u32 op, int count,
+			       u32 *eax, u32 *ebx,
+			       u32 *ecx, u32 *edx)
 {
 	*eax = op;
 	*ecx = count;
@@ -88,43 +88,43 @@ static inline void cpuid_count(unsigned int op, int count,
  * CPUID functions returning a single datum:
  */
 
-static inline unsigned int cpuid_eax(unsigned int op)
+static inline u32 cpuid_eax(u32 op)
 {
-	unsigned int eax, ebx, ecx, edx;
+	u32 eax, ebx, ecx, edx;
 
 	cpuid(op, &eax, &ebx, &ecx, &edx);
 
 	return eax;
 }
 
-static inline unsigned int cpuid_ebx(unsigned int op)
+static inline u32 cpuid_ebx(u32 op)
 {
-	unsigned int eax, ebx, ecx, edx;
+	u32 eax, ebx, ecx, edx;
 
 	cpuid(op, &eax, &ebx, &ecx, &edx);
 
 	return ebx;
 }
 
-static inline unsigned int cpuid_ecx(unsigned int op)
+static inline u32 cpuid_ecx(u32 op)
 {
-	unsigned int eax, ebx, ecx, edx;
+	u32 eax, ebx, ecx, edx;
 
 	cpuid(op, &eax, &ebx, &ecx, &edx);
 
 	return ecx;
 }
 
-static inline unsigned int cpuid_edx(unsigned int op)
+static inline u32 cpuid_edx(u32 op)
 {
-	unsigned int eax, ebx, ecx, edx;
+	u32 eax, ebx, ecx, edx;
 
 	cpuid(op, &eax, &ebx, &ecx, &edx);
 
 	return edx;
 }
 
-static inline void __cpuid_read(unsigned int leaf, unsigned int subleaf, u32 *regs)
+static inline void __cpuid_read(u32 leaf, u32 subleaf, u32 *regs)
 {
 	regs[CPUID_EAX] = leaf;
 	regs[CPUID_ECX] = subleaf;
@@ -141,7 +141,7 @@ static inline void __cpuid_read(unsigned int leaf, unsigned int subleaf, u32 *re
 	__cpuid_read(leaf, 0, (u32 *)(regs));		\
 }
 
-static inline void __cpuid_read_reg(unsigned int leaf, unsigned int subleaf,
+static inline void __cpuid_read_reg(u32 leaf, u32 subleaf,
 				    enum cpuid_regs_idx regidx, u32 *reg)
 {
 	u32 regs[4];
-- 
2.45.2

[PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[mingo]

From: Ingo Molnar <mingo@kernel.org>

Use u32 instead of uint32_t in hypervisor_cpuid_base().

Yes, I realize uint32_t is used in Xen code et al, but this is
a core x86 architecture header and we should standardize on the
type that is being used overwhelmingly in related x86 architecture
code.

The two types are the same so there should be no build warnings.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Ahmed S. Darwish <darwi@linutronix.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250317164745.4754-3-darwi@linutronix.de
---
 arch/x86/include/asm/cpuid/api.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
index 356db1894588..9c180c9cc58e 100644
--- a/arch/x86/include/asm/cpuid/api.h
+++ b/arch/x86/include/asm/cpuid/api.h
@@ -187,9 +187,9 @@ static __always_inline bool cpuid_function_is_indexed(u32 function)
 #define for_each_possible_hypervisor_cpuid_base(function) \
 	for (function = 0x40000000; function < 0x40010000; function += 0x100)
 
-static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
+static inline u32 hypervisor_cpuid_base(const char *sig, u32 leaves)
 {
-	uint32_t base, eax, signature[3];
+	u32 base, eax, signature[3];
 
 	for_each_possible_hypervisor_cpuid_base(base) {
 		cpuid(base, &eax, &signature[0], &signature[1], &signature[2]);
-- 
2.45.2

Re: [PATCH 0/5] x86/cpu: Introduce <asm/cpuid/types.h> and <asm/cpuid/api.h> and clean them up

[Linus Torvalds]

On Mon, 17 Mar 2025 at 15:30, <mingo@kernel.org> wrote:
>
> [ This is a resend with a proper SMTP setup. Apologies for the duplication. ]

Yes, now it looks correct from a DKIM standpoint.

But please still fix your name. Now your "From" line is just this:

    From: mingo@kernel.org

rather than your previous series, that had a much more legible

    From: Ingo Molnar <mingo@kernel.org>

in it.

No need to re-send, but for next time...

              Linus

Re: [PATCH 0/5] x86/cpu: Introduce <asm/cpuid/types.h> and <asm/cpuid/api.h> and clean them up

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, 17 Mar 2025 at 15:30, <mingo@kernel.org> wrote:
> >
> > [ This is a resend with a proper SMTP setup. Apologies for the duplication. ]
> 
> Yes, now it looks correct from a DKIM standpoint.
> 
> But please still fix your name. Now your "From" line is just this:
> 
>     From: mingo@kernel.org
> 
> rather than your previous series, that had a much more legible
> 
>     From: Ingo Molnar <mingo@kernel.org>
> 
> in it.
> 
> No need to re-send, but for next time...

Oh, that's probably the result of me copy-pasting the documentation:

    # https://korg.docs.kernel.org/mail.html

    [sendemail]
            smtpserver     = mail.kernel.org
            smtpserverport = 465
            smtpencryption = ssl
            from           = [username]@kernel.org
            smtpuser       = [username]

Which I did as:

            from           = mingo@kernel.org

... while it should probably be:

            from           = Ingo Molnar <mingo@kernel.org>

I just did a test-send to myself, and this appears to have done the 
trick.

So maybe the mail.html documentation should be updated to say:

            from           = "Your Real Name" <[username]@kernel.org>

or so?

Thanks,

	Ingo

Re: [PATCH 0/5] x86/cpu: Introduce <asm/cpuid/types.h> and <asm/cpuid/api.h> and clean them up

[Ahmed S. Darwish]

Hi,

On Mon, 17 Mar 2025, mingo@kernel.org wrote:
>
> From: Ingo Molnar <mingo@kernel.org>
>
> This series contains Ahmed S. Darwish's splitting up of <asm/cpuid.h>
> into <asm/cpuid/types.h> and <asm/cpuid/api.h>, followed by a couple
> of cleanups that create a more maintainable base.
>
> [ This is a resend with a proper SMTP setup. Apologies for the duplication. ]
>

Thanks a lot!

Just a small hint that I see this PQ in tip/master, merge commit
b8fefef00c0d ("Merge branch into tip/master: 'x86/cpu'"):

   # New commits in x86/cpu:
      ba501f14e1e6 ("x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>")
      aec28d852ed2 ("x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>")
      f2f828b547ab ("x86/cpuid: Clean up <asm/cpuid/api.h>")
      67a7ae050e7c ("x86/cpuid: Clean up <asm/cpuid/types.h>")
      02b63b33dfc9 ("x86/cpuid: Refactor <asm/cpuid.h>")

But for some reason the above 5 commits are not yet pushed to x86/cpu.

(Sorry if this is expected.)

All the best,

--
Ahmed S. Darwish
Linutronix GmbH

Re: [PATCH 0/5] x86/cpu: Introduce <asm/cpuid/types.h> and <asm/cpuid/api.h> and clean them up

[Ingo Molnar]

* Ahmed S. Darwish <darwi@linutronix.de> wrote:

> Hi,
> 
> On Mon, 17 Mar 2025, mingo@kernel.org wrote:
> >
> > From: Ingo Molnar <mingo@kernel.org>
> >
> > This series contains Ahmed S. Darwish's splitting up of <asm/cpuid.h>
> > into <asm/cpuid/types.h> and <asm/cpuid/api.h>, followed by a couple
> > of cleanups that create a more maintainable base.
> >
> > [ This is a resend with a proper SMTP setup. Apologies for the duplication. ]
> >
> 
> Thanks a lot!
> 
> Just a small hint that I see this PQ in tip/master, merge commit
> b8fefef00c0d ("Merge branch into tip/master: 'x86/cpu'"):
> 
>    # New commits in x86/cpu:
>       ba501f14e1e6 ("x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>")
>       aec28d852ed2 ("x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>")
>       f2f828b547ab ("x86/cpuid: Clean up <asm/cpuid/api.h>")
>       67a7ae050e7c ("x86/cpuid: Clean up <asm/cpuid/types.h>")
>       02b63b33dfc9 ("x86/cpuid: Refactor <asm/cpuid.h>")
> 
> But for some reason the above 5 commits are not yet pushed to x86/cpu.

Yeah, that was a temporary status until a bit more testing could be 
done - I've pushed it out now.

Thanks,

	Ingo

Re: [PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>

[H. Peter Anvin]

On March 17, 2025 3:30:38 PM PDT, mingo@kernel.org wrote:
>From: Ingo Molnar <mingo@kernel.org>
>
>Convert all uses of 'unsigned int' to 'u32' in <asm/cpuid/api.h>.
>
>This is how a lot of the call sites are doing it, and the two
>types are equivalent in the C sense - but 'u32' better expresses
>that these are expressions of an immutable hardware ABI.
>
>Signed-off-by: Ingo Molnar <mingo@kernel.org>
>Cc: Ahmed S. Darwish <darwi@linutronix.de>
>Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>Cc: "H. Peter Anvin" <hpa@zytor.com>
>Cc: John Ogness <john.ogness@linutronix.de>
>Cc: x86-cpuid@lists.linux.dev
>Link: https://lore.kernel.org/r/20250317164745.4754-3-darwi@linutronix.de
>---
> arch/x86/include/asm/cpuid/api.h | 40 ++++++++++++++++++++--------------------
> 1 file changed, 20 insertions(+), 20 deletions(-)
>
>diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
>index f26926ba5289..356db1894588 100644
>--- a/arch/x86/include/asm/cpuid/api.h
>+++ b/arch/x86/include/asm/cpuid/api.h
>@@ -22,8 +22,8 @@ static inline bool have_cpuid_p(void)
> }
> #endif
> 
>-static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
>-				unsigned int *ecx, unsigned int *edx)
>+static inline void native_cpuid(u32 *eax, u32 *ebx,
>+				u32 *ecx, u32 *edx)
> {
> 	/* ecx is often an input as well as an output. */
> 	asm volatile("cpuid"
>@@ -36,9 +36,9 @@ static inline void native_cpuid(unsigned int *eax, unsigned int *ebx,
> }
> 
> #define NATIVE_CPUID_REG(reg)					\
>-static inline unsigned int native_cpuid_##reg(unsigned int op)	\
>+static inline u32 native_cpuid_##reg(u32 op)	\
> {								\
>-	unsigned int eax = op, ebx, ecx = 0, edx;		\
>+	u32 eax = op, ebx, ecx = 0, edx;		\
> 								\
> 	native_cpuid(&eax, &ebx, &ecx, &edx);			\
> 								\
>@@ -65,9 +65,9 @@ NATIVE_CPUID_REG(edx)
>  * Clear ECX since some CPUs (Cyrix MII) do not set or clear ECX
>  * resulting in stale register contents being returned.
>  */
>-static inline void cpuid(unsigned int op,
>-			 unsigned int *eax, unsigned int *ebx,
>-			 unsigned int *ecx, unsigned int *edx)
>+static inline void cpuid(u32 op,
>+			 u32 *eax, u32 *ebx,
>+			 u32 *ecx, u32 *edx)
> {
> 	*eax = op;
> 	*ecx = 0;
>@@ -75,9 +75,9 @@ static inline void cpuid(unsigned int op,
> }
> 
> /* Some CPUID calls want 'count' to be placed in ECX */
>-static inline void cpuid_count(unsigned int op, int count,
>-			       unsigned int *eax, unsigned int *ebx,
>-			       unsigned int *ecx, unsigned int *edx)
>+static inline void cpuid_count(u32 op, int count,
>+			       u32 *eax, u32 *ebx,
>+			       u32 *ecx, u32 *edx)
> {
> 	*eax = op;
> 	*ecx = count;
>@@ -88,43 +88,43 @@ static inline void cpuid_count(unsigned int op, int count,
>  * CPUID functions returning a single datum:
>  */
> 
>-static inline unsigned int cpuid_eax(unsigned int op)
>+static inline u32 cpuid_eax(u32 op)
> {
>-	unsigned int eax, ebx, ecx, edx;
>+	u32 eax, ebx, ecx, edx;
> 
> 	cpuid(op, &eax, &ebx, &ecx, &edx);
> 
> 	return eax;
> }
> 
>-static inline unsigned int cpuid_ebx(unsigned int op)
>+static inline u32 cpuid_ebx(u32 op)
> {
>-	unsigned int eax, ebx, ecx, edx;
>+	u32 eax, ebx, ecx, edx;
> 
> 	cpuid(op, &eax, &ebx, &ecx, &edx);
> 
> 	return ebx;
> }
> 
>-static inline unsigned int cpuid_ecx(unsigned int op)
>+static inline u32 cpuid_ecx(u32 op)
> {
>-	unsigned int eax, ebx, ecx, edx;
>+	u32 eax, ebx, ecx, edx;
> 
> 	cpuid(op, &eax, &ebx, &ecx, &edx);
> 
> 	return ecx;
> }
> 
>-static inline unsigned int cpuid_edx(unsigned int op)
>+static inline u32 cpuid_edx(u32 op)
> {
>-	unsigned int eax, ebx, ecx, edx;
>+	u32 eax, ebx, ecx, edx;
> 
> 	cpuid(op, &eax, &ebx, &ecx, &edx);
> 
> 	return edx;
> }
> 
>-static inline void __cpuid_read(unsigned int leaf, unsigned int subleaf, u32 *regs)
>+static inline void __cpuid_read(u32 leaf, u32 subleaf, u32 *regs)
> {
> 	regs[CPUID_EAX] = leaf;
> 	regs[CPUID_ECX] = subleaf;
>@@ -141,7 +141,7 @@ static inline void __cpuid_read(unsigned int leaf, unsigned int subleaf, u32 *re
> 	__cpuid_read(leaf, 0, (u32 *)(regs));		\
> }
> 
>-static inline void __cpuid_read_reg(unsigned int leaf, unsigned int subleaf,
>+static inline void __cpuid_read_reg(u32 leaf, u32 subleaf,
> 				    enum cpuid_regs_idx regidx, u32 *reg)
> {
> 	u32 regs[4];

So in addition to avoid the in/out pointer hack, I would like to point out that cpuid() is now *exactly* the same as cpuid_count with a count of 0 (which is probably a good idea anyway.)

One more thing is that we ought to be able to make cpuid a const function, allowing the compiler to elide multiple calls. (Slight warning for feature-enabling MSRs changing CPUID), but that would require changing the API to returning a structure, since a pure or const structure can't return values by reference.

Re: [PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>

[H. Peter Anvin]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On 3/18/25 11:48, H. Peter Anvin wrote:
> 
> One more thing is that we ought to be able to make cpuid a const
> function, allowing the compiler to elide multiple calls. (Slight warning
> for feature-enabling MSRs changing CPUID), but that would require
> changing the API to returning a structure, since a pure or const
> structure can't return values by reference.
> 

So I experimented (test included) and found that gcc 14.2 does not seem 
to merge the cpuid calls in this code, whereas clang 19.1 does.

  	-hpa

[-- Attachment #2: cpuid.c --]
[-- Type: text/x-csrc, Size: 1262 bytes --]

#include <inttypes.h>
#include <stdio.h>

typedef uint32_t u32;

struct cpuid {
	u32 ebx;
	u32 edx;
	u32 ecx;
	u32 eax;
};

static inline __attribute__((const)) struct cpuid
cpuid(u32 leaf, u32 subleaf)
{
	struct cpuid rv;
	asm("cpuid"
	    : "=a" (rv.eax), "=c" (rv.ecx), "=d" (rv.edx), "=b" (rv.ebx)
	    : "a" (leaf), "c" (subleaf));
	return rv;
}

static inline __attribute__((const)) u32
cpuid_eax(u32 leaf, u32 subleaf)
{
	struct cpuid rv = cpuid(leaf, subleaf);
	return rv.eax;
}
static inline __attribute__((const)) u32
cpuid_ecx(u32 leaf, u32 subleaf)
{
	struct cpuid rv = cpuid(leaf, subleaf);
	return rv.ecx;
}
static inline __attribute__((const)) u32
cpuid_edx(u32 leaf, u32 subleaf)
{
	struct cpuid rv = cpuid(leaf, subleaf);
	return rv.edx;
}
static inline __attribute__((const)) u32
cpuid_ebx(u32 leaf, u32 subleaf)
{
	struct cpuid rv = cpuid(leaf, subleaf);
	return rv.ebx;
}

u32 eax(u32 leaf, u32 subleaf)
{
	return cpuid_eax(leaf, subleaf);
}

struct cpuid _cpuid(u32 leaf, u32 subleaf)
{
	return cpuid(leaf, subleaf);
}

int test_cpuid(void)
{
	int found = 0;

	found += !!(cpuid_edx(1, 0) & (1 << 26)); /* SSE2 */
	found += !!(cpuid_ecx(1, 0) & (1 << 0));  /* SSE3 */
	found += !!(cpuid(1, 0).ecx & (1 << 9));  /* SSSE3 */

	return found;
}

Re: [PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>

[Andrew Cooper]

On 18/03/2025 6:48 pm, H. Peter Anvin wrote:
> One more thing is that we ought to be able to make cpuid a const function, allowing the compiler to elide multiple calls. (Slight warning for feature-enabling MSRs changing CPUID), but that would require changing the API to returning a structure, since a pure or const structure can't return values by reference.

It's not only the feature-enabling MSRs.  It's also OSXSAVE/OSPKE/etc in
CR4, and on Intel CPUs, the CPUID instruction still has a side effect
for microcode patch revision MSR.

There are a few too many side effects to call it const/pure.

That said, when experimenting with the same in Xen, there was nothing
interesting the compiler could do with const/pure because of how the
existing logic is laid out.  Removing volatile and the memory clobber
however did allow the compiler to make slightly better code.

~Andrew

Re: [PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>

[H. Peter Anvin]

On March 18, 2025 12:09:59 PM PDT, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>On 18/03/2025 6:48 pm, H. Peter Anvin wrote:
>> One more thing is that we ought to be able to make cpuid a const function, allowing the compiler to elide multiple calls. (Slight warning for feature-enabling MSRs changing CPUID), but that would require changing the API to returning a structure, since a pure or const structure can't return values by reference.
>
>It's not only the feature-enabling MSRs.  It's also OSXSAVE/OSPKE/etc in
>CR4, and on Intel CPUs, the CPUID instruction still has a side effect
>for microcode patch revision MSR.
>
>There are a few too many side effects to call it const/pure.
>
>That said, when experimenting with the same in Xen, there was nothing
>interesting the compiler could do with const/pure because of how the
>existing logic is laid out.  Removing volatile and the memory clobber
>however did allow the compiler to make slightly better code.
>
>~Andrew

Well, I guess I lump CRs, DRs and MSRs together. There is also CPUID for serialization, which is really a totally different use for the same instruction. 

tglx has suggested that we should cache or even preload the cpuid data (the latter would have the potential advantage of making the memory data structures a little easier to manage, given the very large potential space.)

The biggest issue is that there is no general mechanism for detecting which cpuid leaves have subleaves, and if they do, how many. I *believe* all existing subleaf sets are dense, but one could at least hypothetically see a vendor or VM define a CPUID leaf with a sparse subleaf set.

Re: [PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>

[Andrew Cooper]

On 18/03/2025 7:25 pm, H. Peter Anvin wrote:
> On March 18, 2025 12:09:59 PM PDT, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 18/03/2025 6:48 pm, H. Peter Anvin wrote:
>>> One more thing is that we ought to be able to make cpuid a const function, allowing the compiler to elide multiple calls. (Slight warning for feature-enabling MSRs changing CPUID), but that would require changing the API to returning a structure, since a pure or const structure can't return values by reference.
>> It's not only the feature-enabling MSRs.  It's also OSXSAVE/OSPKE/etc in
>> CR4, and on Intel CPUs, the CPUID instruction still has a side effect
>> for microcode patch revision MSR.
>>
>> There are a few too many side effects to call it const/pure.
>>
>> That said, when experimenting with the same in Xen, there was nothing
>> interesting the compiler could do with const/pure because of how the
>> existing logic is laid out.  Removing volatile and the memory clobber
>> however did allow the compiler to make slightly better code.
>>
>> ~Andrew
> Well, I guess I lump CRs, DRs and MSRs together. There is also CPUID for serialization, which is really a totally different use for the same instruction.

Andy Luto got rid of all CPUID serialisation ages back.  It's about the
worst of the available options, even on native.  It's IRET-to-self
(doesn't exit under any virt), or SERIALISE on bleeding edge CPUs.

> tglx has suggested that we should cache or even preload the cpuid data (the latter would have the potential advantage of making the memory data structures a little easier to manage, given the very large potential space.)
>
> The biggest issue is that there is no general mechanism for detecting which cpuid leaves have subleaves, and if they do, how many. I *believe* all existing subleaf sets are dense, but one could at least hypothetically see a vendor or VM define a CPUID leaf with a sparse subleaf set.

XSTATE is sparse in general; AVX-512 being the notable absence on
Intel's client line, and AMD has LWP at subleaf 62.

But yes, these are all problems trying to maintain an in-memory copy of
the CPUID state.  Maintenance of this in Xen leaves a lot to be desired.

~Andrew

Re: [PATCH 4/5] x86/cpuid: Standardize on u32 in <asm/cpuid/api.h>

[Ahmed S. Darwish]

On Tue, 18 Mar 2025, H. Peter Anvin wrote:
>
> tglx has suggested that we should cache or even preload the cpuid data
> (the latter would have the potential advantage of making the memory
> data structures a little easier to manage, given the very large
>  potential space.)
>

This is indeed in the patch queue that I plan to send after this leaf
cleanups one gets merged.  We have a data model and CPUIDs are cached on
early boot.  The cache is also refreshed during machine state changes
where the CPUIDs can change; e.g. a microcode update, PSN disable, etc.

Call sites then just do:

    a = cpudata_cpuid(c, 0x0)->max_std_leaf;
    b = cpudata_cpuid(c, 0x80000000)->max_ext_leaf;

    struct leaf_0x1_0 *l1 = cpudata_cpuid(c, 0x1);
    x = l0->cpu_vendorid_0;
    y = l0->cpu_vendorid_1;
    z = l0->cpu_vendorid_2;

and all the data is retrieved auto-magically from the cached tables.

The struct leaf_0xM_N C99 bitfield listings are auto generated by
x86-cpuid-db of course, just like in tools/arch/x86/kcpuid/cpuid.csv.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

Re: [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[Ingo Molnar]

* Thomas Gleixner <tglx@linutronix.de> wrote:

> On Tue, Mar 18 2025 at 19:20, Ingo Molnar wrote:
> > * Borislav Petkov <bp@alien8.de> wrote:
> >> On Tue, Mar 18, 2025 at 12:53:05PM +0100, Ingo Molnar wrote:
> >> > How is one more word and saying the same thing in a more circumspect 
> >> > fashion a liguistic improvement?
> >> 
> >> Because it removes the "we" out of the equation. I don't have to 
> >> wonder who's the "we" the author is talking about: his employer, his 
> >> private interests in Linux or "we" is actually "us" - the community 
> >> as a whole.
> >
> > In practice this is almost never ambiguous - and when it is, it can be 
> > fixed up.
> >
> >> I can't give a more honking example about the ambiguity here.
> >
> > It's a red herring fallacy really. Let's go over the first example 
> > given in Documentation/process/maintainer-tip.rst:
> >
> >     x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu
> >
> >     When a CPU is dying, we cancel the worker and schedule a new worker on a
> >     different CPU on the same domain. But if the timer is already about to
> >     expire (say 0.99s) then we essentially double the interval.
> >
> > You'd have to be a bumbling idiot to think that the 'we' means an 
> > employer or the person themselves ...
> >
> > Put differently: *the very first example given* uses 'we' functionally 
> > unambiguously so that everyone who can read kernel changelogs will 
> > understand what it says. Ie. the whole policy is based on a false 
> > statement...
> 
> That's complete and utter nonsense.

I love you too! :-)

> 'we cancel the worker, we call kmalloc()' are purely colloquial 
> expressions.

So what? I have no problem with colloquial, familiar, everyday language 
in a technical context as long as it's effective and unambiguous.

The main linguistic advantage of German engineering is the ability to 
construct new, unambiguous words out of thin air:

   "Donaudampfschifffahrtselektrizitätenhauptbetriebswerkbauunternehmenbeamtengesellschaft"

... not the cold, impersonal tone. And I say that as a German, and yes, 
the 87-letter word above is a real, valid German word. :-)

> Liguistically they are factually wrong abominations.
> 
> We can cancel a subscription, an appointment, a booking... We can 
> call a taxi, a ambulance, a doctor, ....
> 
> But as a matter of fact, we _cannot_ cancel a worker or call 
> kmalloc().

Nor can we read a source buffer, nor can we do multiple writes to a 
destination buffer, right?

Tell that to Linus, who arguably writes one of the best changelogs in 
the kernel:

  # 9022ed0e7e65 ("strscpy: write destination buffer only once")

    In particular, the same way we shouldn't read the source buffer more
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    than once, we should avoid doing multiple writes to the destination
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    buffer: first writing a potentially non-terminated string, and then
    ^^^^^^^
    terminating it with NUL at the end does not result in a stable result
    buffer.

And I think the moment you have to argue against the quality of Linus's 
changelogs you've lost the argument really, almost by default.

> Changelogs as any other serious writing in technical context are about
> precision and clarity.

Absolutely, and 'we' in this context unambiguously means the kernel, so 
it's as clear to me as it gets.

I (obviously) agree with most of the stylistic and linguistic 
suggestions in Documentation/process/maintainer-tip.rst, and maybe my 
reaction was a bit hyperbolic (sorry), I just pointed out that this 
silly avoidance of pronouns like 'we' - which started the discussion - 
which results in *sentences with more words*, is *obviously* 
counterproductive.

Longer sentences with the same information content == worse.

To visualize it:

  When a CPU is dying, the worker is canceled and a new worker is scheduled on a different CPU in the same domain.
  When a CPU is dying, we cancel the worker and schedule a new worker on a different CPU in the same domain.

In communication shorter is better, if the information content is 
otherwise equivalent.

Anyway, let's agree to disagree. :-)

Thanks,

	Ingo

Re: [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[Thomas Gleixner]

On Tue, Mar 18 2025 at 19:20, Ingo Molnar wrote:
> * Borislav Petkov <bp@alien8.de> wrote:
>> On Tue, Mar 18, 2025 at 12:53:05PM +0100, Ingo Molnar wrote:
>> > How is one more word and saying the same thing in a more circumspect 
>> > fashion a liguistic improvement?
>> 
>> Because it removes the "we" out of the equation. I don't have to 
>> wonder who's the "we" the author is talking about: his employer, his 
>> private interests in Linux or "we" is actually "us" - the community 
>> as a whole.
>
> In practice this is almost never ambiguous - and when it is, it can be 
> fixed up.
>
>> I can't give a more honking example about the ambiguity here.
>
> It's a red herring fallacy really. Let's go over the first example 
> given in Documentation/process/maintainer-tip.rst:
>
>     x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu
>
>     When a CPU is dying, we cancel the worker and schedule a new worker on a
>     different CPU on the same domain. But if the timer is already about to
>     expire (say 0.99s) then we essentially double the interval.
>
> You'd have to be a bumbling idiot to think that the 'we' means an 
> employer or the person themselves ...
>
> Put differently: *the very first example given* uses 'we' functionally 
> unambiguously so that everyone who can read kernel changelogs will 
> understand what it says. Ie. the whole policy is based on a false 
> statement...

That's complete and utter nonsense.

'we cancel the worker, we call kmalloc()' are purely colloquial
expressions. Liguistically they are factually wrong abominations.

We can cancel a subscription, an appointment, a booking...
We can call a taxi, a ambulance, a doctor, ....

But as a matter of fact, we _cannot_ cancel a worker or call kmalloc().

Changelogs as any other serious writing in technical context are about
precision and clarity.

The impersonating form is obviously popular and in some contexts, like
tutorials and beginner guides, it makes them seemingly more accessible,
but that does not provide an justification for using it in the context
of change logs.

Change logs are an important documentation of the underlying code
change, because they provide context and technical justification for the
change and therefore have to prioritize precision and clarity.

Aside of that ,writing a change log in neutral and technically precise
language forces you to actually rethink the problem and the approach to
solve it. Dumping your half baked thoughts in impersonating novel style
does not.

From 20+ years of experience on the receiving end of the patch fire
hose, I can clearly proof a very high correlation between the quality of
change logs and the quality of the analysis and the resulting code
change.

Yes, it is work to write a proper and precise change log, but that extra
effort makes the work of people, who review patches, easier and it's
also highly benefitial, when analyising historical changes.

Thanks,

        tglx

Re: [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[Ingo Molnar]

* Borislav Petkov <bp@alien8.de> wrote:

> On Tue, Mar 18, 2025 at 12:53:05PM +0100, Ingo Molnar wrote:
> > How is one more word and saying the same thing in a more circumspect 
> > fashion a liguistic improvement?
> 
> Because it removes the "we" out of the equation. I don't have to 
> wonder who's the "we" the author is talking about: his employer, his 
> private interests in Linux or "we" is actually "us" - the community 
> as a whole.

In practice this is almost never ambiguous - and when it is, it can be 
fixed up.

> I can't give a more honking example about the ambiguity here.

It's a red herring fallacy really. Let's go over the first example 
given in Documentation/process/maintainer-tip.rst:

    x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu

    When a CPU is dying, we cancel the worker and schedule a new worker on a
    different CPU on the same domain. But if the timer is already about to
    expire (say 0.99s) then we essentially double the interval.

You'd have to be a bumbling idiot to think that the 'we' means an 
employer or the person themselves ...

Put differently: *the very first example given* uses 'we' functionally 
unambiguously so that everyone who can read kernel changelogs will 
understand what it says. Ie. the whole policy is based on a false 
statement...

Very few of the 'we' general pronouns used in kernel changelogs are 
actually ambiguous. This means that any crusade to eliminate 'we' from 
changelogs is not just pointless, but also a waste of resources - it's 
a net negative. At least IMHO. ;-)

> >   The second sentence, "When a CPU is dying, we cancel the worker 
> >   and schedule a new worker on a different CPU on the same domain," 
> >   is easier to understand. It uses simpler language and a more 
> >   direct structure, making it clearer for the reader.
> 
> I disagree with the LLM - it is yet another proof that AI won't 
> replace humans - if anything it'll make them *think* more. Which is 
> good! :-)

Yeah, and in any case, tastes differ, so no strong feelings from me 
either! :-)

Thanks,

	Ingo

Re: [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[Borislav Petkov]

On Tue, Mar 18, 2025 at 12:53:05PM +0100, Ingo Molnar wrote:
> How is one more word and saying the same thing in a more circumspect 
> fashion a liguistic improvement?

Because it removes the "we" out of the equation. I don't have to wonder who's
the "we" the author is talking about: his employer, his private interests in
Linux or "we" is actually "us" - the community as a whole.

I can't give a more honking example about the ambiguity here.

>   The second sentence, "When a CPU is dying, we cancel the worker and 
>   schedule a new worker on a different CPU on the same domain," is easier 
>   to understand. It uses simpler language and a more direct structure, 
>   making it clearer for the reader.

I disagree with the LLM - it is yet another proof that AI won't replace
humans - if anything it'll make them *think* more. Which is good! :-)

> Few people will understand a generic personal pronoun to apply to a 
> corporate entity magically, unless it's really clear and specific:
> 
> 	"We at Intel believe that this condition cannot occur on Intel 
> 	 hardware."
> 
> in which case it's not a generic personal pronoun anymore.

Except no one says "we at <company>" - they say "we" ambiguously. And I have
had gazillion examples of "we the company want Linux to do this and that
because our use case is bla".

> Or to give another data point: since the v6.13 merge cycle we have 

<snip the stats>

That's why I said

"Is it a hard rule? Ofc not - there are exceptions to that rule depending on
the context."

And we have said "we" for 30+ years so can't change that over night. And not
everyone agrees with that. I understand it all.

I still think that in some cases formulating a commit message in impersonal
style lets you concentrate on the *problem* at hand the commit is trying to
fix - not what we do or want. It removes the person out of the equation
because the person doesn't need to be there.

HOWEVER, it is perfectly fine to say "I did this and that and I've been
wondering for years why the code does what it does." because it adds that
additional coloring about the trials and tribulations of the author.

So no, it is not a hard rule but there is an undeniable merit in writing the
commit messages impersonal.

And that's fine - I fix up things from time to time when they bother me.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[Ingo Molnar]

* Borislav Petkov <bp@alien8.de> wrote:

> On Tue, Mar 18, 2025 at 09:34:41AM +0100, Ingo Molnar wrote:
> > That's a stupid rule, I don't know where it came from, and I never 
> > enforced it. It's not in Documentation/process/coding-style.rst.
> 
> I believe tglx came up with it - section "Changelog" in
> 
> Documentation/process/maintainer-tip.rst
> 
> Read the examples there.

Literally the first example there is kinda bogus:

  Example 1::

    ...

    When a CPU is dying, we cancel the worker and schedule a new worker 
    on a different CPU on the same domain.

  Improved version::

    ... 

    When a CPU is dying, the worker is canceled and a new worker is 
    scheduled on a different CPU in the same domain.

[ Note that I edited the first example to be a true equivalent 
  transformation to passive voice. The example in maintainer-tip.rst 
  makes other edits too which make it hard to compare. ]

How is one more word and saying the same thing in a more circumspect 
fashion a liguistic improvement?

And you don't have to believe me - I gave an LLM the following prompt:

  Which English sentence is easier to understand:
    "When a CPU is dying, the worker is canceled and a new worker is 
     scheduled on a different CPU in the same domain."
  or
    "When a CPU is dying, we cancel the worker and schedule a new worker 
     on a different CPU on the same domain."?

And it answered:

  The second sentence, "When a CPU is dying, we cancel the worker and 
  schedule a new worker on a different CPU on the same domain," is easier 
  to understand. It uses simpler language and a more direct structure, 
  making it clearer for the reader.

... and although I'd be the first one to distrust an LLM's opinion, 
it's correct in this case IMHO.

> And you and I have had this conversation already on IRC. I happen to 
> agree with him that "we" is ambiguous - with all those companies 
> submitting patches you don't know who's "we" interests are being 
> taken care of.

Few people will understand a generic personal pronoun to apply to a 
corporate entity magically, unless it's really clear and specific:

	"We at Intel believe that this condition cannot occur on Intel 
	 hardware."

in which case it's not a generic personal pronoun anymore.

Or to give another data point: since the v6.13 merge cycle we have 
merged over 11,000 commits in the upstream kernel, and over 1,500 
contain the word 'we' - over 13% of all commits. This is literally a 
pointless battle that creates unnecessary maintenance overhead and 
pointless detours for developers.

> And if you formulate your commit message in impersonal tone, it reads a lot
> clearer. It is simply a lot better this way.

Except *not even we* follow it consistently:

  starship:~/tip> gl --author=tglx --since=two-years-ago --grep='\<we\>' linus | grep -iw we
         by a context from task B and we do the check
    So it turns out that we have to do two passes of
      "The problem in current microcode loading method is that we load a
       microcode way, way too late; ideally we should load it before turning
       paging on.  This may only be practical on 32 bits since we can't get
       to 64-bit mode without paging on, but we should still do it as early
    MADT delivers we only trust the hardware anyway.
             * booting is too fragile that we want to limit the

Because it's actually a natural and direct linguistic construct.

And have a look at:

   $ gl --author=torvalds --since=two-years-ago --grep='\<we\>' linus | grep -iw we

it's 1352 examples of Linus using 'we' as a generic personal pronoun in 
the last 2 years alone...

Thanks,

	Ingo

Re: [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[Borislav Petkov]

On Tue, Mar 18, 2025 at 09:34:41AM +0100, Ingo Molnar wrote:
> That's a stupid rule, I don't know where it came from, and I never 
> enforced it. It's not in Documentation/process/coding-style.rst.

I believe tglx came up with it - section "Changelog" in

Documentation/process/maintainer-tip.rst

Read the examples there.

And you and I have had this conversation already on IRC. I happen to agree
with him that "we" is ambiguous - with all those companies submitting patches
you don't know who's "we" interests are being taken care of.

And if you formulate your commit message in impersonal tone, it reads a lot
clearer. It is simply a lot better this way.

Is it a hard rule? Ofc not - there are exceptions to that rule depending on
the context. But most if the time and IMNSVHO, impersonal formulations read
a lot better and clearer.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[Ingo Molnar]

* Xin Li <xin@zytor.com> wrote:

> On 3/17/2025 3:18 PM, Ingo Molnar wrote:
> > Use u32 instead of uint32_t in hypervisor_cpuid_base().
> > 
> > Yes, I realize uint32_t is used in Xen code et al, but this is
> > a core x86 architecture header and we should standardize on the
> 
> no "we", right?

That's a stupid rule, I don't know where it came from, and I never 
enforced it. It's not in Documentation/process/coding-style.rst.

Linus doesn't use this pointless rule of 'pronoun avoidance' in 
changelogs either:

  00a7d39898c8 ("fs/pipe: add simpler helpers for common cases")

  https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00a7d39898c8010bfd5ff62af31ca5db34421b38  

    It turns out that we don't have _that_ many places that access these
                      ^^
    fields directly and were affected, but we have more than we strictly
                                           ^^                ^^
    should have, because our low-level helper functions have been designed
    to have intimate knowledge of how the pipes work.
    
    And as a result, that random noise of direct 'pipe->head' and
    'pipe->tail' accesses makes it harder to pinpoint any actual potential
    problem spots remaining.
    
    For example, we didn't have a "is the pipe full" helper function, but
                 ^^
    instead had a "given these pipe buffer indexes and this pipe size, is
    the pipe full".  That's because some low-level pipe code does actually
    want that much more complicated interface.

In changelogs 'we' when used as a generic personal pronoun means the 
kernel and the kernel community in general. It's a perfectly fine 
grammatical construct.

Thanks,

	Ingo

Re: [PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[Xin Li]

On 3/17/2025 3:18 PM, Ingo Molnar wrote:
> Use u32 instead of uint32_t in hypervisor_cpuid_base().
> 
> Yes, I realize uint32_t is used in Xen code et al, but this is
> a core x86 architecture header and we should standardize on the

no "we", right?

> type that is being used overwhelmingly in related x86 architecture
> code.
> 
> The two types are the same so there should be no build warnings.
> 
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Stefano Stabellini <sstabellini@kernel.org>
> Cc: Ahmed S. Darwish <darwi@linutronix.de>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: John Ogness <john.ogness@linutronix.de>
> Cc: x86-cpuid@lists.linux.dev
> Link: https://lore.kernel.org/r/20250317164745.4754-3-darwi@linutronix.de
> ---
>   arch/x86/include/asm/cpuid/api.h | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
> index 356db1894588..9c180c9cc58e 100644
> --- a/arch/x86/include/asm/cpuid/api.h
> +++ b/arch/x86/include/asm/cpuid/api.h
> @@ -187,9 +187,9 @@ static __always_inline bool cpuid_function_is_indexed(u32 function)
>   #define for_each_possible_hypervisor_cpuid_base(function) \
>   	for (function = 0x40000000; function < 0x40010000; function += 0x100)
>   
> -static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
> +static inline u32 hypervisor_cpuid_base(const char *sig, u32 leaves)
>   {
> -	uint32_t base, eax, signature[3];
> +	u32 base, eax, signature[3];
>   
>   	for_each_possible_hypervisor_cpuid_base(base) {
>   		cpuid(base, &eax, &signature[0], &signature[1], &signature[2]);

[PATCH 5/5] x86/cpuid: Use u32 in instead of uint32_t in <asm/cpuid/api.h>

[Ingo Molnar]

Use u32 instead of uint32_t in hypervisor_cpuid_base().

Yes, I realize uint32_t is used in Xen code et al, but this is
a core x86 architecture header and we should standardize on the
type that is being used overwhelmingly in related x86 architecture
code.

The two types are the same so there should be no build warnings.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Ahmed S. Darwish <darwi@linutronix.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250317164745.4754-3-darwi@linutronix.de
---
 arch/x86/include/asm/cpuid/api.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/cpuid/api.h b/arch/x86/include/asm/cpuid/api.h
index 356db1894588..9c180c9cc58e 100644
--- a/arch/x86/include/asm/cpuid/api.h
+++ b/arch/x86/include/asm/cpuid/api.h
@@ -187,9 +187,9 @@ static __always_inline bool cpuid_function_is_indexed(u32 function)
 #define for_each_possible_hypervisor_cpuid_base(function) \
 	for (function = 0x40000000; function < 0x40010000; function += 0x100)
 
-static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
+static inline u32 hypervisor_cpuid_base(const char *sig, u32 leaves)
 {
-	uint32_t base, eax, signature[3];
+	u32 base, eax, signature[3];
 
 	for_each_possible_hypervisor_cpuid_base(base) {
 		cpuid(base, &eax, &signature[0], &signature[1], &signature[2]);
-- 
2.45.2