* [PATCH 00/74] New Intel CPUID families
@ 2024-03-28 16:37 Tony Luck
2024-03-28 16:37 ` [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 Tony Luck
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Tony Luck @ 2024-03-28 16:37 UTC (permalink / raw)
To: x86; +Cc: linux-kernel, Tony Luck
Q1: Where are all the other parts of this series. I only got 1-3.
A1: There are ~2700 subscribers to LKML. I want to get some feedback
on the approach and naming etc. before spamming everyone with a 74
patch series.
Q2: Can I get the other parts?
A2: Sure. I posted them to patches@lists.linux.dev so you can get them
with:
$ b4 am 20240328090459.242500-tony.luck@intel.com
or get from kernel.org with:
$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git new_families
Q3: When are CPUs using new families coming?
A3: Soon-ish. We have some time to get the infrastructure right.
Intel has been using family 6 almost exclusively for many
years. As a result, Linux has built up infrastructure like
X86_MATCH_INTEL_FAM6_MODEL() to make it easy for model specific code to
use the #defines for each Intel CPU model.
But the reign of family 6 is about to end. Intel will begin using non-zero
values for the extended family field in CPUID(1).EAX. The minimal patch
size approach to handle these would be to clone the FAM6 macros. But
that will get messy as these prolifrate. This approach does not have an
elegant solution if a switch() statement needs to choose between CPUs
from different families.
Dave Hansen suggested that a more general cleanup that provides
CPU #defines that encode all of <vendor, family, model> would make
existing code better, and provide infrastructure that makes it trivial
to incorporate new families.
Big picture view is that code like this:
if (c->x86_vendor == X86_VENDOR_INTEL && c->x86 == 6 && c->x86_model == INTEL_FAM6_ICELAKE_X)
can become:
if (c->x86_vfm == INTEL_ICELAKE_X)
which is:
a) Simpler
b) Faster
c) More resilient (can't forget to check vendor & family along with model)
d) Code style doesn't change for every new family.
Note that "struct cpuinfo_x86" gains a new xf6_vfm field and the ICELAKE
#define loses the "FAM6_" substring and will be initialized with a macro
that does the bit shuffling to fit X86_VENDOR_INTEL and a family and
model into a "u32":
#define INTEL_ICELAKE_X IFM(6, 0x6A) /* Sunny Cove */
New CPUs in other families might look like:
#define INTEL_DOUGLASCOVE IFM(42, 0x01) /* Adams Lake */
#define INTEL_SHELDONMONT IFM(73, 0x01) /* Cooper Forest */
Model specific "if" statements then follow the same pattern
regardless of family:
if (c->x86_vfm == INTEL_DOUGLASCOVE || c->x86_vfm == INTEL_SHELDONMONT) {
}
If needed these could even appear in the same switch statement:
switch (c->x86_vfm) {
case INTEL_ICELAKE_X:
...
case INTEL_DOUGLASCOVE:
...
case INTEL_SHELDONMONT:
...
}
The existing X86_MATCH_INTEL_FAM6_MODEL() can be replaced with a new
X86_MATCH_VFM() macro.
Update can happen in three phases:
1) Add infrastructure macros, new "x86_vfm" field, new CPU #defines
2) Treewide update from old to new (around 70 files at current count)
3) Delete the old INTEL_FAM6 and X86_MATCH_INTEL_FAM6 macros
Tony Luck (74):
x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86
x86/cpu/vfm: Add new macros to work with (vendor/family/model) values
x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h
x86/cpu/vfm: Update arch/x86/crypto/poly1305_glue.c
x86/cpu/vfm: Update arch/x86/crypto/twofish_glue_3way.c
x86/cpu/vfm: Update arch/x86/events/intel/cstate.c
x86/cpu/vfm: Update arch/x86/events/intel/lbr.c
x86/cpu/vfm: Update arch/x86/events/intel/pt.c
x86/cpu/vfm: Update arch/x86/events/intel/uncore.c
x86/cpu/vfm: Update arch/x86/events/intel/uncore_nhmex.c
x86/cpu/vfm: Update arch/x86/events/intel/uncore_snbep.c
x86/cpu/vfm: Update arch/x86/events/msr.c
x86/cpu/vfm: Update arch/x86/events/rapl.c
x86/cpu/vfm: Update arch/x86/kernel/apic/apic.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/aperfmperf.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/bugs.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/common.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/intel.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/intel_epb.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/match.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/core.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/intel.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/severity.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/microcode/intel.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/resctrl/core.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/resctrl/pseudo_lock.c
x86/cpu/vfm: Update arch/x86/kernel/smpboot.c
x86/cpu/vfm: Update arch/x86/kernel/tsc.c
x86/cpu/vfm: Update arch/x86/kernel/tsc_msr.c
x86/cpu/vfm: Update arch/x86/kvm/pmu.c
x86/cpu/vfm: Update arch/x86/kvm/vmx/vmx.c
x86/cpu/vfm: Update arch/x86/mm/init.c
x86/cpu/vfm: Update arch/x86/pci/intel_mid_pci.c
x86/cpu/vfm: Update arch/x86/virt/vmx/tdx/tdx.c
x86/cpu/vfm: Update drivers/acpi/acpi_lpss.c
x86/cpu/vfm: Update drivers/acpi/x86/utils.c
x86/cpu/vfm: Update tpm files
x86/cpu/vfm: Update drivers/cpufreq/intel_pstate.c
x86/cpu/vfm: Update drivers/cpufreq/speedstep-centrino.c
x86/cpu/vfm: Update drivers/edac/i10nm_base.c
x86/cpu/vfm: Update drivers/edac/pnd2_edac.c
x86/cpu/vfm: Update drivers/edac/sb_edac.c
x86/cpu/vfm: Update drivers/edac/skx_base.c
x86/cpu/vfm: Update drivers/extcon/extcon-axp288.c
x86/cpu/vfm: Update drivers/hwmon/peci/cputemp.c
x86/cpu/vfm: Update drivers/idle/intel_idle.c
x86/cpu/vfm: Update drivers/pci/pci-mid.c
x86/cpu/vfm: Update drivers/peci/cpu.c
x86/cpu/vfm: Update drivers/platform/x86/intel/ifs/core.c
x86/cpu/vfm: Update drivers/platform/x86/intel_ips.c
x86/cpu/vfm: Update drivers/platform/x86/intel/pmc/core.c
x86/cpu/vfm: Update drivers/platform/x86/intel/pmc/pltdrv.c
x86/cpu/vfm: Update drivers/platform/x86/intel_scu_wdt.c
x86/cpu/vfm: Update
drivers/platform/x86/intel/speed_select_if/isst_if_common.c
x86/cpu/vfm: Update
drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c
x86/cpu/vfm: Update drivers/platform/x86/intel/telemetry/debugfs.c
x86/cpu/vfm: Update drivers/platform/x86/intel/telemetry/pltdrv.c
x86/cpu/vfm: Update drivers/platform/x86/intel/turbo_max_3.c
x86/cpu/vfm: Update
drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c
x86/cpu/vfm: Update drivers/platform/x86/p2sb.c
x86/cpu/vfm: Update drivers/powercap/intel_rapl_common.c
x86/cpu/vfm: Update drivers/powercap/intel_rapl_msr.c
x86/cpu/vfm: Update
drivers/staging/media/atomisp/include/linux/atomisp_platform.h
x86/cpu/vfm: Update intel_soc_dts_thermal.c
x86/cpu/vfm: Update drivers/thermal/intel/intel_tcc_cooling.c
x86/cpu/vfm: Update sound/soc/intel/avs/boards/es8336.c
x86/cpu/vfm: Update arch/x86/events/intel/core.c
x86/cpu/vfm: Update arch/x86/platform/intel-mid/intel-mid.c
x86/cpu/vfm: Update arch/x86/platform/atom/punit_atom_debug.c
x86/cpu/vfm: Update arch/x86/events/intel/core.c
x86/cpu/vfm: Update tools/power/x86/turbostat/turbostat.c
x86/cpu/vfm: Update arch/x86/boot/cpucheck.c
x86/cpu/vfm: Delete X86_MATCH_INTEL_FAM6_MODEL[_STEPPING]() macros
x86/cpu/vfm: Delete all the *_FAM6_ CPU #defines
.../atomisp/include/linux/atomisp_platform.h | 26 +--
include/linux/peci-cpu.h | 1 +
include/linux/platform_data/x86/soc.h | 12 +-
arch/x86/include/asm/cpu_device_id.h | 103 +++++++--
arch/x86/include/asm/intel-family.h | 167 +++++++-------
arch/x86/include/asm/processor.h | 12 +-
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm_tis_core.h | 2 +-
arch/x86/boot/cpucheck.c | 2 +-
arch/x86/crypto/poly1305_glue.c | 3 +-
arch/x86/crypto/twofish_glue_3way.c | 10 +-
arch/x86/events/intel/core.c | 212 +++++++++---------
arch/x86/events/intel/cstate.c | 144 ++++++------
arch/x86/events/intel/lbr.c | 3 +-
arch/x86/events/intel/pt.c | 11 +-
arch/x86/events/intel/uncore.c | 100 ++++-----
arch/x86/events/intel/uncore_nhmex.c | 3 +-
arch/x86/events/intel/uncore_snbep.c | 5 +-
arch/x86/events/msr.c | 131 +++++------
arch/x86/events/rapl.c | 84 +++----
arch/x86/kernel/apic/apic.c | 38 ++--
arch/x86/kernel/cpu/aperfmperf.c | 17 +-
arch/x86/kernel/cpu/bugs.c | 29 +--
arch/x86/kernel/cpu/common.c | 154 +++++++------
arch/x86/kernel/cpu/intel.c | 115 +++++-----
arch/x86/kernel/cpu/intel_epb.c | 12 +-
arch/x86/kernel/cpu/match.c | 5 +-
arch/x86/kernel/cpu/mce/core.c | 5 +-
arch/x86/kernel/cpu/mce/intel.c | 20 +-
arch/x86/kernel/cpu/mce/severity.c | 9 +-
arch/x86/kernel/cpu/microcode/intel.c | 4 +-
arch/x86/kernel/cpu/resctrl/core.c | 9 +-
arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 21 +-
arch/x86/kernel/smpboot.c | 6 +-
arch/x86/kernel/tsc.c | 5 +-
arch/x86/kernel/tsc_msr.c | 14 +-
arch/x86/kvm/pmu.c | 8 +-
arch/x86/kvm/vmx/vmx.c | 20 +-
arch/x86/mm/init.c | 16 +-
arch/x86/pci/intel_mid_pci.c | 4 +-
arch/x86/platform/atom/punit_atom_debug.c | 11 +-
arch/x86/platform/intel-mid/intel-mid.c | 7 +-
arch/x86/virt/vmx/tdx/tdx.c | 7 +-
drivers/acpi/acpi_lpss.c | 4 +-
drivers/acpi/x86/utils.c | 42 ++--
drivers/cpufreq/intel_pstate.c | 90 ++++----
drivers/cpufreq/speedstep-centrino.c | 8 +-
drivers/edac/i10nm_base.c | 20 +-
drivers/edac/pnd2_edac.c | 4 +-
drivers/edac/sb_edac.c | 14 +-
drivers/edac/skx_base.c | 2 +-
drivers/extcon/extcon-axp288.c | 2 +-
drivers/hwmon/peci/cputemp.c | 7 +-
drivers/idle/intel_idle.c | 116 +++++-----
drivers/pci/pci-mid.c | 4 +-
drivers/peci/cpu.c | 28 +--
drivers/platform/x86/intel/ifs/core.c | 15 +-
drivers/platform/x86/intel/pmc/core.c | 46 ++--
drivers/platform/x86/intel/pmc/pltdrv.c | 16 +-
.../intel/speed_select_if/isst_if_common.c | 4 +-
.../intel/speed_select_if/isst_if_mbox_msr.c | 2 +-
.../platform/x86/intel/telemetry/debugfs.c | 4 +-
drivers/platform/x86/intel/telemetry/pltdrv.c | 4 +-
drivers/platform/x86/intel/turbo_max_3.c | 4 +-
.../intel/uncore-frequency/uncore-frequency.c | 56 ++---
drivers/platform/x86/intel_ips.c | 3 +-
drivers/platform/x86/intel_scu_wdt.c | 2 +-
drivers/platform/x86/p2sb.c | 2 +-
drivers/powercap/intel_rapl_common.c | 118 +++++-----
drivers/powercap/intel_rapl_msr.c | 16 +-
drivers/thermal/intel/intel_soc_dts_thermal.c | 2 +-
drivers/thermal/intel/intel_tcc_cooling.c | 30 +--
sound/soc/intel/avs/boards/es8336.c | 7 +-
tools/power/x86/turbostat/turbostat.c | 161 +++++++------
74 files changed, 1258 insertions(+), 1143 deletions(-)
base-commit: 4cece764965020c22cff7665b18a012006359095
--
2.44.0
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 16:37 [PATCH 00/74] New Intel CPUID families Tony Luck @ 2024-03-28 16:37 ` Tony Luck 2024-03-28 16:48 ` Borislav Petkov 2024-04-01 18:23 ` [PATCH v2 " Tony Luck 2024-03-28 16:37 ` [PATCH 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values Tony Luck 2024-03-28 16:37 ` [PATCH 03/74] x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h Tony Luck 2 siblings, 2 replies; 33+ messages in thread From: Tony Luck @ 2024-03-28 16:37 UTC (permalink / raw) To: x86; +Cc: linux-kernel, Tony Luck Refactor struct cpuinfo_x86 so that the vendor, family, and model fields are overlayed in a union with a 32-bit field that combines all three (together with a one byte reserved field in the upper byte). This will make it easy, cheap, and reliable to check all three values at once. Signed-off-by: Tony Luck <tony.luck@intel.com> --- arch/x86/include/asm/processor.h | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 811548f131f4..87115e5d884f 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -108,9 +108,15 @@ struct cpuinfo_topology { }; struct cpuinfo_x86 { - __u8 x86; /* CPU family */ - __u8 x86_vendor; /* CPU vendor */ - __u8 x86_model; + union { + struct { + __u8 x86_vendor; /* CPU vendor */ + __u8 x86; /* CPU family */ + __u8 x86_model; + __u8 x86_reserved; + }; + __u32 x86_vfm; /* combined vendor, family, model */ + }; __u8 x86_stepping; #ifdef CONFIG_X86_64 /* Number of 4K pages in DTLB/ITLB combined(in pages): */ -- 2.44.0 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 16:37 ` [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 Tony Luck @ 2024-03-28 16:48 ` Borislav Petkov 2024-03-28 16:52 ` Borislav Petkov 2024-03-28 16:56 ` Luck, Tony 2024-04-01 18:23 ` [PATCH v2 " Tony Luck 1 sibling, 2 replies; 33+ messages in thread From: Borislav Petkov @ 2024-03-28 16:48 UTC (permalink / raw) To: Tony Luck; +Cc: x86, linux-kernel On Thu, Mar 28, 2024 at 09:37:44AM -0700, Tony Luck wrote: > Refactor struct cpuinfo_x86 so that the vendor, family, and model > fields are overlayed in a union with a 32-bit field that combines > all three (together with a one byte reserved field in the upper > byte). > > This will make it easy, cheap, and reliable to check all three > values at once. > > Signed-off-by: Tony Luck <tony.luck@intel.com> > --- > arch/x86/include/asm/processor.h | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h > index 811548f131f4..87115e5d884f 100644 > --- a/arch/x86/include/asm/processor.h > +++ b/arch/x86/include/asm/processor.h > @@ -108,9 +108,15 @@ struct cpuinfo_topology { > }; > > struct cpuinfo_x86 { > - __u8 x86; /* CPU family */ > - __u8 x86_vendor; /* CPU vendor */ > - __u8 x86_model; > + union { > + struct { > + __u8 x86_vendor; /* CPU vendor */ > + __u8 x86; /* CPU family */ > + __u8 x86_model; > + __u8 x86_reserved; > + }; > + __u32 x86_vfm; /* combined vendor, family, model */ > + }; > __u8 x86_stepping; Why are you leaving out stepping? And since we want to simplify all this, why aren't we replacing all f/m/s checks by using the whole CPUID(1).EAX u32 instead? Then the macros need to build that CPUID leaf simply. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 16:48 ` Borislav Petkov @ 2024-03-28 16:52 ` Borislav Petkov 2024-03-28 17:00 ` Luck, Tony 2024-03-28 16:56 ` Luck, Tony 1 sibling, 1 reply; 33+ messages in thread From: Borislav Petkov @ 2024-03-28 16:52 UTC (permalink / raw) To: Tony Luck; +Cc: x86, linux-kernel On Thu, Mar 28, 2024 at 05:48:11PM +0100, Borislav Petkov wrote: > > + struct { > > + __u8 x86_vendor; /* CPU vendor */ Looking at this more - you don't really need the vendor to be part of this as the CPUID leaf ranges should *actually* be disjunct. Actually... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 16:52 ` Borislav Petkov @ 2024-03-28 17:00 ` Luck, Tony 2024-03-28 17:12 ` Borislav Petkov 0 siblings, 1 reply; 33+ messages in thread From: Luck, Tony @ 2024-03-28 17:00 UTC (permalink / raw) To: Borislav Petkov; +Cc: x86, linux-kernel > Looking at this more - you don't really need the vendor to be part of > this as the CPUID leaf ranges should *actually* be disjunct. Actually... It's essentially free to do this, and it makes the code more robust. It becomes impossible to check model without also checking vendor and family at the same time. -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 17:00 ` Luck, Tony @ 2024-03-28 17:12 ` Borislav Petkov 2024-03-28 18:32 ` Luck, Tony 0 siblings, 1 reply; 33+ messages in thread From: Borislav Petkov @ 2024-03-28 17:12 UTC (permalink / raw) To: Luck, Tony; +Cc: x86, linux-kernel On Thu, Mar 28, 2024 at 05:00:59PM +0000, Luck, Tony wrote: > It's essentially free to do this, and it makes the code more robust. It > becomes impossible to check model without also checking vendor > and family at the same time. I see that but if we want to use CPUID(1).EAX, there's no vendor in there. And frankly, the x86 vendor is a Linux thing so I wouldn't mind if checks are if (c->x86_vendor == X86_VENDOR... && c->cpuid_1_eax == MACRO_BUILD_CPUID_1_EAX(fam, model, stepping)) Anyway, using CPUID(1).EAX is just a suggestion so that we don't have to invent our own format and convert to and fro. And that would be advantageous when we convert to dealing with CPUID(1).EAX values everywhere and we compare them straightaway. We'd need macros only when we need only some data elements from that leaf. And since that leaf's layout is commonly known, the conversion errors should be at a minimum... I'd say. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 17:12 ` Borislav Petkov @ 2024-03-28 18:32 ` Luck, Tony 2024-03-28 20:52 ` Luck, Tony 2024-03-29 11:40 ` Borislav Petkov 0 siblings, 2 replies; 33+ messages in thread From: Luck, Tony @ 2024-03-28 18:32 UTC (permalink / raw) To: Borislav Petkov; +Cc: x86, linux-kernel > And frankly, the x86 vendor is a Linux thing so I wouldn't mind if > checks are > > if (c->x86_vendor == X86_VENDOR... && > c->cpuid_1_eax == MACRO_BUILD_CPUID_1_EAX(fam, model, stepping)) That hurts my eyes compared to: if (c->x86_vfm == INTEL_DOUGLASCOVE) > > Anyway, using CPUID(1).EAX is just a suggestion so that we don't have to > invent our own format and convert to and fro. All the conversion is at compile time to generate the values for the CPU model name #defines. > And that would be advantageous when we convert to dealing with > CPUID(1).EAX values everywhere and we compare them straightaway. We'd > need macros only when we need only some data elements from that leaf. It's a humungous amount more code churn. Most of the changes in this set were achieved with some simple sed scripts (followed by hand massage to adjust TABs to make things pretty because lengths of strings are different). Take a look at a few of the patches that implement this change and consider how they would look based on a CPUID(1).EAX value. > And since that leaf's layout is commonly known, the conversion errors > should be at a minimum... > > I'd say. I don't think the format is really that big an issue. Including stepping in the format adds complexity to a thousand places these checks are made while only being useful in a few dozen. -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 18:32 ` Luck, Tony @ 2024-03-28 20:52 ` Luck, Tony 2024-03-29 11:40 ` Borislav Petkov 1 sibling, 0 replies; 33+ messages in thread From: Luck, Tony @ 2024-03-28 20:52 UTC (permalink / raw) To: Borislav Petkov; +Cc: x86, linux-kernel > I don't think the format is really that big an issue. Including stepping in the > format adds complexity to a thousand places these checks are made while > only being useful in a few dozen. Stats to back that up: $ git grep INTEL_FAM6 | wc -l 876 but some of those are the definitions of the model name macros: $ git grep INTEL_FAM6 -- arch/x86/include/asm/intel-family.h | wc -l 82 Places using the X86_MATCH_INTEL macros don't show in above count: $ git grep X86_MATCH_INTEL | wc -l 430 Places that use STEPPINGS: $ git grep X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS | wc -l 21 or STEPPINGS + FEATURE $ git grep gg X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE | wc -l 6 $ git grep x86_stepping | wc -l 83 -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 18:32 ` Luck, Tony 2024-03-28 20:52 ` Luck, Tony @ 2024-03-29 11:40 ` Borislav Petkov 2024-03-29 16:46 ` Tony Luck 2024-04-01 18:18 ` Tony Luck 1 sibling, 2 replies; 33+ messages in thread From: Borislav Petkov @ 2024-03-29 11:40 UTC (permalink / raw) To: Luck, Tony; +Cc: x86, linux-kernel On Thu, Mar 28, 2024 at 06:32:35PM +0000, Luck, Tony wrote: > I don't think the format is really that big an issue. Including stepping in the > format adds complexity to a thousand places these checks are made while > only being useful in a few dozen. I've figured out what the problem is with steppings - ranges. If you have a range of steppings which all belong to the same model, then you have to complicate the checks by either masking out the stepping or use the X86_STEPPING_ANY thing which forces you to use x86_match_cpu() instead of a simple integer comparison. And you should talk to your folks what their plan is for the new families because if they do a range of model numbers which all belong to the same CPU model like AMD does, then your simple comparison scheme goes out the window because it can't really deal with ranges. Because from looking at your set, I don't see a slick way to check whether a concrete f/m/s tuple belongs to a range without involved checking. For example, models: case 0x30 ... 0x4f: case 0x60 ... 0x7f: case 0x90 ... 0x91: case 0xa0 ... 0xaf: are all Zen2. I could do a X86_MATCH_VF_MODEL_RANGE and we even had a patch like that at some point but it didn't go in. But even if I did that, I'd still need to do x86_match_cpu() instead of the current X86_FEATURE_ZEN* checks we're doing. So I don't think I can switch AMD to use that. It looks like the 'V' in "VFM" could just as well turn into "I". :-) I'd say. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-29 11:40 ` Borislav Petkov @ 2024-03-29 16:46 ` Tony Luck 2024-03-29 17:23 ` Borislav Petkov 2024-04-01 18:18 ` Tony Luck 1 sibling, 1 reply; 33+ messages in thread From: Tony Luck @ 2024-03-29 16:46 UTC (permalink / raw) To: Borislav Petkov; +Cc: x86, linux-kernel On Fri, Mar 29, 2024 at 12:40:07PM +0100, Borislav Petkov wrote: > On Thu, Mar 28, 2024 at 06:32:35PM +0000, Luck, Tony wrote: > > I don't think the format is really that big an issue. Including stepping in the > > format adds complexity to a thousand places these checks are made while > > only being useful in a few dozen. > > I've figured out what the problem is with steppings - ranges. If you > have a range of steppings which all belong to the same model, then you > have to complicate the checks by either masking out the stepping or use > the X86_STEPPING_ANY thing which forces you to use x86_match_cpu() > instead of a simple integer comparison. I think you are talking about a range of models that all belong to the same family (rather than steppings in the same model). > And you should talk to your folks what their plan is for the new > families because if they do a range of model numbers which all belong to > the same CPU model like AMD does, then your simple comparison scheme > goes out the window because it can't really deal with ranges. History of Intel model number allocations apparently looks like we just throw a dart in the general area of a block of unused model numbers :-) I will check with the relevent folks, but this seems unlikely. There's more push (from the Linux community!) to assign CPUID feature bits for stuff that goes more than 2-3 CPU generations. That leaves the stuff that is different almost every time (perfomaance counters, power management, EDAC, etc.). > Because from looking at your set, I don't see a slick way to check > whether a concrete f/m/s tuple belongs to a range without involved > checking. > > For example, models: > > case 0x30 ... 0x4f: > case 0x60 ... 0x7f: > case 0x90 ... 0x91: > case 0xa0 ... 0xaf: > > are all Zen2. I could do a X86_MATCH_VF_MODEL_RANGE and we even had I'm glad I don't have to keep track of groups of hex numbers like that. > a patch like that at some point but it didn't go in. But even if I did > that, I'd still need to do x86_match_cpu() instead of the current > X86_FEATURE_ZEN* checks we're doing. My patch doesn't help with this, but doesn't prevent you from doing a switch (c->x86_model). If that list of model number ranges shows up more than twice you could add a helper that converts that list to a #define AMD_ZEN2 to make the code clearer. > So I don't think I can switch AMD to use that. It looks like the 'V' in > "VFM" could just as well turn into "I". Patch 3 includes: #define IFM(_fam, _model) VFM_MAKE(X86_VENDOR_INTEL, _fam, _model) as a helper to build model numbers in <asm/intel-family.h> > > :-) > > I'd say. So keep the "V" in the common code. Maybe one of the other x86 vendors will want to have #define names for their CPU models some day. Thanks for digging into this. -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-29 16:46 ` Tony Luck @ 2024-03-29 17:23 ` Borislav Petkov 0 siblings, 0 replies; 33+ messages in thread From: Borislav Petkov @ 2024-03-29 17:23 UTC (permalink / raw) To: Tony Luck; +Cc: x86, linux-kernel On Fri, Mar 29, 2024 at 09:46:25AM -0700, Tony Luck wrote: > I think you are talking about a range of models that all belong to > the same family (rather than steppings in the same model). Either. Depending on what you're tracking. If the majority of your feature tests want to determine whether you're running on the same set of hw features which belong to a model determined by a single or multiple model numbers, then you need to track that. On Intel you have a single model number determining that set of hw features. On AMD you have s range of model numbers and there can be differences too. Seldom we pay attention to steppings but it is not unheard of. We have had an incremented stepping denoting a hw bug fix in the past. > History of Intel model number allocations apparently looks like > we just throw a dart in the general area of a block of unused > model numbers :-) Don't say that. The guy who's assigning the numbers and keeps track of what he's given to which team, will be mad at you. :-P > I'm glad I don't have to keep track of groups of hex numbers like that. Depends on how you model it. Setting a X86_FEATURE_ZEN<n> for each works like a charm. > My patch doesn't help with this, but doesn't prevent you from doing > a switch (c->x86_model). If that list of model number ranges shows > up more than twice you could add a helper that converts that list to > a #define AMD_ZEN2 to make the code clearer. Haven't needed such stunts yet and I hope I won't ever. > So keep the "V" in the common code. Maybe one of the other x86 > vendors will want to have #define names for their CPU models > some day. Right. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-29 11:40 ` Borislav Petkov 2024-03-29 16:46 ` Tony Luck @ 2024-04-01 18:18 ` Tony Luck 2024-04-07 10:54 ` Borislav Petkov 1 sibling, 1 reply; 33+ messages in thread From: Tony Luck @ 2024-04-01 18:18 UTC (permalink / raw) To: Borislav Petkov; +Cc: x86, linux-kernel On Fri, Mar 29, 2024 at 12:40:07PM +0100, Borislav Petkov wrote: > Because from looking at your set, I don't see a slick way to check > whether a concrete f/m/s tuple belongs to a range without involved > checking. > > For example, models: > > case 0x30 ... 0x4f: > case 0x60 ... 0x7f: > case 0x90 ... 0x91: > case 0xa0 ... 0xaf: > > are all Zen2. I could do a X86_MATCH_VF_MODEL_RANGE and we even had > a patch like that at some point but it didn't go in. But even if I did > that, I'd still need to do x86_match_cpu() instead of the current > X86_FEATURE_ZEN* checks we're doing. I realized the problem with ranges is the order I put the bits into the x86_vfm field. If I swap around to put the vendor in high bits, family in the middle, model in low bits like this: struct cpuinfo_x86 { union { struct { __u8 x86_model; __u8 x86; /* CPU family */ __u8 x86_vendor; /* CPU vendor */ __u8 x86_reserved; }; __u32 x86_vfm; /* combined vendor, family, model */ }; Then ranges of models within (or across) familiies can work. E.g. the AMD Zen generation checking could be changed from: /* Figure out Zen generations: */ switch (c->x86) { case 0x17: switch (c->x86_model) { case 0x00 ... 0x2f: case 0x50 ... 0x5f: setup_force_cpu_cap(X86_FEATURE_ZEN1); break; case 0x30 ... 0x4f: case 0x60 ... 0x7f: case 0x90 ... 0x91: case 0xa0 ... 0xaf: setup_force_cpu_cap(X86_FEATURE_ZEN2); break; default: goto warn; } break; case 0x19: switch (c->x86_model) { case 0x00 ... 0x0f: case 0x20 ... 0x5f: setup_force_cpu_cap(X86_FEATURE_ZEN3); break; case 0x10 ... 0x1f: case 0x60 ... 0xaf: setup_force_cpu_cap(X86_FEATURE_ZEN4); break; default: goto warn; } break; case 0x1a: switch (c->x86_model) { case 0x00 ... 0x0f: case 0x20 ... 0x2f: case 0x40 ... 0x4f: case 0x70 ... 0x7f: setup_force_cpu_cap(X86_FEATURE_ZEN5); break; default: goto warn; } break; default: break; } to: /* Figure out Zen generations: */ switch (c->x86_vfm) { case AFM(0x17, 0x00) ... AFM(0x17, 0x2f): case AFM(0x17, 0x50) ... AFM(0x17, 0x5f): setup_force_cpu_cap(X86_FEATURE_ZEN1); break; case AFM(0x17, 0x30) ... AFM(0x17, 0x4f): case AFM(0x17, 0x60) ... AFM(0x17, 0x7f): case AFM(0x17, 0x90) ... AFM(0x17, 0x91): case AFM(0x17, 0xa0) ... AFM(0x17, 0xaf): setup_force_cpu_cap(X86_FEATURE_ZEN2); break; case AFM(0x19, 0x00) ... AFM(0x19, 0x0f): case AFM(0x19, 0x20) ... AFM(0x19, 0x5f): setup_force_cpu_cap(X86_FEATURE_ZEN3); break; case AFM(0x19, 0x10) ... AFM(0x19, 0x1f): case AFM(0x19, 0x60) ... AFM(0x19, 0xaf): setup_force_cpu_cap(X86_FEATURE_ZEN4); break; case AFM(0x1a, 0x00) ... AFM(0x1a, 0x0f): case AFM(0x1a, 0x20) ... AFM(0x1a, 0x2f): case AFM(0x1a, 0x40) ... AFM(0x1a, 0x4f): case AFM(0x1a, 0x70) ... AFM(0x1a, 0x7f): setup_force_cpu_cap(X86_FEATURE_ZEN5); break; default: goto warn; } That's more visually more compact, but maybe not any more readable. But you would have the *option* to do this. I'll post V2 of parts 1 & 2 with the re-ordered fields. None of the rest of the patches need to change. -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-01 18:18 ` Tony Luck @ 2024-04-07 10:54 ` Borislav Petkov 2024-04-08 16:20 ` Luck, Tony 0 siblings, 1 reply; 33+ messages in thread From: Borislav Petkov @ 2024-04-07 10:54 UTC (permalink / raw) To: Tony Luck; +Cc: x86, linux-kernel On Mon, Apr 01, 2024 at 11:18:57AM -0700, Tony Luck wrote: > That's more visually more compact, but maybe not any more readable. Yap, I see it the same way. > But you would have the *option* to do this. Thanks, yeah, in case we ever get to cross that bridge... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-07 10:54 ` Borislav Petkov @ 2024-04-08 16:20 ` Luck, Tony 2024-04-09 8:22 ` Borislav Petkov 0 siblings, 1 reply; 33+ messages in thread From: Luck, Tony @ 2024-04-08 16:20 UTC (permalink / raw) To: Borislav Petkov; +Cc: x86, linux-kernel >> That's more visually more compact, but maybe not any more readable. > > Yap, I see it the same way. > > But you would have the *option* to do this. > > Thanks, yeah, in case we ever get to cross that bridge... Boris, So are parts 1-3 ready for TIP? If they get added I can start collecting reviews for parts 4-72. 73 and 74 are the cleanup to delete bits that are no longer needed. -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-08 16:20 ` Luck, Tony @ 2024-04-09 8:22 ` Borislav Petkov 2024-04-16 18:16 ` Tony Luck 0 siblings, 1 reply; 33+ messages in thread From: Borislav Petkov @ 2024-04-09 8:22 UTC (permalink / raw) To: Luck, Tony, Thomas Gleixner; +Cc: x86, linux-kernel On Mon, Apr 08, 2024 at 04:20:36PM +0000, Luck, Tony wrote: > So are parts 1-3 ready for TIP? If they get added I can start collecting > reviews for parts 4-72. I'd like for tglx to have a look at this first too. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-09 8:22 ` Borislav Petkov @ 2024-04-16 18:16 ` Tony Luck 2024-04-16 18:23 ` Borislav Petkov 0 siblings, 1 reply; 33+ messages in thread From: Tony Luck @ 2024-04-16 18:16 UTC (permalink / raw) To: Borislav Petkov; +Cc: Thomas Gleixner, x86, linux-kernel On Tue, Apr 09, 2024 at 10:22:17AM +0200, Borislav Petkov wrote: > On Mon, Apr 08, 2024 at 04:20:36PM +0000, Luck, Tony wrote: > > So are parts 1-3 ready for TIP? If they get added I can start collecting > > reviews for parts 4-72. > > I'd like for tglx to have a look at this first too. Boris, Thomas gave his Reviewed-by for parts 1-3 Link: https://lore.kernel.org/all/871q7e7lfu.ffs@tglx/ Link: https://lore.kernel.org/all/87y19m66tu.ffs@tglx/ Link: https://lore.kernel.org/all/87v84q66sn.ffs@tglx/ Is there anyone else that needs a quick poke to look at these? -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-16 18:16 ` Tony Luck @ 2024-04-16 18:23 ` Borislav Petkov 2024-04-16 18:37 ` Luck, Tony 0 siblings, 1 reply; 33+ messages in thread From: Borislav Petkov @ 2024-04-16 18:23 UTC (permalink / raw) To: Tony Luck; +Cc: Thomas Gleixner, x86, linux-kernel On Tue, Apr 16, 2024 at 11:16:05AM -0700, Tony Luck wrote: > Thomas gave his Reviewed-by for parts 1-3 > > Link: https://lore.kernel.org/all/871q7e7lfu.ffs@tglx/ > Link: https://lore.kernel.org/all/87y19m66tu.ffs@tglx/ > Link: https://lore.kernel.org/all/87v84q66sn.ffs@tglx/ > > Is there anyone else that needs a quick poke to look at these? I don't think so. Aren't you going to send the whole set first though? Or what is the merge strategy here? Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-16 18:23 ` Borislav Petkov @ 2024-04-16 18:37 ` Luck, Tony 2024-04-16 19:58 ` Borislav Petkov 0 siblings, 1 reply; 33+ messages in thread From: Luck, Tony @ 2024-04-16 18:37 UTC (permalink / raw) To: Borislav Petkov; +Cc: Thomas Gleixner, x86, linux-kernel >> Is there anyone else that needs a quick poke to look at these? > > I don't think so. > > Aren't you going to send the whole set first though? > > Or what is the merge strategy here? I thought to get the first three into TIP, and thus into linux-next. Then I'd start posting patches to the individual files to their respective maintainers. Only about half are arch/x86. The rest are scattered around the tree. But if you'd like to see the whole series in one big mail thread, I can post it all. -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-16 18:37 ` Luck, Tony @ 2024-04-16 19:58 ` Borislav Petkov 2024-04-16 21:45 ` Luck, Tony 0 siblings, 1 reply; 33+ messages in thread From: Borislav Petkov @ 2024-04-16 19:58 UTC (permalink / raw) To: Luck, Tony; +Cc: Thomas Gleixner, x86, linux-kernel On Tue, Apr 16, 2024 at 06:37:18PM +0000, Luck, Tony wrote: > I thought to get the first three into TIP, and thus into linux-next. Then I'd > start posting patches to the individual files to their respective maintainers. > > Only about half are arch/x86. The rest are scattered around the tree. If you do that, people would have to merge the tip branch which has them before they apply them in their tree. Alternatively, we can take the arch/x86 parts and once 6.10 releases, the other maintainers will have them in tree and thus not need the cross-tree merges. > But if you'd like to see the whole series in one big mail thread, I can > post it all. Or you can post the whole series and we can take it all through tip once the other maintainers ack the respective patch for their area. Which sounds like the simplest solution to me... Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-16 19:58 ` Borislav Petkov @ 2024-04-16 21:45 ` Luck, Tony 2024-04-17 19:02 ` Sean Christopherson 0 siblings, 1 reply; 33+ messages in thread From: Luck, Tony @ 2024-04-16 21:45 UTC (permalink / raw) To: Borislav Petkov; +Cc: Thomas Gleixner, x86, linux-kernel > Alternatively, we can take the arch/x86 parts and once 6.10 releases, > the other maintainers will have them in tree and thus not need the > cross-tree merges. I did a bit of this. I moved all the arch/x86 patches up to immediately follow the three prep patches. So you can pick through parts 0004..0039 and apply any that look good to you (there is no ordering requirement among these). Bounce anything that needs extra work back to me. > Or you can post the whole series and we can take it all through tip once > the other maintainers ack the respective patch for their area. Which > sounds like the simplest solution to me... Also a bit of this. Parts 0040..0072 are posted to whomever get_maintainer.pl said might be interested. So may see some reviews coming in for these. Parts 0073..0074 are the cleanup to delete the old macros. They can only be applied after everything else has been merged. -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-16 21:45 ` Luck, Tony @ 2024-04-17 19:02 ` Sean Christopherson 2024-04-17 19:42 ` Borislav Petkov 0 siblings, 1 reply; 33+ messages in thread From: Sean Christopherson @ 2024-04-17 19:02 UTC (permalink / raw) To: Tony Luck; +Cc: Borislav Petkov, Thomas Gleixner, x86, linux-kernel On Tue, Apr 16, 2024, Tony Luck wrote: > > Alternatively, we can take the arch/x86 parts and once 6.10 releases, > > the other maintainers will have them in tree and thus not need the > > cross-tree merges. > > I did a bit of this. I moved all the arch/x86 patches up to immediately follow > the three prep patches. So you can pick through parts 0004..0039 and apply > any that look good to you (there is no ordering requirement among these). > Bounce anything that needs extra work back to me. There are two KVM changes hiding in there, but they're obviously quite trivial and can to through tip, I don't expect any conflicts. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-17 19:02 ` Sean Christopherson @ 2024-04-17 19:42 ` Borislav Petkov 2024-04-18 1:47 ` Luck, Tony 0 siblings, 1 reply; 33+ messages in thread From: Borislav Petkov @ 2024-04-17 19:42 UTC (permalink / raw) To: Sean Christopherson; +Cc: Tony Luck, Thomas Gleixner, x86, linux-kernel On Wed, Apr 17, 2024 at 12:02:21PM -0700, Sean Christopherson wrote: > There are two KVM changes hiding in there, but they're obviously quite trivial > and can to through tip, I don't expect any conflicts. Yeah, the plan is to queue it all through tip as that would be a lot less conflicts and cross-tree issues so you acking them is what I was hoping to get. So thanks. :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-17 19:42 ` Borislav Petkov @ 2024-04-18 1:47 ` Luck, Tony 0 siblings, 0 replies; 33+ messages in thread From: Luck, Tony @ 2024-04-18 1:47 UTC (permalink / raw) To: Borislav Petkov; +Cc: Sean Christopherson, Thomas Gleixner, x86, linux-kernel > On Apr 17, 2024, at 12:43, Borislav Petkov <bp@alien8.de> wrote: > > On Wed, Apr 17, 2024 at 12:02:21PM -0700, Sean Christopherson wrote: >> There are two KVM changes hiding in there, but they're obviously quite trivial >> and can to through tip, I don't expect any conflicts. > > Yeah, the plan is to queue it all through tip as that would be a lot > less conflicts and cross-tree issues so you acking them is what I was > hoping to get. > > So thanks. :-) There’s general (justified) grumbling about my auto-generated Subject lines. So I’ll make a pass through the whole series to make the initial tag match each subsystem convention. Also make it generally more useful. I.e. like this for most of the arch/x86 patches: Subject: x86/cpu: Use new Intel CPU model #defines Perhaps all the pieces with Reviewed or Acked tags can go into tip tree next week? -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 16:48 ` Borislav Petkov 2024-03-28 16:52 ` Borislav Petkov @ 2024-03-28 16:56 ` Luck, Tony 2024-03-28 17:06 ` Borislav Petkov 1 sibling, 1 reply; 33+ messages in thread From: Luck, Tony @ 2024-03-28 16:56 UTC (permalink / raw) To: Borislav Petkov; +Cc: x86, linux-kernel >> __u8 x86_stepping; > > Why are you leaving out stepping? There are only a handful of places where stepping is significant in CPU model specific checks (mostly errata and side-channel security stuff). I didn't want to have to invent new #define names for each stepping. E.g. there are about three separate steppings of INTEL_SKYLAKE_X out in the wild. It would be messy to have three #defines and add them in all the stepping independent code paths. > And since we want to simplify all this, why aren't we replacing all > f/m/s checks by using the whole CPUID(1).EAX u32 instead? > > Then the macros need to build that CPUID leaf simply. I could make the raw format of the #define values be CPUID(1).EAX with the stepping masked out. But then I'd need to add a new field to the structure instead of overlaying with the vendor/family/model fields. -Tony ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 16:56 ` Luck, Tony @ 2024-03-28 17:06 ` Borislav Petkov 0 siblings, 0 replies; 33+ messages in thread From: Borislav Petkov @ 2024-03-28 17:06 UTC (permalink / raw) To: Luck, Tony; +Cc: x86, linux-kernel On Thu, Mar 28, 2024 at 04:56:37PM +0000, Luck, Tony wrote: > I could make the raw format of the #define values be CPUID(1).EAX > with the stepping masked out. But then I'd need to add a new field to > the structure instead of overlaying with the vendor/family/model > fields. Yes, that would be better. And if you're going to replace our f/m/s checking with something better, then it better handle the stepping just like the rest. How it is used now doesn't mean a whole lot for the future. And if it is not too important for most checks, you can mask it out with macros. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v2 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 16:37 ` [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 Tony Luck 2024-03-28 16:48 ` Borislav Petkov @ 2024-04-01 18:23 ` Tony Luck 2024-04-09 12:46 ` Thomas Gleixner 1 sibling, 1 reply; 33+ messages in thread From: Tony Luck @ 2024-04-01 18:23 UTC (permalink / raw) To: x86; +Cc: linux-kernel Refactor struct cpuinfo_x86 so that the vendor, family, and model fields are overlayed in a union with a 32-bit field that combines all three (together with a one byte reserved field in the upper byte). This will make it easy, cheap, and reliable to check all three values at once. Signed-off-by: Tony Luck <tony.luck@intel.com> --- arch/x86/include/asm/processor.h | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 811548f131f4..4c5d166aa473 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -108,9 +108,15 @@ struct cpuinfo_topology { }; struct cpuinfo_x86 { - __u8 x86; /* CPU family */ - __u8 x86_vendor; /* CPU vendor */ - __u8 x86_model; + union { + struct { + __u8 x86_model; + __u8 x86; /* CPU family */ + __u8 x86_vendor; /* CPU vendor */ + __u8 x86_reserved; + }; + __u32 x86_vfm; /* combined vendor, family, model */ + }; __u8 x86_stepping; #ifdef CONFIG_X86_64 /* Number of 4K pages in DTLB/ITLB combined(in pages): */ -- 2.44.0 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [PATCH v2 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-04-01 18:23 ` [PATCH v2 " Tony Luck @ 2024-04-09 12:46 ` Thomas Gleixner 0 siblings, 0 replies; 33+ messages in thread From: Thomas Gleixner @ 2024-04-09 12:46 UTC (permalink / raw) To: Tony Luck, x86; +Cc: linux-kernel On Mon, Apr 01 2024 at 11:23, Tony Luck wrote: > Refactor struct cpuinfo_x86 so that the vendor, family, and model > fields are overlayed in a union with a 32-bit field that combines > all three (together with a one byte reserved field in the upper > byte). > > This will make it easy, cheap, and reliable to check all three > values at once. > > Signed-off-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> > --- > arch/x86/include/asm/processor.h | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h > index 811548f131f4..4c5d166aa473 100644 > --- a/arch/x86/include/asm/processor.h > +++ b/arch/x86/include/asm/processor.h > @@ -108,9 +108,15 @@ struct cpuinfo_topology { > }; > > struct cpuinfo_x86 { > - __u8 x86; /* CPU family */ > - __u8 x86_vendor; /* CPU vendor */ > - __u8 x86_model; > + union { > + struct { > + __u8 x86_model; > + __u8 x86; /* CPU family */ > + __u8 x86_vendor; /* CPU vendor */ > + __u8 x86_reserved; > + }; > + __u32 x86_vfm; /* combined vendor, family, model */ > + }; > __u8 x86_stepping; > #ifdef CONFIG_X86_64 > /* Number of 4K pages in DTLB/ITLB combined(in pages): */ ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values 2024-03-28 16:37 [PATCH 00/74] New Intel CPUID families Tony Luck 2024-03-28 16:37 ` [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 Tony Luck @ 2024-03-28 16:37 ` Tony Luck 2024-04-01 18:24 ` [PATCH v2 " Tony Luck 2024-03-28 16:37 ` [PATCH 03/74] x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h Tony Luck 2 siblings, 1 reply; 33+ messages in thread From: Tony Luck @ 2024-03-28 16:37 UTC (permalink / raw) To: x86; +Cc: linux-kernel, Tony Luck To avoid adding a slew of new macros for each new Intel CPU family switch over from providing CPU model number #defines to a new scheme that encodes vendor, family, and model in a single number. Signed-off-by: Tony Luck <tony.luck@intel.com> --- arch/x86/include/asm/cpu_device_id.h | 93 ++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h index eb8fcede9e3b..0e98d3fd0d38 100644 --- a/arch/x86/include/asm/cpu_device_id.h +++ b/arch/x86/include/asm/cpu_device_id.h @@ -2,6 +2,39 @@ #ifndef _ASM_X86_CPU_DEVICE_ID #define _ASM_X86_CPU_DEVICE_ID +/* + * Can't use <linux/bitfield.h> because it generates expressions that + * cannot be used in structure initializers. Bitfield construction + * here must match the union in struct cpuinfo_86: + * union { + * struct { + * __u8 x86_vendor; + * __u8 x86; + * __u8 x86_model; + * __u8 x86_reserved; + * }; + * __u32 x86_vfm; + * }; + */ +#define VFM_VENDOR_BIT 0 +#define VFM_FAMILY_BIT 8 +#define VFM_MODEL_BIT 16 +#define VFM_RSVD_BIT 24 + +#define VFM_VENDOR_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_VENDOR_BIT) +#define VFM_FAMILY_MASK GENMASK(VFM_MODEL_BIT - 1, VFM_FAMILY_BIT) +#define VFM_MODEL_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_MODEL_BIT) + +#define VFM_VENDOR(vfm) (((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT) +#define VFM_FAMILY(vfm) (((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT) +#define VFM_MODEL(vfm) (((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT) + +#define VFM_MAKE(_vendor, _family, _model) ( \ + ((_vendor) << VFM_VENDOR_BIT) | \ + ((_family) << VFM_FAMILY_BIT) | \ + ((_model) << VFM_MODEL_BIT) \ +) + /* * Declare drivers belonging to specific x86 CPUs * Similar in spirit to pci_device_id and related PCI functions @@ -49,6 +82,16 @@ .driver_data = (unsigned long) _data \ } +#define X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \ + _steppings, _feature, _data) { \ + .vendor = _vendor, \ + .family = _family, \ + .model = _model, \ + .steppings = _steppings, \ + .feature = _feature, \ + .driver_data = (unsigned long) _data \ +} + /** * X86_MATCH_VENDOR_FAM_MODEL_FEATURE - Macro for CPU matching * @_vendor: The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY @@ -164,6 +207,56 @@ X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6, INTEL_FAM6_##model, \ steppings, X86_FEATURE_ANY, data) +/** + * X86_MATCH_VFM - Match encoded vendor/family/model + * @vfm: Encoded 8-bits each for vendor, family, model + * @data: Driver specific data or NULL. The internal storage + * format is unsigned long. The supplied value, pointer + * etc. is casted to unsigned long internally. + * + * Stepping and feature are set to wildcards + */ +#define X86_MATCH_VFM(vfm, data) \ + X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \ + VFM_VENDOR(vfm), \ + VFM_FAMILY(vfm), \ + VFM_MODEL(vfm), \ + X86_STEPPING_ANY, X86_FEATURE_ANY, data) + +/** + * X86_MATCH_VFM_STEPPINGS - Match encoded vendor/family/model/stepping + * @vfm: Encoded 8-bits each for vendor, family, model + * @steppings: Bitmask of steppings to match + * @data: Driver specific data or NULL. The internal storage + * format is unsigned long. The supplied value, pointer + * etc. is casted to unsigned long internally. + * + * feature is set to wildcard + */ +#define X86_MATCH_VFM_STEPPINGS(vfm, steppings, data) \ + X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \ + VFM_VENDOR(vfm), \ + VFM_FAMILY(vfm), \ + VFM_MODEL(vfm), \ + steppings, X86_FEATURE_ANY, data) + +/** + * X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature + * @vfm: Encoded 8-bits each for vendor, family, model + * @feature: A X86_FEATURE bit + * @data: Driver specific data or NULL. The internal storage + * format is unsigned long. The supplied value, pointer + * etc. is casted to unsigned long internally. + * + * Steppings is set to wildcard + */ +#define X86_MATCH_VFM_FEATURE(vfm, feature, data) \ + X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \ + VFM_VENDOR(vfm), \ + VFM_FAMILY(vfm), \ + VFM_MODEL(vfm), \ + X86_STEPPING_ANY, feature, data) + /* * Match specific microcode revisions. * -- 2.44.0 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* [PATCH v2 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values 2024-03-28 16:37 ` [PATCH 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values Tony Luck @ 2024-04-01 18:24 ` Tony Luck 2024-04-09 12:47 ` Thomas Gleixner 0 siblings, 1 reply; 33+ messages in thread From: Tony Luck @ 2024-04-01 18:24 UTC (permalink / raw) To: x86; +Cc: linux-kernel To avoid adding a slew of new macros for each new Intel CPU family switch over from providing CPU model number #defines to a new scheme that encodes vendor, family, and model in a single number. Signed-off-by: Tony Luck <tony.luck@intel.com> --- arch/x86/include/asm/cpu_device_id.h | 93 ++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h index eb8fcede9e3b..b8a86c227d65 100644 --- a/arch/x86/include/asm/cpu_device_id.h +++ b/arch/x86/include/asm/cpu_device_id.h @@ -2,6 +2,39 @@ #ifndef _ASM_X86_CPU_DEVICE_ID #define _ASM_X86_CPU_DEVICE_ID +/* + * Can't use <linux/bitfield.h> because it generates expressions that + * cannot be used in structure initializers. Bitfield construction + * here must match the union in struct cpuinfo_86: + * union { + * struct { + * __u8 x86_model; + * __u8 x86; + * __u8 x86_vendor; + * __u8 x86_reserved; + * }; + * __u32 x86_vfm; + * }; + */ +#define VFM_MODEL_BIT 0 +#define VFM_FAMILY_BIT 8 +#define VFM_VENDOR_BIT 16 +#define VFM_RSVD_BIT 24 + +#define VFM_MODEL_MASK GENMASK(VFM_FAMILY_BIT - 1, VFM_MODEL_BIT) +#define VFM_FAMILY_MASK GENMASK(VFM_VENDOR_BIT - 1, VFM_FAMILY_BIT) +#define VFM_VENDOR_MASK GENMASK(VFM_RSVD_BIT - 1, VFM_VENDOR_BIT) + +#define VFM_MODEL(vfm) (((vfm) & VFM_MODEL_MASK) >> VFM_MODEL_BIT) +#define VFM_FAMILY(vfm) (((vfm) & VFM_FAMILY_MASK) >> VFM_FAMILY_BIT) +#define VFM_VENDOR(vfm) (((vfm) & VFM_VENDOR_MASK) >> VFM_VENDOR_BIT) + +#define VFM_MAKE(_vendor, _family, _model) ( \ + ((_model) << VFM_MODEL_BIT) | \ + ((_family) << VFM_FAMILY_BIT) | \ + ((_vendor) << VFM_VENDOR_BIT) \ +) + /* * Declare drivers belonging to specific x86 CPUs * Similar in spirit to pci_device_id and related PCI functions @@ -49,6 +82,16 @@ .driver_data = (unsigned long) _data \ } +#define X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \ + _steppings, _feature, _data) { \ + .vendor = _vendor, \ + .family = _family, \ + .model = _model, \ + .steppings = _steppings, \ + .feature = _feature, \ + .driver_data = (unsigned long) _data \ +} + /** * X86_MATCH_VENDOR_FAM_MODEL_FEATURE - Macro for CPU matching * @_vendor: The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY @@ -164,6 +207,56 @@ X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6, INTEL_FAM6_##model, \ steppings, X86_FEATURE_ANY, data) +/** + * X86_MATCH_VFM - Match encoded vendor/family/model + * @vfm: Encoded 8-bits each for vendor, family, model + * @data: Driver specific data or NULL. The internal storage + * format is unsigned long. The supplied value, pointer + * etc. is casted to unsigned long internally. + * + * Stepping and feature are set to wildcards + */ +#define X86_MATCH_VFM(vfm, data) \ + X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \ + VFM_VENDOR(vfm), \ + VFM_FAMILY(vfm), \ + VFM_MODEL(vfm), \ + X86_STEPPING_ANY, X86_FEATURE_ANY, data) + +/** + * X86_MATCH_VFM_STEPPINGS - Match encoded vendor/family/model/stepping + * @vfm: Encoded 8-bits each for vendor, family, model + * @steppings: Bitmask of steppings to match + * @data: Driver specific data or NULL. The internal storage + * format is unsigned long. The supplied value, pointer + * etc. is casted to unsigned long internally. + * + * feature is set to wildcard + */ +#define X86_MATCH_VFM_STEPPINGS(vfm, steppings, data) \ + X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \ + VFM_VENDOR(vfm), \ + VFM_FAMILY(vfm), \ + VFM_MODEL(vfm), \ + steppings, X86_FEATURE_ANY, data) + +/** + * X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature + * @vfm: Encoded 8-bits each for vendor, family, model + * @feature: A X86_FEATURE bit + * @data: Driver specific data or NULL. The internal storage + * format is unsigned long. The supplied value, pointer + * etc. is casted to unsigned long internally. + * + * Steppings is set to wildcard + */ +#define X86_MATCH_VFM_FEATURE(vfm, feature, data) \ + X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \ + VFM_VENDOR(vfm), \ + VFM_FAMILY(vfm), \ + VFM_MODEL(vfm), \ + X86_STEPPING_ANY, feature, data) + /* * Match specific microcode revisions. * -- 2.44.0 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [PATCH v2 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values 2024-04-01 18:24 ` [PATCH v2 " Tony Luck @ 2024-04-09 12:47 ` Thomas Gleixner 0 siblings, 0 replies; 33+ messages in thread From: Thomas Gleixner @ 2024-04-09 12:47 UTC (permalink / raw) To: Tony Luck, x86; +Cc: linux-kernel On Mon, Apr 01 2024 at 11:24, Tony Luck wrote: > To avoid adding a slew of new macros for each new Intel CPU family > switch over from providing CPU model number #defines to a new > scheme that encodes vendor, family, and model in a single number. > > Signed-off-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH 03/74] x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h 2024-03-28 16:37 [PATCH 00/74] New Intel CPUID families Tony Luck 2024-03-28 16:37 ` [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 Tony Luck 2024-03-28 16:37 ` [PATCH 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values Tony Luck @ 2024-03-28 16:37 ` Tony Luck 2024-04-09 12:48 ` Thomas Gleixner 2 siblings, 1 reply; 33+ messages in thread From: Tony Luck @ 2024-03-28 16:37 UTC (permalink / raw) To: x86; +Cc: linux-kernel, Tony Luck New CPU #defines encode vendor and family as well as model. Update the example usage comment in arch/x86/kernel/cpu/match.c Signed-off-by: Tony Luck <tony.luck@intel.com> --- arch/x86/include/asm/intel-family.h | 84 +++++++++++++++++++++++++++++ arch/x86/kernel/cpu/match.c | 3 +- 2 files changed, 85 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index d0941f4c2724..f81a851c46dc 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -40,137 +40,221 @@ * their own names :-( */ +#define IFM(_fam, _model) VFM_MAKE(X86_VENDOR_INTEL, _fam, _model) + /* Wildcard match for FAM6 so X86_MATCH_INTEL_FAM6_MODEL(ANY) works */ #define INTEL_FAM6_ANY X86_MODEL_ANY +/* Wildcard match for FAM6 so X86_MATCH_VFM(ANY) works */ +#define INTEL_ANY IFM(X86_FAMILY_ANY, X86_MODEL_ANY) #define INTEL_FAM6_CORE_YONAH 0x0E +#define INTEL_CORE_YONAH IFM(6, 0x0E) #define INTEL_FAM6_CORE2_MEROM 0x0F +#define INTEL_CORE2_MEROM IFM(6, 0x0F) #define INTEL_FAM6_CORE2_MEROM_L 0x16 +#define INTEL_CORE2_MEROM_L IFM(6, 0x16) #define INTEL_FAM6_CORE2_PENRYN 0x17 +#define INTEL_CORE2_PENRYN IFM(6, 0x17) #define INTEL_FAM6_CORE2_DUNNINGTON 0x1D +#define INTEL_CORE2_DUNNINGTON IFM(6, 0x1D) #define INTEL_FAM6_NEHALEM 0x1E +#define INTEL_NEHALEM IFM(6, 0x1E) #define INTEL_FAM6_NEHALEM_G 0x1F /* Auburndale / Havendale */ +#define INTEL_NEHALEM_G IFM(6, 0x1F) /* Auburndale / Havendale */ #define INTEL_FAM6_NEHALEM_EP 0x1A +#define INTEL_NEHALEM_EP IFM(6, 0x1A) #define INTEL_FAM6_NEHALEM_EX 0x2E +#define INTEL_NEHALEM_EX IFM(6, 0x2E) #define INTEL_FAM6_WESTMERE 0x25 +#define INTEL_WESTMERE IFM(6, 0x25) #define INTEL_FAM6_WESTMERE_EP 0x2C +#define INTEL_WESTMERE_EP IFM(6, 0x2C) #define INTEL_FAM6_WESTMERE_EX 0x2F +#define INTEL_WESTMERE_EX IFM(6, 0x2F) #define INTEL_FAM6_SANDYBRIDGE 0x2A +#define INTEL_SANDYBRIDGE IFM(6, 0x2A) #define INTEL_FAM6_SANDYBRIDGE_X 0x2D +#define INTEL_SANDYBRIDGE_X IFM(6, 0x2D) #define INTEL_FAM6_IVYBRIDGE 0x3A +#define INTEL_IVYBRIDGE IFM(6, 0x3A) #define INTEL_FAM6_IVYBRIDGE_X 0x3E +#define INTEL_IVYBRIDGE_X IFM(6, 0x3E) #define INTEL_FAM6_HASWELL 0x3C +#define INTEL_HASWELL IFM(6, 0x3C) #define INTEL_FAM6_HASWELL_X 0x3F +#define INTEL_HASWELL_X IFM(6, 0x3F) #define INTEL_FAM6_HASWELL_L 0x45 +#define INTEL_HASWELL_L IFM(6, 0x45) #define INTEL_FAM6_HASWELL_G 0x46 +#define INTEL_HASWELL_G IFM(6, 0x46) #define INTEL_FAM6_BROADWELL 0x3D +#define INTEL_BROADWELL IFM(6, 0x3D) #define INTEL_FAM6_BROADWELL_G 0x47 +#define INTEL_BROADWELL_G IFM(6, 0x47) #define INTEL_FAM6_BROADWELL_X 0x4F +#define INTEL_BROADWELL_X IFM(6, 0x4F) #define INTEL_FAM6_BROADWELL_D 0x56 +#define INTEL_BROADWELL_D IFM(6, 0x56) #define INTEL_FAM6_SKYLAKE_L 0x4E /* Sky Lake */ +#define INTEL_SKYLAKE_L IFM(6, 0x4E) /* Sky Lake */ #define INTEL_FAM6_SKYLAKE 0x5E /* Sky Lake */ +#define INTEL_SKYLAKE IFM(6, 0x5E) /* Sky Lake */ #define INTEL_FAM6_SKYLAKE_X 0x55 /* Sky Lake */ +#define INTEL_SKYLAKE_X IFM(6, 0x55) /* Sky Lake */ /* CASCADELAKE_X 0x55 Sky Lake -- s: 7 */ /* COOPERLAKE_X 0x55 Sky Lake -- s: 11 */ #define INTEL_FAM6_KABYLAKE_L 0x8E /* Sky Lake */ +#define INTEL_KABYLAKE_L IFM(6, 0x8E) /* Sky Lake */ /* AMBERLAKE_L 0x8E Sky Lake -- s: 9 */ /* COFFEELAKE_L 0x8E Sky Lake -- s: 10 */ /* WHISKEYLAKE_L 0x8E Sky Lake -- s: 11,12 */ #define INTEL_FAM6_KABYLAKE 0x9E /* Sky Lake */ +#define INTEL_KABYLAKE IFM(6, 0x9E) /* Sky Lake */ /* COFFEELAKE 0x9E Sky Lake -- s: 10-13 */ #define INTEL_FAM6_COMETLAKE 0xA5 /* Sky Lake */ +#define INTEL_COMETLAKE IFM(6, 0xA5) /* Sky Lake */ #define INTEL_FAM6_COMETLAKE_L 0xA6 /* Sky Lake */ +#define INTEL_COMETLAKE_L IFM(6, 0xA6) /* Sky Lake */ #define INTEL_FAM6_CANNONLAKE_L 0x66 /* Palm Cove */ +#define INTEL_CANNONLAKE_L IFM(6, 0x66) /* Palm Cove */ #define INTEL_FAM6_ICELAKE_X 0x6A /* Sunny Cove */ +#define INTEL_ICELAKE_X IFM(6, 0x6A) /* Sunny Cove */ #define INTEL_FAM6_ICELAKE_D 0x6C /* Sunny Cove */ +#define INTEL_ICELAKE_D IFM(6, 0x6C) /* Sunny Cove */ #define INTEL_FAM6_ICELAKE 0x7D /* Sunny Cove */ +#define INTEL_ICELAKE IFM(6, 0x7D) /* Sunny Cove */ #define INTEL_FAM6_ICELAKE_L 0x7E /* Sunny Cove */ +#define INTEL_ICELAKE_L IFM(6, 0x7E) /* Sunny Cove */ #define INTEL_FAM6_ICELAKE_NNPI 0x9D /* Sunny Cove */ +#define INTEL_ICELAKE_NNPI IFM(6, 0x9D) /* Sunny Cove */ #define INTEL_FAM6_ROCKETLAKE 0xA7 /* Cypress Cove */ +#define INTEL_ROCKETLAKE IFM(6, 0xA7) /* Cypress Cove */ #define INTEL_FAM6_TIGERLAKE_L 0x8C /* Willow Cove */ +#define INTEL_TIGERLAKE_L IFM(6, 0x8C) /* Willow Cove */ #define INTEL_FAM6_TIGERLAKE 0x8D /* Willow Cove */ +#define INTEL_TIGERLAKE IFM(6, 0x8D) /* Willow Cove */ #define INTEL_FAM6_SAPPHIRERAPIDS_X 0x8F /* Golden Cove */ +#define INTEL_SAPPHIRERAPIDS_X IFM(6, 0x8F) /* Golden Cove */ #define INTEL_FAM6_EMERALDRAPIDS_X 0xCF +#define INTEL_EMERALDRAPIDS_X IFM(6, 0xCF) #define INTEL_FAM6_GRANITERAPIDS_X 0xAD +#define INTEL_GRANITERAPIDS_X IFM(6, 0xAD) #define INTEL_FAM6_GRANITERAPIDS_D 0xAE +#define INTEL_GRANITERAPIDS_D IFM(6, 0xAE) /* "Hybrid" Processors (P-Core/E-Core) */ #define INTEL_FAM6_LAKEFIELD 0x8A /* Sunny Cove / Tremont */ +#define INTEL_LAKEFIELD IFM(6, 0x8A) /* Sunny Cove / Tremont */ #define INTEL_FAM6_ALDERLAKE 0x97 /* Golden Cove / Gracemont */ +#define INTEL_ALDERLAKE IFM(6, 0x97) /* Golden Cove / Gracemont */ #define INTEL_FAM6_ALDERLAKE_L 0x9A /* Golden Cove / Gracemont */ +#define INTEL_ALDERLAKE_L IFM(6, 0x9A) /* Golden Cove / Gracemont */ #define INTEL_FAM6_RAPTORLAKE 0xB7 /* Raptor Cove / Enhanced Gracemont */ +#define INTEL_RAPTORLAKE IFM(6, 0xB7) /* Raptor Cove / Enhanced Gracemont */ #define INTEL_FAM6_RAPTORLAKE_P 0xBA +#define INTEL_RAPTORLAKE_P IFM(6, 0xBA) #define INTEL_FAM6_RAPTORLAKE_S 0xBF +#define INTEL_RAPTORLAKE_S IFM(6, 0xBF) #define INTEL_FAM6_METEORLAKE 0xAC +#define INTEL_METEORLAKE IFM(6, 0xAC) #define INTEL_FAM6_METEORLAKE_L 0xAA +#define INTEL_METEORLAKE_L IFM(6, 0xAA) #define INTEL_FAM6_ARROWLAKE_H 0xC5 +#define INTEL_ARROWLAKE_H IFM(6, 0xC5) #define INTEL_FAM6_ARROWLAKE 0xC6 +#define INTEL_ARROWLAKE IFM(6, 0xC6) #define INTEL_FAM6_ARROWLAKE_U 0xB5 +#define INTEL_ARROWLAKE_U IFM(6, 0xB5) #define INTEL_FAM6_LUNARLAKE_M 0xBD +#define INTEL_LUNARLAKE_M IFM(6, 0xBD) /* "Small Core" Processors (Atom/E-Core) */ #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview */ +#define INTEL_ATOM_BONNELL IFM(6, 0x1C) /* Diamondville, Pineview */ #define INTEL_FAM6_ATOM_BONNELL_MID 0x26 /* Silverthorne, Lincroft */ +#define INTEL_ATOM_BONNELL_MID IFM(6, 0x26) /* Silverthorne, Lincroft */ #define INTEL_FAM6_ATOM_SALTWELL 0x36 /* Cedarview */ +#define INTEL_ATOM_SALTWELL IFM(6, 0x36) /* Cedarview */ #define INTEL_FAM6_ATOM_SALTWELL_MID 0x27 /* Penwell */ +#define INTEL_ATOM_SALTWELL_MID IFM(6, 0x27) /* Penwell */ #define INTEL_FAM6_ATOM_SALTWELL_TABLET 0x35 /* Cloverview */ +#define INTEL_ATOM_SALTWELL_TABLET IFM(6, 0x35) /* Cloverview */ #define INTEL_FAM6_ATOM_SILVERMONT 0x37 /* Bay Trail, Valleyview */ +#define INTEL_ATOM_SILVERMONT IFM(6, 0x37) /* Bay Trail, Valleyview */ #define INTEL_FAM6_ATOM_SILVERMONT_D 0x4D /* Avaton, Rangely */ +#define INTEL_ATOM_SILVERMONT_D IFM(6, 0x4D) /* Avaton, Rangely */ #define INTEL_FAM6_ATOM_SILVERMONT_MID 0x4A /* Merriefield */ +#define INTEL_ATOM_SILVERMONT_MID IFM(6, 0x4A) /* Merriefield */ #define INTEL_FAM6_ATOM_AIRMONT 0x4C /* Cherry Trail, Braswell */ +#define INTEL_ATOM_AIRMONT IFM(6, 0x4C) /* Cherry Trail, Braswell */ #define INTEL_FAM6_ATOM_AIRMONT_MID 0x5A /* Moorefield */ +#define INTEL_ATOM_AIRMONT_MID IFM(6, 0x5A) /* Moorefield */ #define INTEL_FAM6_ATOM_AIRMONT_NP 0x75 /* Lightning Mountain */ +#define INTEL_ATOM_AIRMONT_NP IFM(6, 0x75) /* Lightning Mountain */ #define INTEL_FAM6_ATOM_GOLDMONT 0x5C /* Apollo Lake */ +#define INTEL_ATOM_GOLDMONT IFM(6, 0x5C) /* Apollo Lake */ #define INTEL_FAM6_ATOM_GOLDMONT_D 0x5F /* Denverton */ +#define INTEL_ATOM_GOLDMONT_D IFM(6, 0x5F) /* Denverton */ /* Note: the micro-architecture is "Goldmont Plus" */ #define INTEL_FAM6_ATOM_GOLDMONT_PLUS 0x7A /* Gemini Lake */ +#define INTEL_ATOM_GOLDMONT_PLUS IFM(6, 0x7A) /* Gemini Lake */ #define INTEL_FAM6_ATOM_TREMONT_D 0x86 /* Jacobsville */ +#define INTEL_ATOM_TREMONT_D IFM(6, 0x86) /* Jacobsville */ #define INTEL_FAM6_ATOM_TREMONT 0x96 /* Elkhart Lake */ +#define INTEL_ATOM_TREMONT IFM(6, 0x96) /* Elkhart Lake */ #define INTEL_FAM6_ATOM_TREMONT_L 0x9C /* Jasper Lake */ +#define INTEL_ATOM_TREMONT_L IFM(6, 0x9C) /* Jasper Lake */ #define INTEL_FAM6_ATOM_GRACEMONT 0xBE /* Alderlake N */ +#define INTEL_ATOM_GRACEMONT IFM(6, 0xBE) /* Alderlake N */ #define INTEL_FAM6_ATOM_CRESTMONT_X 0xAF /* Sierra Forest */ +#define INTEL_ATOM_CRESTMONT_X IFM(6, 0xAF) /* Sierra Forest */ #define INTEL_FAM6_ATOM_CRESTMONT 0xB6 /* Grand Ridge */ +#define INTEL_ATOM_CRESTMONT IFM(6, 0xB6) /* Grand Ridge */ #define INTEL_FAM6_ATOM_DARKMONT_X 0xDD /* Clearwater Forest */ +#define INTEL_ATOM_DARKMONT_X IFM(6, 0xDD) /* Clearwater Forest */ /* Xeon Phi */ #define INTEL_FAM6_XEON_PHI_KNL 0x57 /* Knights Landing */ +#define INTEL_XEON_PHI_KNL IFM(6, 0x57) /* Knights Landing */ #define INTEL_FAM6_XEON_PHI_KNM 0x85 /* Knights Mill */ +#define INTEL_XEON_PHI_KNM IFM(6, 0x85) /* Knights Mill */ /* Family 5 */ #define INTEL_FAM5_QUARK_X1000 0x09 /* Quark X1000 SoC */ +#define INTEL_QUARK_X1000 IFM(5, 0x09) /* Quark X1000 SoC */ #endif /* _ASM_X86_INTEL_FAMILY_H */ diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c index ad6776081e60..2243083f0bc2 100644 --- a/arch/x86/kernel/cpu/match.c +++ b/arch/x86/kernel/cpu/match.c @@ -17,8 +17,7 @@ * * A typical table entry would be to match a specific CPU * - * X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, INTEL_FAM6_BROADWELL, - * X86_FEATURE_ANY, NULL); + * X86_MATCH_VFM_FEATURE(INTEL_BROADWELL, X86_FEATURE_ANY, NULL); * * Fields can be wildcarded with %X86_VENDOR_ANY, %X86_FAMILY_ANY, * %X86_MODEL_ANY, %X86_FEATURE_ANY (except for vendor) -- 2.44.0 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [PATCH 03/74] x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h 2024-03-28 16:37 ` [PATCH 03/74] x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h Tony Luck @ 2024-04-09 12:48 ` Thomas Gleixner 0 siblings, 0 replies; 33+ messages in thread From: Thomas Gleixner @ 2024-04-09 12:48 UTC (permalink / raw) To: Tony Luck, x86; +Cc: linux-kernel, Tony Luck On Thu, Mar 28 2024 at 09:37, Tony Luck wrote: > New CPU #defines encode vendor and family as well as model. > > Update the example usage comment in arch/x86/kernel/cpu/match.c > > Signed-off-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> ^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH 00/74] New Intel CPUID families
@ 2024-03-28 16:26 Tony Luck
2024-03-28 16:26 ` [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 Tony Luck
0 siblings, 1 reply; 33+ messages in thread
From: Tony Luck @ 2024-03-28 16:26 UTC (permalink / raw)
To: patches; +Cc: Tony Luck
Q1: Where are all the other parts of this series. I only got 1-3.
A1: There are ~2700 subscribers to LKML. I want to get some feedback
on the approach and naming etc. before spamming everyone with a 74
patch series.
Q2: Can I get the other parts?
A2: Sure. I posted them to patches@lists.linux.dev so you can get them
with:
$ b4 am 20240328090459.242500-tony.luck@intel.com
or get from kernel.org with:
$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git new_families
Q3: When are CPUs using new families coming?
A3: Soon-ish. We have some time to get the infrastructure right.
Intel has been using family 6 almost exclusively for many
years. As a result, Linux has built up infrastructure like
X86_MATCH_INTEL_FAM6_MODEL() to make it easy for model specific code to
use the #defines for each Intel CPU model.
But the reign of family 6 is about to end. Intel will begin using non-zero
values for the extended family field in CPUID(1).EAX. The minimal patch
size approach to handle these would be to clone the FAM6 macros. But
that will get messy as these prolifrate. This approach does not have an
elegant solution if a switch() statement needs to choose between CPUs
from different families.
Dave Hansen suggested that a more general cleanup that provides
CPU #defines that encode all of <vendor, family, model> would make
existing code better, and provide infrastructure that makes it trivial
to incorporate new families.
Big picture view is that code like this:
if (c->x86_vendor == X86_VENDOR_INTEL && c->x86 == 6 && c->x86_model == INTEL_FAM6_ICELAKE_X)
can become:
if (c->x86_vfm == INTEL_ICELAKE_X)
which is:
a) Simpler
b) Faster
c) More resilient (can't forget to check vendor & family along with model)
d) Code style doesn't change for every new family.
Note that "struct cpuinfo_x86" gains a new xf6_vfm field and the ICELAKE
#define loses the "FAM6_" substring and will be initialized with a macro
that does the bit shuffling to fit X86_VENDOR_INTEL and a family and
model into a "u32":
#define INTEL_ICELAKE_X IFM(6, 0x6A) /* Sunny Cove */
New CPUs in other families might look like:
#define INTEL_DOUGLASCOVE IFM(42, 0x01) /* Adams Lake */
#define INTEL_SHELDONMONT IFM(73, 0x01) /* Cooper Forest */
Model specific "if" statements then follow the same pattern
regardless of family:
if (c->x86_vfm == INTEL_DOUGLASCOVE || c->x86_vfm == INTEL_SHELDONMONT) {
}
If needed these could even appear in the same switch statement:
switch (c->x86_vfm) {
case INTEL_ICELAKE_X:
...
case INTEL_DOUGLASCOVE:
...
case INTEL_SHELDONMONT:
...
}
The existing X86_MATCH_INTEL_FAM6_MODEL() can be replaced with a new
X86_MATCH_VFM() macro.
Update can happen in three phases:
1) Add infrastructure macros, new "x86_vfm" field, new CPU #defines
2) Treewide update from old to new (around 70 files at current count)
3) Delete the old INTEL_FAM6 and X86_MATCH_INTEL_FAM6 macros
Tony Luck (74):
x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86
x86/cpu/vfm: Add new macros to work with (vendor/family/model) values
x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h
x86/cpu/vfm: Update arch/x86/crypto/poly1305_glue.c
x86/cpu/vfm: Update arch/x86/crypto/twofish_glue_3way.c
x86/cpu/vfm: Update arch/x86/events/intel/cstate.c
x86/cpu/vfm: Update arch/x86/events/intel/lbr.c
x86/cpu/vfm: Update arch/x86/events/intel/pt.c
x86/cpu/vfm: Update arch/x86/events/intel/uncore.c
x86/cpu/vfm: Update arch/x86/events/intel/uncore_nhmex.c
x86/cpu/vfm: Update arch/x86/events/intel/uncore_snbep.c
x86/cpu/vfm: Update arch/x86/events/msr.c
x86/cpu/vfm: Update arch/x86/events/rapl.c
x86/cpu/vfm: Update arch/x86/kernel/apic/apic.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/aperfmperf.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/bugs.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/common.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/intel.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/intel_epb.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/match.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/core.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/intel.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/mce/severity.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/microcode/intel.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/resctrl/core.c
x86/cpu/vfm: Update arch/x86/kernel/cpu/resctrl/pseudo_lock.c
x86/cpu/vfm: Update arch/x86/kernel/smpboot.c
x86/cpu/vfm: Update arch/x86/kernel/tsc.c
x86/cpu/vfm: Update arch/x86/kernel/tsc_msr.c
x86/cpu/vfm: Update arch/x86/kvm/pmu.c
x86/cpu/vfm: Update arch/x86/kvm/vmx/vmx.c
x86/cpu/vfm: Update arch/x86/mm/init.c
x86/cpu/vfm: Update arch/x86/pci/intel_mid_pci.c
x86/cpu/vfm: Update arch/x86/virt/vmx/tdx/tdx.c
x86/cpu/vfm: Update drivers/acpi/acpi_lpss.c
x86/cpu/vfm: Update drivers/acpi/x86/utils.c
x86/cpu/vfm: Update tpm files
x86/cpu/vfm: Update drivers/cpufreq/intel_pstate.c
x86/cpu/vfm: Update drivers/cpufreq/speedstep-centrino.c
x86/cpu/vfm: Update drivers/edac/i10nm_base.c
x86/cpu/vfm: Update drivers/edac/pnd2_edac.c
x86/cpu/vfm: Update drivers/edac/sb_edac.c
x86/cpu/vfm: Update drivers/edac/skx_base.c
x86/cpu/vfm: Update drivers/extcon/extcon-axp288.c
x86/cpu/vfm: Update drivers/hwmon/peci/cputemp.c
x86/cpu/vfm: Update drivers/idle/intel_idle.c
x86/cpu/vfm: Update drivers/pci/pci-mid.c
x86/cpu/vfm: Update drivers/peci/cpu.c
x86/cpu/vfm: Update drivers/platform/x86/intel/ifs/core.c
x86/cpu/vfm: Update drivers/platform/x86/intel_ips.c
x86/cpu/vfm: Update drivers/platform/x86/intel/pmc/core.c
x86/cpu/vfm: Update drivers/platform/x86/intel/pmc/pltdrv.c
x86/cpu/vfm: Update drivers/platform/x86/intel_scu_wdt.c
x86/cpu/vfm: Update
drivers/platform/x86/intel/speed_select_if/isst_if_common.c
x86/cpu/vfm: Update
drivers/platform/x86/intel/speed_select_if/isst_if_mbox_msr.c
x86/cpu/vfm: Update drivers/platform/x86/intel/telemetry/debugfs.c
x86/cpu/vfm: Update drivers/platform/x86/intel/telemetry/pltdrv.c
x86/cpu/vfm: Update drivers/platform/x86/intel/turbo_max_3.c
x86/cpu/vfm: Update
drivers/platform/x86/intel/uncore-frequency/uncore-frequency.c
x86/cpu/vfm: Update drivers/platform/x86/p2sb.c
x86/cpu/vfm: Update drivers/powercap/intel_rapl_common.c
x86/cpu/vfm: Update drivers/powercap/intel_rapl_msr.c
x86/cpu/vfm: Update
drivers/staging/media/atomisp/include/linux/atomisp_platform.h
x86/cpu/vfm: Update intel_soc_dts_thermal.c
x86/cpu/vfm: Update drivers/thermal/intel/intel_tcc_cooling.c
x86/cpu/vfm: Update sound/soc/intel/avs/boards/es8336.c
x86/cpu/vfm: Update arch/x86/events/intel/core.c
x86/cpu/vfm: Update arch/x86/platform/intel-mid/intel-mid.c
x86/cpu/vfm: Update arch/x86/platform/atom/punit_atom_debug.c
x86/cpu/vfm: Update arch/x86/events/intel/core.c
x86/cpu/vfm: Update tools/power/x86/turbostat/turbostat.c
x86/cpu/vfm: Update arch/x86/boot/cpucheck.c
x86/cpu/vfm: Delete X86_MATCH_INTEL_FAM6_MODEL[_STEPPING]() macros
x86/cpu/vfm: Delete all the *_FAM6_ CPU #defines
.../atomisp/include/linux/atomisp_platform.h | 26 +--
include/linux/peci-cpu.h | 1 +
include/linux/platform_data/x86/soc.h | 12 +-
arch/x86/include/asm/cpu_device_id.h | 103 +++++++--
arch/x86/include/asm/intel-family.h | 167 +++++++-------
arch/x86/include/asm/processor.h | 12 +-
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm_tis_core.h | 2 +-
arch/x86/boot/cpucheck.c | 2 +-
arch/x86/crypto/poly1305_glue.c | 3 +-
arch/x86/crypto/twofish_glue_3way.c | 10 +-
arch/x86/events/intel/core.c | 212 +++++++++---------
arch/x86/events/intel/cstate.c | 144 ++++++------
arch/x86/events/intel/lbr.c | 3 +-
arch/x86/events/intel/pt.c | 11 +-
arch/x86/events/intel/uncore.c | 100 ++++-----
arch/x86/events/intel/uncore_nhmex.c | 3 +-
arch/x86/events/intel/uncore_snbep.c | 5 +-
arch/x86/events/msr.c | 131 +++++------
arch/x86/events/rapl.c | 84 +++----
arch/x86/kernel/apic/apic.c | 38 ++--
arch/x86/kernel/cpu/aperfmperf.c | 17 +-
arch/x86/kernel/cpu/bugs.c | 29 +--
arch/x86/kernel/cpu/common.c | 154 +++++++------
arch/x86/kernel/cpu/intel.c | 115 +++++-----
arch/x86/kernel/cpu/intel_epb.c | 12 +-
arch/x86/kernel/cpu/match.c | 5 +-
arch/x86/kernel/cpu/mce/core.c | 5 +-
arch/x86/kernel/cpu/mce/intel.c | 20 +-
arch/x86/kernel/cpu/mce/severity.c | 9 +-
arch/x86/kernel/cpu/microcode/intel.c | 4 +-
arch/x86/kernel/cpu/resctrl/core.c | 9 +-
arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 21 +-
arch/x86/kernel/smpboot.c | 6 +-
arch/x86/kernel/tsc.c | 5 +-
arch/x86/kernel/tsc_msr.c | 14 +-
arch/x86/kvm/pmu.c | 8 +-
arch/x86/kvm/vmx/vmx.c | 20 +-
arch/x86/mm/init.c | 16 +-
arch/x86/pci/intel_mid_pci.c | 4 +-
arch/x86/platform/atom/punit_atom_debug.c | 11 +-
arch/x86/platform/intel-mid/intel-mid.c | 7 +-
arch/x86/virt/vmx/tdx/tdx.c | 7 +-
drivers/acpi/acpi_lpss.c | 4 +-
drivers/acpi/x86/utils.c | 42 ++--
drivers/cpufreq/intel_pstate.c | 90 ++++----
drivers/cpufreq/speedstep-centrino.c | 8 +-
drivers/edac/i10nm_base.c | 20 +-
drivers/edac/pnd2_edac.c | 4 +-
drivers/edac/sb_edac.c | 14 +-
drivers/edac/skx_base.c | 2 +-
drivers/extcon/extcon-axp288.c | 2 +-
drivers/hwmon/peci/cputemp.c | 7 +-
drivers/idle/intel_idle.c | 116 +++++-----
drivers/pci/pci-mid.c | 4 +-
drivers/peci/cpu.c | 28 +--
drivers/platform/x86/intel/ifs/core.c | 15 +-
drivers/platform/x86/intel/pmc/core.c | 46 ++--
drivers/platform/x86/intel/pmc/pltdrv.c | 16 +-
.../intel/speed_select_if/isst_if_common.c | 4 +-
.../intel/speed_select_if/isst_if_mbox_msr.c | 2 +-
.../platform/x86/intel/telemetry/debugfs.c | 4 +-
drivers/platform/x86/intel/telemetry/pltdrv.c | 4 +-
drivers/platform/x86/intel/turbo_max_3.c | 4 +-
.../intel/uncore-frequency/uncore-frequency.c | 56 ++---
drivers/platform/x86/intel_ips.c | 3 +-
drivers/platform/x86/intel_scu_wdt.c | 2 +-
drivers/platform/x86/p2sb.c | 2 +-
drivers/powercap/intel_rapl_common.c | 118 +++++-----
drivers/powercap/intel_rapl_msr.c | 16 +-
drivers/thermal/intel/intel_soc_dts_thermal.c | 2 +-
drivers/thermal/intel/intel_tcc_cooling.c | 30 +--
sound/soc/intel/avs/boards/es8336.c | 7 +-
tools/power/x86/turbostat/turbostat.c | 161 +++++++------
74 files changed, 1258 insertions(+), 1143 deletions(-)
base-commit: 4cece764965020c22cff7665b18a012006359095
--
2.44.0
^ permalink raw reply [flat|nested] 33+ messages in thread* [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 2024-03-28 16:26 [PATCH 00/74] New Intel CPUID families Tony Luck @ 2024-03-28 16:26 ` Tony Luck 0 siblings, 0 replies; 33+ messages in thread From: Tony Luck @ 2024-03-28 16:26 UTC (permalink / raw) To: patches; +Cc: Tony Luck Refactor struct cpuinfo_x86 so that the vendor, family, and model fields are overlayed in a union with a 32-bit field that combines all three (together with a one byte reserved field in the upper byte). This will make it easy, cheap, and reliable to check all three values at once. Signed-off-by: Tony Luck <tony.luck@intel.com> --- arch/x86/include/asm/processor.h | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 811548f131f4..87115e5d884f 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -108,9 +108,15 @@ struct cpuinfo_topology { }; struct cpuinfo_x86 { - __u8 x86; /* CPU family */ - __u8 x86_vendor; /* CPU vendor */ - __u8 x86_model; + union { + struct { + __u8 x86_vendor; /* CPU vendor */ + __u8 x86; /* CPU family */ + __u8 x86_model; + __u8 x86_reserved; + }; + __u32 x86_vfm; /* combined vendor, family, model */ + }; __u8 x86_stepping; #ifdef CONFIG_X86_64 /* Number of 4K pages in DTLB/ITLB combined(in pages): */ -- 2.44.0 ^ permalink raw reply related [flat|nested] 33+ messages in thread
end of thread, other threads:[~2024-04-18 1:47 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-03-28 16:37 [PATCH 00/74] New Intel CPUID families Tony Luck 2024-03-28 16:37 ` [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 Tony Luck 2024-03-28 16:48 ` Borislav Petkov 2024-03-28 16:52 ` Borislav Petkov 2024-03-28 17:00 ` Luck, Tony 2024-03-28 17:12 ` Borislav Petkov 2024-03-28 18:32 ` Luck, Tony 2024-03-28 20:52 ` Luck, Tony 2024-03-29 11:40 ` Borislav Petkov 2024-03-29 16:46 ` Tony Luck 2024-03-29 17:23 ` Borislav Petkov 2024-04-01 18:18 ` Tony Luck 2024-04-07 10:54 ` Borislav Petkov 2024-04-08 16:20 ` Luck, Tony 2024-04-09 8:22 ` Borislav Petkov 2024-04-16 18:16 ` Tony Luck 2024-04-16 18:23 ` Borislav Petkov 2024-04-16 18:37 ` Luck, Tony 2024-04-16 19:58 ` Borislav Petkov 2024-04-16 21:45 ` Luck, Tony 2024-04-17 19:02 ` Sean Christopherson 2024-04-17 19:42 ` Borislav Petkov 2024-04-18 1:47 ` Luck, Tony 2024-03-28 16:56 ` Luck, Tony 2024-03-28 17:06 ` Borislav Petkov 2024-04-01 18:23 ` [PATCH v2 " Tony Luck 2024-04-09 12:46 ` Thomas Gleixner 2024-03-28 16:37 ` [PATCH 02/74] x86/cpu/vfm: Add new macros to work with (vendor/family/model) values Tony Luck 2024-04-01 18:24 ` [PATCH v2 " Tony Luck 2024-04-09 12:47 ` Thomas Gleixner 2024-03-28 16:37 ` [PATCH 03/74] x86/cpu/vfm: Update arch/x86/include/asm/intel-family.h Tony Luck 2024-04-09 12:48 ` Thomas Gleixner -- strict thread matches above, loose matches on Subject: below -- 2024-03-28 16:26 [PATCH 00/74] New Intel CPUID families Tony Luck 2024-03-28 16:26 ` [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to struct cpuinfo_x86 Tony Luck
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.