RE: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
> sed -i -e 's/\(INTEL_FAM6_.*\)_MOBILE/\1_ULT/g' ${i}
I think it would be better to change the one _ULT to _MOBILE, rather than
all the _MOBILE to _ULT
-Tony
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, Aug 15, 2019 at 10:22:07PM +0200, Thomas Gleixner wrote: > We have the following existing _SHORT variants: > > _G > _EP > _EX > _CORE > _ULT > _GT3E > _XEON_D > _MOBILE > _DESKTOP > _NNPI > _MID > _TABLET > _PLUS Your list is missing: _L and _X. _X is the generic 'server' And we have only MEROM_L, which, afaict, is a mobile variant of MEROM. Now, I just send out patches doing s/_MOBILE/_ULT/, so I suppose this then should be MEROM_ULT. Or we go the other way and do: s/_ULT/_MOBILE/, in which case this becomes: MEROM_MOBILE. No strong feelings either way.
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Tue, Aug 20, 2019 at 05:40:11PM +0200, Peter Zijlstra wrote:
> > _ULT
> > _MOBILE
>
> I suspect these two are the same.
for i in `git grep -l "INTEL_FAM6_.*_MOBILE"`
do
sed -i -e 's/\(INTEL_FAM6_.*\)_MOBILE/\1_ULT/g' ${i}
done
---
arch/x86/events/intel/core.c | 16 +++
arch/x86/events/intel/cstate.c| 14 ++---
arch/x86/events/intel/rapl.c | 8
arch/x86/events/intel/uncore.c| 6 +++---
arch/x86/events/msr.c | 6 +++---
arch/x86/include/asm/intel-family.h | 8
arch/x86/kernel/apic/apic.c | 4 ++--
arch/x86/kernel/cpu/bugs.c| 4 ++--
arch/x86/kernel/cpu/intel.c | 4 ++--
drivers/cpufreq/intel_pstate.c| 2 +-
tools/power/x86/turbostat/turbostat.c | 38 +--
11 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 76bff3a33725..a0945aa897d6 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3978,13 +3978,13 @@ static const struct x86_cpu_desc isolation_ucodes[] = {
INTEL_CPU_DESC(INTEL_FAM6_BROADWELL_X, 2, 0x0b14),
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 3, 0x0021),
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 4, 0x),
- INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_MOBILE,3, 0x007c),
+ INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_ULT, 3, 0x007c),
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE, 3, 0x007c),
INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 9, 0x004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 9, 0x004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 10, 0x004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 11, 0x004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 12, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_ULT, 9, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_ULT, 10, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_ULT, 11, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_ULT, 12, 0x004e),
INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 10, 0x004e),
INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 11, 0x004e),
INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 12, 0x004e),
@@ -4955,9 +4955,9 @@ __init int intel_pmu_init(void)
case INTEL_FAM6_SKYLAKE_X:
pmem = true;
/* fall through */
- case INTEL_FAM6_SKYLAKE_MOBILE:
+ case INTEL_FAM6_SKYLAKE_ULT:
case INTEL_FAM6_SKYLAKE:
- case INTEL_FAM6_KABYLAKE_MOBILE:
+ case INTEL_FAM6_KABYLAKE_ULT:
case INTEL_FAM6_KABYLAKE:
x86_add_quirk(intel_pebs_isolation_quirk);
x86_pmu.late_ack = true;
@@ -5005,7 +5005,7 @@ __init int intel_pmu_init(void)
case INTEL_FAM6_ICELAKE_XEON_D:
pmem = true;
/* fall through */
- case INTEL_FAM6_ICELAKE_MOBILE:
+ case INTEL_FAM6_ICELAKE_ULT:
case INTEL_FAM6_ICELAKE:
x86_pmu.late_ack = true;
memcpy(hw_cache_event_ids, skl_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
index 3854400ad8ff..39c48a0dc6dc 100644
--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -608,14 +608,14 @@ static const struct x86_cpu_id intel_cstates_match[]
__initconst = {
X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_GT3E, snb_cstates),
X86_CSTATES_MODEL(INTEL_FAM6_BROADWELL_X, snb_cstates),
- X86_CSTATES_MODEL(INTEL_FAM6_SKYLAKE_MOBILE, snb_cstates),
- X86_CSTATES_MODEL(INTEL_FAM6_SKYLAKE,snb_cstates),
- X86_CSTATES_MODEL(INTEL_FAM6_SKYLAKE_X, snb_cstates),
+ X86_CSTATES_MODEL(INTEL_FAM6_SKYLAKE_ULT, snb_cstates),
+ X86_CSTATES_MODEL(INTEL_FAM6_SKYLAKE, snb_cstates),
+ X86_CSTATES_MODEL(INTEL_FAM6_SKYLAKE_X, snb_cstates),
- X86_CSTATES_MODEL(INTEL_FAM6_KABYLAKE_MOBILE, hswult_cstates),
+ X86_CSTATES_MODEL(INTEL_FAM6_KABYLAKE_ULT, hswult_cstates),
X86_CSTATES_MODEL(INTEL_FAM6_KABYLAKE,hswult_cstates),
- X86_CSTATES_MODEL(INTEL_FAM6_CANNONLAKE_MOBILE, cnl_cstates),
+ X86_CSTATES_MODEL(INTEL_FAM6_CANNONLAKE_ULT, cnl_cstates),
X86_CSTATES_MODEL(INTEL_FAM6_XEON_PHI_KNL, knl_cstates),
X86_CSTATES_MODEL(INTEL_FAM6_XEON_PHI_KNM, knl_cstates),
@@ -625,8 +625,8 @@ static const struct x86_cpu_id intel_cstates_match[]
__initconst = {
X86_CSTATES_MODEL(INTEL_FAM6_ATOM_GOLDMONT_PLUS, glm_cstates),
- X86_CSTATES_MODEL(INTEL_FAM6_ICELAKE_MOBILE, snb_cstates),
- X86_CSTATES_MODEL(INTEL_FAM6_ICELAKE,snb_cstates),
+
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Tue, Aug 20, 2019 at 05:40:11PM +0200, Peter Zijlstra wrote:
> > _CORE
> > _DESKTOP
>
> These two and no _SHORT should/could be collated, I think.
for i in `git grep -l "INTEL_FAM6_.*_\(CORE\|DESKTOP\)"`
do
sed -i -e 's/\(INTEL_FAM6_.*\)_\(CORE\|DESKTOP\)/\1/g' ${i}
done
---
arch/x86/events/intel/core.c | 26 +-
arch/x86/events/intel/cstate.c| 22 +++---
arch/x86/events/intel/pt.c| 2 +-
arch/x86/events/intel/rapl.c | 10 +-
arch/x86/events/intel/uncore.c| 12 ++--
arch/x86/events/msr.c | 8
arch/x86/include/asm/intel-family.h | 10 +-
arch/x86/kernel/apic/apic.c | 8
arch/x86/kernel/cpu/bugs.c| 8
arch/x86/kernel/cpu/intel.c | 10 +-
drivers/cpufreq/intel_pstate.c| 12 ++--
drivers/idle/intel_idle.c | 2 +-
tools/power/x86/turbostat/turbostat.c | 28 ++--
13 files changed, 79 insertions(+), 79 deletions(-)
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 648260b5f367..76bff3a33725 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3964,12 +3964,12 @@ static __init void intel_clovertown_quirk(void)
}
static const struct x86_cpu_desc isolation_ucodes[] = {
- INTEL_CPU_DESC(INTEL_FAM6_HASWELL_CORE, 3, 0x001f),
+ INTEL_CPU_DESC(INTEL_FAM6_HASWELL, 3, 0x001f),
INTEL_CPU_DESC(INTEL_FAM6_HASWELL_ULT, 1, 0x001e),
INTEL_CPU_DESC(INTEL_FAM6_HASWELL_GT3E, 1, 0x0015),
INTEL_CPU_DESC(INTEL_FAM6_HASWELL_X, 2, 0x0037),
INTEL_CPU_DESC(INTEL_FAM6_HASWELL_X, 4, 0x000a),
- INTEL_CPU_DESC(INTEL_FAM6_BROADWELL_CORE,4, 0x0023),
+ INTEL_CPU_DESC(INTEL_FAM6_BROADWELL, 4, 0x0023),
INTEL_CPU_DESC(INTEL_FAM6_BROADWELL_GT3E,1, 0x0014),
INTEL_CPU_DESC(INTEL_FAM6_BROADWELL_XEON_D, 2, 0x0010),
INTEL_CPU_DESC(INTEL_FAM6_BROADWELL_XEON_D, 3, 0x0709),
@@ -3979,16 +3979,16 @@ static const struct x86_cpu_desc isolation_ucodes[] = {
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 3, 0x0021),
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 4, 0x),
INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_MOBILE,3, 0x007c),
- INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_DESKTOP, 3, 0x007c),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_DESKTOP, 9, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE, 3, 0x007c),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 9, 0x004e),
INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 9, 0x004e),
INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 10, 0x004e),
INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 11, 0x004e),
INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_MOBILE, 12, 0x004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_DESKTOP, 10, 0x004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_DESKTOP, 11, 0x004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_DESKTOP, 12, 0x004e),
- INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE_DESKTOP, 13, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 10, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 11, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 12, 0x004e),
+ INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 13, 0x004e),
{}
};
@@ -4857,7 +4857,7 @@ __init int intel_pmu_init(void)
break;
- case INTEL_FAM6_HASWELL_CORE:
+ case INTEL_FAM6_HASWELL:
case INTEL_FAM6_HASWELL_X:
case INTEL_FAM6_HASWELL_ULT:
case INTEL_FAM6_HASWELL_GT3E:
@@ -4890,7 +4890,7 @@ __init int intel_pmu_init(void)
name = "haswell";
break;
- case INTEL_FAM6_BROADWELL_CORE:
+ case INTEL_FAM6_BROADWELL:
case INTEL_FAM6_BROADWELL_XEON_D:
case INTEL_FAM6_BROADWELL_GT3E:
case INTEL_FAM6_BROADWELL_X:
@@ -4956,9 +4956,9 @@ __init int intel_pmu_init(void)
pmem = true;
/* fall through */
case INTEL_FAM6_SKYLAKE_MOBILE:
- case INTEL_FAM6_SKYLAKE_DESKTOP:
+ case INTEL_FAM6_SKYLAKE:
case INTEL_FAM6_KABYLAKE_MOBILE:
- case INTEL_FAM6_KABYLAKE_DESKTOP:
+ case INTEL_FAM6_KABYLAKE:
x86_add_quirk(intel_pebs_isolation_quirk);
x86_pmu.late_ack = true;
memcpy(hw_cache_event_ids, skl_hw_cache_event_ids,
sizeof(hw_cache_event_ids));
@@ -5006,7 +5006,7 @@ __init int intel_pmu_init(void)
pmem = true;
/* fall through */
case INTEL_FAM6_ICELAKE_MOBILE:
- case
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, Aug 15, 2019 at 10:22:07PM +0200, Thomas Gleixner wrote: > We have the following existing _SHORT variants: > _G > _GT3E Those two are special SOCs due to 'extra graphics bits on', and I suppose we could collate them. That said; I'm not sure NHM_G ever shipped, I'm looking at a wikipedia page that says both Auburndale and Havendale got scrapped. > _EP > _EX Both are historical, intel is no longer making that distinction and current chips will have _X. > _CORE > _DESKTOP These two and no _SHORT should/could be collated, I think. > _ULT > _MOBILE I suspect these two are the same. > _XEON_D Bit unfortunate that; we use _XEON_D for big microservers and ATOM_*_X for small microservers. So there's room for improvement here by unifying this. > _MID That one lived for 4 atom generations, but afaict it's no longer alive. > _NNPI > _TABLET These are so far one offs, not sure about the future. > _PLUS Like said in the other email, that one is not actually a _SHORT at all, but rather the uarch is 'Goldmont Plus'
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, Aug 15, 2019 at 10:22:07PM +0200, Thomas Gleixner wrote: > On Thu, 15 Aug 2019, Luck, Tony wrote: > > On Thu, Aug 15, 2019 at 07:54:55PM +0200, Borislav Petkov wrote: > > @@ -11,6 +11,21 @@ > > * While adding a new CPUID for a new microarchitecture, add a new > > * group to keep logically sorted out in chronological order. Within > > * that group keep the CPUID for the variants sorted by model number. > > + * > > + * HOWTO Build an INTEL_FAM6_ definition: > > + * > > + * 1. Start with INTEL_FAM6_ > > + * 2. If not Core-family, add a note about it, like "ATOM". There are only > > + *two options for this (Xeon Phi and Atom). It is exceedingly unlikely > > + *that you are adding a cpu which needs a new option here. > > + * 3. Add the processor microarchitecture, not the platform name > > + * 4. Add a short differentiator if necessary. Add an _X to differentiate > > + *Server from Client. > > We have the following existing _SHORT variants: > _PLUS That one isn't actually a _SHORT, the uarch is called 'Goldmont Plus'.
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Fri, Aug 16, 2019 at 04:29:19PM +, Luck, Tony wrote:
> >> + * The defined symbol names have the following form:
> >> + *INTEL_FAM6{OPTFAMILY}_{MICROARCH}{OPTDIFF}
> >
> > I think you want to have the underscores in the template:
> >
> > INTEL_FAM6_{OPTFAMILY}_{MICROARCH}_{OPTDIFF}
> >
> > but no need to resend if this is the only issue - I'll fix it up when
> > applying.
>
> I started there, but then had to include a sentence saying to skip the "_"
> if you didn't include either/both of the optional fields.
Ok, I see, that's why you call it "_CORE" - with a prepended underscore
- which should be omitted, for example. Ok, I'll take it and we can
always fix it up if it ain't clear.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
RE: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
From: Luck, Tony
> Sent: 16 August 2019 17:29
> >> + * The defined symbol names have the following form:
> >> + *INTEL_FAM6{OPTFAMILY}_{MICROARCH}{OPTDIFF}
> >
> > I think you want to have the underscores in the template:
> >
> > INTEL_FAM6_{OPTFAMILY}_{MICROARCH}_{OPTDIFF}
> >
> > but no need to resend if this is the only issue - I'll fix it up when
> > applying.
>
> I started there, but then had to include a sentence saying to skip the "_"
> if you didn't include either/both of the optional fields.
Might get difficult working out whether INTER_FAM6_FOO_BAR has an
OPTFAMILY of FOO and MICROARCH of BAR, or MICROARCH of FOO and
OPTDIFF of BAR.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
RE: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
>> + * The defined symbol names have the following form:
>> + * INTEL_FAM6{OPTFAMILY}_{MICROARCH}{OPTDIFF}
>
> I think you want to have the underscores in the template:
>
> INTEL_FAM6_{OPTFAMILY}_{MICROARCH}_{OPTDIFF}
>
> but no need to resend if this is the only issue - I'll fix it up when
> applying.
I started there, but then had to include a sentence saying to skip the "_"
if you didn't include either/both of the optional fields.
-Tony
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, 15 Aug 2019, Luck, Tony wrote:
> >From 093bf8cd02f4c7a3fa256c2cf7302014190e2840 Mon Sep 17 00:00:00 2001
> From: Tony Luck
> Date: Thu, 15 Aug 2019 11:16:24 -0700
> Subject: [PATCH] x86/cpu: Explain Intel model naming convention
>
> Dave Hansen spelled out the rules in an e-mail:
>
> https://lkml.kernel.org/r/91eefbe4-e32b-d762-be4d-672ff915d...@intel.com
>
> Copy those right into the file to
> make it easy for people to find them.
>
> Suggested-by: Borislav Petkov
> Signed-off-by: Tony Luck
> ---
> arch/x86/include/asm/intel-family.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/x86/include/asm/intel-family.h
> b/arch/x86/include/asm/intel-family.h
> index 0278aa66ef62..fe7c205233f1 100644
> --- a/arch/x86/include/asm/intel-family.h
> +++ b/arch/x86/include/asm/intel-family.h
> @@ -11,6 +11,21 @@
> * While adding a new CPUID for a new microarchitecture, add a new
> * group to keep logically sorted out in chronological order. Within
> * that group keep the CPUID for the variants sorted by model number.
> + *
> + * The defined symbol names have the following form:
> + * INTEL_FAM6{OPTFAMILY}_{MICROARCH}{OPTDIFF}
> + * where:
> + * OPTFAMILY Describes the family of CPUs that this belongs to. Default
> + * is assumed to be "_CORE" (and should be omitted). Other values
> + * currently in use are _ATOM and _XEON_PHI
> + * MICROARCH Is the code name for the micro-architecture for this core.
> + * N.B. Not the platform name.
> + * OPTDIFF If needed, a short string to differentiate by market segment.
> + * Exact strings here will vary over time. _DESKTOP, _MOBILE, and
> + * _X (short for Xeon server) should be used when they are
> + * appropriate.
> + *
> + * The #define line may optionally include a comment including platform
> names.
> */
Acked-by: Thomas Gleixner
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, Aug 15, 2019 at 03:47:05PM -0700, Luck, Tony wrote:
> On Thu, Aug 15, 2019 at 10:22:07PM +0200, Thomas Gleixner wrote:
> > On Thu, 15 Aug 2019, Luck, Tony wrote:
> > > On Thu, Aug 15, 2019 at 07:54:55PM +0200, Borislav Petkov wrote:
> > So we should document the list of valid and usable ones and either fixup
> > broken ones or document that they are historic ballast and not to be used
> > for new ones. Otherwise you end up with the same discussions again.
>
> This version is a lot more specific (but still allows future
> flexibility). I see a world of bike-shedding if I try to come
> up with a naming scheme to fix previous questionable naming
> choices ... I'm not going to open that can of worms.
>
> -Tony
>
> From 093bf8cd02f4c7a3fa256c2cf7302014190e2840 Mon Sep 17 00:00:00 2001
> From: Tony Luck
> Date: Thu, 15 Aug 2019 11:16:24 -0700
> Subject: [PATCH] x86/cpu: Explain Intel model naming convention
>
> Dave Hansen spelled out the rules in an e-mail:
>
> https://lkml.kernel.org/r/91eefbe4-e32b-d762-be4d-672ff915d...@intel.com
>
> Copy those right into the file to
> make it easy for people to find them.
>
> Suggested-by: Borislav Petkov
> Signed-off-by: Tony Luck
> ---
> arch/x86/include/asm/intel-family.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/x86/include/asm/intel-family.h
> b/arch/x86/include/asm/intel-family.h
> index 0278aa66ef62..fe7c205233f1 100644
> --- a/arch/x86/include/asm/intel-family.h
> +++ b/arch/x86/include/asm/intel-family.h
> @@ -11,6 +11,21 @@
> * While adding a new CPUID for a new microarchitecture, add a new
> * group to keep logically sorted out in chronological order. Within
> * that group keep the CPUID for the variants sorted by model number.
> + *
> + * The defined symbol names have the following form:
> + * INTEL_FAM6{OPTFAMILY}_{MICROARCH}{OPTDIFF}
I think you want to have the underscores in the template:
INTEL_FAM6_{OPTFAMILY}_{MICROARCH}_{OPTDIFF}
but no need to resend if this is the only issue - I'll fix it up when
applying.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, Aug 15, 2019 at 10:22:07PM +0200, Thomas Gleixner wrote:
> On Thu, 15 Aug 2019, Luck, Tony wrote:
> > On Thu, Aug 15, 2019 at 07:54:55PM +0200, Borislav Petkov wrote:
> So we should document the list of valid and usable ones and either fixup
> broken ones or document that they are historic ballast and not to be used
> for new ones. Otherwise you end up with the same discussions again.
This version is a lot more specific (but still allows future
flexibility). I see a world of bike-shedding if I try to come
up with a naming scheme to fix previous questionable naming
choices ... I'm not going to open that can of worms.
-Tony
>From 093bf8cd02f4c7a3fa256c2cf7302014190e2840 Mon Sep 17 00:00:00 2001
From: Tony Luck
Date: Thu, 15 Aug 2019 11:16:24 -0700
Subject: [PATCH] x86/cpu: Explain Intel model naming convention
Dave Hansen spelled out the rules in an e-mail:
https://lkml.kernel.org/r/91eefbe4-e32b-d762-be4d-672ff915d...@intel.com
Copy those right into the file to
make it easy for people to find them.
Suggested-by: Borislav Petkov
Signed-off-by: Tony Luck
---
arch/x86/include/asm/intel-family.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/x86/include/asm/intel-family.h
b/arch/x86/include/asm/intel-family.h
index 0278aa66ef62..fe7c205233f1 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -11,6 +11,21 @@
* While adding a new CPUID for a new microarchitecture, add a new
* group to keep logically sorted out in chronological order. Within
* that group keep the CPUID for the variants sorted by model number.
+ *
+ * The defined symbol names have the following form:
+ * INTEL_FAM6{OPTFAMILY}_{MICROARCH}{OPTDIFF}
+ * where:
+ * OPTFAMILY Describes the family of CPUs that this belongs to. Default
+ * is assumed to be "_CORE" (and should be omitted). Other values
+ * currently in use are _ATOM and _XEON_PHI
+ * MICROARCH Is the code name for the micro-architecture for this core.
+ * N.B. Not the platform name.
+ * OPTDIFF If needed, a short string to differentiate by market segment.
+ * Exact strings here will vary over time. _DESKTOP, _MOBILE, and
+ * _X (short for Xeon server) should be used when they are
+ * appropriate.
+ *
+ * The #define line may optionally include a comment including platform names.
*/
#define INTEL_FAM6_CORE_YONAH 0x0E
--
2.20.1
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, 15 Aug 2019, Luck, Tony wrote: > On Thu, Aug 15, 2019 at 07:54:55PM +0200, Borislav Petkov wrote: > @@ -11,6 +11,21 @@ > * While adding a new CPUID for a new microarchitecture, add a new > * group to keep logically sorted out in chronological order. Within > * that group keep the CPUID for the variants sorted by model number. > + * > + * HOWTO Build an INTEL_FAM6_ definition: > + * > + * 1. Start with INTEL_FAM6_ > + * 2. If not Core-family, add a note about it, like "ATOM". There are only > + *two options for this (Xeon Phi and Atom). It is exceedingly unlikely > + *that you are adding a cpu which needs a new option here. > + * 3. Add the processor microarchitecture, not the platform name > + * 4. Add a short differentiator if necessary. Add an _X to differentiate > + *Server from Client. We have the following existing _SHORT variants: _G _EP _EX _CORE _ULT _GT3E _XEON_D _MOBILE _DESKTOP _NNPI _MID _TABLET _PLUS So we should document the list of valid and usable ones and either fixup broken ones or document that they are historic ballast and not to be used for new ones. Otherwise you end up with the same discussions again. Thanks, tglx
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, Aug 15, 2019 at 11:30:55AM -0700, Luck, Tony wrote: > On Thu, Aug 15, 2019 at 07:54:55PM +0200, Borislav Petkov wrote: > > On Thu, Aug 15, 2019 at 10:21:59AM -0700, Luck, Tony wrote: > > > Like this? > > > > Actually, I was thinking you'd put it above the defines in the file > > intel-family.h itself so that *everyone* who wants to add a model, sees > > it first and while that explanation below is very nice... > > V2 ... ugh ... C doesn't do well with nested comments, so the example > has issues. I chose to use a C++ style comment (as they are not as > verboten in Linux as they used to be). > > Another option would be to put the instructions inside #if 0 ... #endif > but that seems less than ideal. > > Any other ideas? > > -Tony > > From 84624a3410a3ba03c3acb13e54b1292c3ca64b8c Mon Sep 17 00:00:00 2001 > From: Tony Luck > Date: Thu, 15 Aug 2019 11:16:24 -0700 > Subject: [PATCH] x86/cpu: Explain Intel model naming convention > > Dave Hansen spelled out the rules in an e-mail: > > https://lkml.kernel.org/r/91eefbe4-e32b-d762-be4d-672ff915d...@intel.com > > Copy those right into the file to > make it easy for people to find them. > > Suggested-by: Borislav Petkov > Signed-off-by: Tony Luck > --- > arch/x86/include/asm/intel-family.h | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/x86/include/asm/intel-family.h > b/arch/x86/include/asm/intel-family.h > index 0278aa66ef62..87443df77eee 100644 > --- a/arch/x86/include/asm/intel-family.h > +++ b/arch/x86/include/asm/intel-family.h > @@ -11,6 +11,21 @@ > * While adding a new CPUID for a new microarchitecture, add a new > * group to keep logically sorted out in chronological order. Within > * that group keep the CPUID for the variants sorted by model number. > + * > + * HOWTO Build an INTEL_FAM6_ definition: > + * > + * 1. Start with INTEL_FAM6_ > + * 2. If not Core-family, add a note about it, like "ATOM". There are only > + *two options for this (Xeon Phi and Atom). It is exceedingly unlikely > + *that you are adding a cpu which needs a new option here. > + * 3. Add the processor microarchitecture, not the platform name > + * 4. Add a short differentiator if necessary. Add an _X to differentiate > + *Server from Client. > + * 5. Add an optional comment with the platform name(s) > + * > + * It should end up looking like this: > + * > + * INTEL_FAM6___ // Platform Name(s) > */ > > #define INTEL_FAM6_CORE_YONAH0x0E > -- Thanks, LGTM. Let's wait for the others to bikeshed a little before I take it. :-) -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, Aug 15, 2019 at 07:54:55PM +0200, Borislav Petkov wrote: > On Thu, Aug 15, 2019 at 10:21:59AM -0700, Luck, Tony wrote: > > Like this? > > Actually, I was thinking you'd put it above the defines in the file > intel-family.h itself so that *everyone* who wants to add a model, sees > it first and while that explanation below is very nice... V2 ... ugh ... C doesn't do well with nested comments, so the example has issues. I chose to use a C++ style comment (as they are not as verboten in Linux as they used to be). Another option would be to put the instructions inside #if 0 ... #endif but that seems less than ideal. Any other ideas? -Tony >From 84624a3410a3ba03c3acb13e54b1292c3ca64b8c Mon Sep 17 00:00:00 2001 From: Tony Luck Date: Thu, 15 Aug 2019 11:16:24 -0700 Subject: [PATCH] x86/cpu: Explain Intel model naming convention Dave Hansen spelled out the rules in an e-mail: https://lkml.kernel.org/r/91eefbe4-e32b-d762-be4d-672ff915d...@intel.com Copy those right into the file to make it easy for people to find them. Suggested-by: Borislav Petkov Signed-off-by: Tony Luck --- arch/x86/include/asm/intel-family.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index 0278aa66ef62..87443df77eee 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -11,6 +11,21 @@ * While adding a new CPUID for a new microarchitecture, add a new * group to keep logically sorted out in chronological order. Within * that group keep the CPUID for the variants sorted by model number. + * + * HOWTO Build an INTEL_FAM6_ definition: + * + * 1. Start with INTEL_FAM6_ + * 2. If not Core-family, add a note about it, like "ATOM". There are only + *two options for this (Xeon Phi and Atom). It is exceedingly unlikely + *that you are adding a cpu which needs a new option here. + * 3. Add the processor microarchitecture, not the platform name + * 4. Add a short differentiator if necessary. Add an _X to differentiate + *Server from Client. + * 5. Add an optional comment with the platform name(s) + * + * It should end up looking like this: + * + * INTEL_FAM6___ // Platform Name(s) */ #define INTEL_FAM6_CORE_YONAH 0x0E -- 2.20.1
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, Aug 15, 2019 at 10:21:59AM -0700, Luck, Tony wrote: > Like this? Actually, I was thinking you'd put it above the defines in the file intel-family.h itself so that *everyone* who wants to add a model, sees it first and while that explanation below is very nice... > +The CPU model number on a running system can be found by executing > +the CPUID(EAX=0) instruction to find the vendor, family, model > +and stepping. The model number is found by concatenating two bit > +fields from the EAX return value. Bits 19:16 (extended model number) > +and 7:4 (model number). > + > +Inside the Linux kernel the vendor, family, model and stepping are > +stored in the cpuinfo_x86 structure. Model specific code typically > +uses x86_match_cpu() to determine if it is running on any of some > +list of CPU models. > + > +There are several subsystems that need model specific handling on > +Intel CPUs. For code legibility it is better to assign names for > +the various model numbers in the include file > + > +Currently all interesting Intel CPU models are in family 6. .. we're probably going to need the text only from here on down: > + > +HOWTO Build an INTEL_FAM6_ definition: > + > +1. Start with INTEL_FAM6_ > +2. If not Core-family, add a note about it, like "ATOM". There are only > + two options for this (Xeon Phi and Atom). It is exceedingly unlikely > + that you are adding a cpu which needs a new option here. > +3. Add the processor microarchitecture, not the platform name > +4. Add a short differentiator if necessary. Add an _X to differentiate > + Server from Client. > +5. Add an optional comment with the platform name(s) > + > +It should end up looking like this: > + > +INTEL_FAM6___ /* Platform Name */ > -- Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Thu, Aug 15, 2019 at 09:58:22AM +0200, Borislav Petkov wrote: > On Wed, Aug 14, 2019 at 04:40:30PM -0700, Tony Luck wrote: > > There are a few different subsystems in the kernel that depend on > > model specific behaviour (perf, EDAC, power, ...). Easier for just > > one person to have the task to get new model numbers included instead > > of having these groups trip over each other to do it. > > > > Signed-off-by: Tony Luck > > --- > > MAINTAINERS | 6 ++ > > 1 file changed, 6 insertions(+) > > Applied, thanks. > > As a first order of business, pls sum up the naming scheme convention > you guys are going to adhere to so that it is clear to everybody: > > https://lkml.kernel.org/r/91eefbe4-e32b-d762-be4d-672ff915d...@intel.com > > in a patch form. :) Like this? >From 364e337ec2008442a8a77cf919fbf499b297b3f4 Mon Sep 17 00:00:00 2001 From: Tony Luck Date: Thu, 15 Aug 2019 10:04:18 -0700 Subject: [PATCH] Documentation: x86: Explain Intel model naming convention This was written in an e-mail by Dave Hansen, but not everybody reads the entire LKML archive before posting a patch. https://lkml.kernel.org/r/91eefbe4-e32b-d762-be4d-672ff915d...@intel.com Signed-off-by: Tony Luck --- Documentation/x86/index.rst| 1 + Documentation/x86/intel-cpu-models.rst | 37 ++ 2 files changed, 38 insertions(+) create mode 100644 Documentation/x86/intel-cpu-models.rst diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index af64c4bb4447..6ba9e9cc5938 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -19,6 +19,7 @@ x86-specific Documentation tlb mtrr pat + intel-cpu-models intel_mpx intel-iommu intel_txt diff --git a/Documentation/x86/intel-cpu-models.rst b/Documentation/x86/intel-cpu-models.rst new file mode 100644 index ..75b5267a5354 --- /dev/null +++ b/Documentation/x86/intel-cpu-models.rst @@ -0,0 +1,37 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Intel CPU model numbers +=== + +The CPU model number on a running system can be found by executing +the CPUID(EAX=0) instruction to find the vendor, family, model +and stepping. The model number is found by concatenating two bit +fields from the EAX return value. Bits 19:16 (extended model number) +and 7:4 (model number). + +Inside the Linux kernel the vendor, family, model and stepping are +stored in the cpuinfo_x86 structure. Model specific code typically +uses x86_match_cpu() to determine if it is running on any of some +list of CPU models. + +There are several subsystems that need model specific handling on +Intel CPUs. For code legibility it is better to assign names for +the various model numbers in the include file + +Currently all interesting Intel CPU models are in family 6. + +HOWTO Build an INTEL_FAM6_ definition: + +1. Start with INTEL_FAM6_ +2. If not Core-family, add a note about it, like "ATOM". There are only + two options for this (Xeon Phi and Atom). It is exceedingly unlikely + that you are adding a cpu which needs a new option here. +3. Add the processor microarchitecture, not the platform name +4. Add a short differentiator if necessary. Add an _X to differentiate + Server from Client. +5. Add an optional comment with the platform name(s) + +It should end up looking like this: + +INTEL_FAM6___ /* Platform Name */ -- 2.20.1
Re: [PATCH] MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.h
On Wed, Aug 14, 2019 at 04:40:30PM -0700, Tony Luck wrote: > There are a few different subsystems in the kernel that depend on > model specific behaviour (perf, EDAC, power, ...). Easier for just > one person to have the task to get new model numbers included instead > of having these groups trip over each other to do it. > > Signed-off-by: Tony Luck > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) Applied, thanks. As a first order of business, pls sum up the naming scheme convention you guys are going to adhere to so that it is clear to everybody: https://lkml.kernel.org/r/91eefbe4-e32b-d762-be4d-672ff915d...@intel.com in a patch form. :) Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
