[PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs

[PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs

[Ricardo Neri]

Add support to discover and enumerate CPUs in Intel hybrid parts. A hybrid
part has CPUs with more than one type of micro-architecture. Thus, certain
features may only be present in a specific CPU type.

It is useful to know the type of CPUs present in a system. For instance,
perf may need to handle CPUs differently depending on the type of micro-
architecture. Decoding machine check error logs may need the additional
micro-architecture type information, so include that in the log.

A hybrid part can be identified by reading a new CPUID feature bit.
Likewise, CPUID contains information about the CPU type as well as a new
native model ID. Details can be found in the Intel manual (SDM, [1]).

This series adds support for Intel hybrid parts in two areas: a) adding
the hybrid feature bit as well as struct cpuinfo_x86; and b) decode machine
check errors on hybrid parts.

A later submission will use the proposed functionality to expose the CPU
topology to user space.

Thanks and BR,
Ricardo

[1].
https://software.intel.com/content/dam/develop/public/us/en/documents/325462-sdm-vol-1-2abcd-3abcd.pdf
Vol 2. Section 3.2.CPUID leaf 0x1a

Ricardo Neri (3):
  x86/cpufeatures: Enumerate hybrid CPU feature bit
  x86/cpu: Describe hybrid CPUs in cpuinfo_x86
  x86/mce: include type of core when reporting a machine check error

 arch/x86/include/asm/cpufeatures.h |  1 +
 arch/x86/include/asm/processor.h   | 13 +++++++++++++
 arch/x86/include/uapi/asm/mce.h    |  1 +
 arch/x86/kernel/cpu/common.c       |  5 +++++
 arch/x86/kernel/cpu/mce/core.c     |  7 +++++++
 5 files changed, 27 insertions(+)

-- 
2.17.1

[PATCH 1/3] x86/cpufeatures: Enumerate hybrid CPU feature bit

[Ricardo Neri]

Add feature enumeration to identify a hybrid part: one in which CPUs with
more than one type of micro-architecture exists in the same package.

Cc: Andi Kleen <ak@linux.intel.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Len Brown <len.brown@intel.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
 arch/x86/include/asm/cpufeatures.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index dad350d42ecf..26ecc0f2a6fd 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -371,6 +371,7 @@
 #define X86_FEATURE_MD_CLEAR		(18*32+10) /* VERW clears CPU buffers */
 #define X86_FEATURE_TSX_FORCE_ABORT	(18*32+13) /* "" TSX_FORCE_ABORT */
 #define X86_FEATURE_SERIALIZE		(18*32+14) /* SERIALIZE instruction */
+#define X86_FEATURE_HYBRID_CPU		(18*32+15) /* This part has CPUs of more than one type */
 #define X86_FEATURE_TSXLDTRK		(18*32+16) /* TSX Suspend Load Address Tracking */
 #define X86_FEATURE_PCONFIG		(18*32+18) /* Intel PCONFIG */
 #define X86_FEATURE_ARCH_LBR		(18*32+19) /* Intel ARCH LBR */
-- 
2.17.1

[PATCH 2/3] x86/cpu: Describe hybrid CPUs in cpuinfo_x86

[Ricardo Neri]

When Linux runs on Intel hybrid parts (i.e., having more than one type of
CPU in the same package), subsystems that deal with specific CPU features
may need to know the type of CPU in which they run. Instead of having each
subsystem to inspect CPUID leaves on its own, add a new member to
cpuinfo_x86 that can be queried to know the type of CPU.

Also, hybrid parts have a native model ID to uniquely identify the
micro-architecture of each CPU. Please note that the native model ID is not
related with the existing x86_model_id read from CPUID leaf 0x1.

In order to uniquely identify a CPU by type and micro-architecture, combine
the aforementioned identifiers into a single new member, x86_cpu_type.

The Intel manual (SDM) defines the CPU type and the CPU native model ID as
8-bit and 24-bit identifiers, respectively; they are packed in %eax when
read from CPUID.

Define also masks that subsystems can use to obtain the CPU type or the
native model separately. The native model ID only requires only a bit mask
as it uses the 24 least significant bits of %eax. The CPU type identifier
requires only a shift value as it uses the 8 most significant bytes of
%eax.

Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Len Brown <len.brown@intel.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: "Ravi V. Shankar" <ravi.v.shankar@intel.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
 arch/x86/include/asm/processor.h | 13 +++++++++++++
 arch/x86/kernel/cpu/common.c     |  5 +++++
 2 files changed, 18 insertions(+)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index f88c74d7dbd4..d86cdf2b1562 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -141,6 +141,16 @@ struct cpuinfo_x86 {
 	u32			microcode;
 	/* Address space bits used by the cache internally */
 	u8			x86_cache_bits;
+	/*
+	 * In hybrid parts, there is a CPU type and a native model ID. The
+	 * CPU type (x86_cpu_type[31:24]) describes the type of micro-
+	 * architecture families. The native model ID (x86_cpu_type[23:0])
+	 * describes a specific microarchitecture version. Combining both
+	 * allows to uniquely identify a CPU.
+	 *
+	 * Please note that the native model ID is not related to x86_model.
+	 */
+	u32			x86_cpu_type;
 	unsigned		initialized : 1;
 } __randomize_layout;
 
@@ -168,6 +178,9 @@ enum cpuid_regs_idx {
 
 #define X86_VENDOR_UNKNOWN	0xff
 
+#define X86_HYBRID_CPU_TYPE_ID_SHIFT		24
+#define X86_HYBRID_CPU_NATIVE_MODEL_ID_MASK	0xffffff
+
 /*
  * capabilities of CPUs
  */
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 35ad8480c464..0778b3ad26b3 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -932,6 +932,11 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
 		c->x86_capability[CPUID_D_1_EAX] = eax;
 	}
 
+	if (cpu_has(c, X86_FEATURE_HYBRID_CPU)) {
+		cpuid_count(0x0000001a, 0, &eax, &ebx, &ecx, &edx);
+		c->x86_cpu_type = eax;
+	}
+
 	/* AMD-defined flags: level 0x80000001 */
 	eax = cpuid_eax(0x80000000);
 	c->extended_cpuid_level = eax;
-- 
2.17.1

[PATCH 3/3] x86/mce: include type of core when reporting a machine check error

[Ricardo Neri]

In hybrid parts, each type of core reports different types of machine check
errors as the machine check error blocks are tied to different parts of the
hardware. Furthermore, errors may be different across micro-architecture
versions. Thus, in order to decode errors, userspace tools need to know the
type of core as well as the native model ID of the CPU which reported the
error.

This extra information is only included in the error report only when
running on hybrid parts. This conserves the existing behavior when running
on non-hybrid parts. Hence, legacy userspace tools running on new kernels
and hybrid hardware can still understand the format of the reported error
format.

Cc: "Ravi V Shankar" <ravi.v.shankar@intel.com>
Cc: linux-edac@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
---
 arch/x86/include/uapi/asm/mce.h | 1 +
 arch/x86/kernel/cpu/mce/core.c  | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/arch/x86/include/uapi/asm/mce.h b/arch/x86/include/uapi/asm/mce.h
index db9adc081c5a..e730572186d6 100644
--- a/arch/x86/include/uapi/asm/mce.h
+++ b/arch/x86/include/uapi/asm/mce.h
@@ -36,6 +36,7 @@ struct mce {
 	__u64 ppin;		/* Protected Processor Inventory Number */
 	__u32 microcode;	/* Microcode revision */
 	__u64 kflags;		/* Internal kernel use */
+	__u32 hybrid_info;	/* Type and native model ID in hybrid parts */
 };
 
 #define MCE_GET_RECORD_LEN   _IOR('M', 1, int)
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index a6ff407dec71..ecac8d9b6070 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -143,6 +143,9 @@ noinstr void mce_setup(struct mce *m)
 	m->apicid = cpu_data(m->extcpu).initial_apicid;
 	m->mcgcap = __rdmsr(MSR_IA32_MCG_CAP);
 
+	if (this_cpu_has(X86_FEATURE_HYBRID_CPU))
+		m->hybrid_info = cpuid_eax(0x1a);
+
 	if (this_cpu_has(X86_FEATURE_INTEL_PPIN))
 		m->ppin = __rdmsr(MSR_PPIN);
 	else if (this_cpu_has(X86_FEATURE_AMD_PPIN))
@@ -264,6 +267,10 @@ static void __print_mce(struct mce *m)
 	pr_emerg(HW_ERR "PROCESSOR %u:%x TIME %llu SOCKET %u APIC %x microcode %x\n",
 		m->cpuvendor, m->cpuid, m->time, m->socketid, m->apicid,
 		m->microcode);
+
+	if (this_cpu_has(X86_FEATURE_HYBRID_CPU))
+		pr_emerg(HW_ERR "HYBRID_TYPE %x HYBRID_NATIVE_MODEL_ID %x\n",
+			 m->hybrid_info >> 24, m->hybrid_info & 0xffffff);
 }
 
 static void print_mce(struct mce *m)
-- 
2.17.1

Re: [PATCH 2/3] x86/cpu: Describe hybrid CPUs in cpuinfo_x86

[Borislav Petkov]

On Fri, Oct 02, 2020 at 01:19:30PM -0700, Ricardo Neri wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 35ad8480c464..0778b3ad26b3 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -932,6 +932,11 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
>  		c->x86_capability[CPUID_D_1_EAX] = eax;
>  	}
>  
> +	if (cpu_has(c, X86_FEATURE_HYBRID_CPU)) {
> +		cpuid_count(0x0000001a, 0, &eax, &ebx, &ecx, &edx);
> +		c->x86_cpu_type = eax;

		c->x86_cpu_type = cpuid_eax(0x0000001a);

should do too.

But send this patch together with the code that uses it.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH 2/3] x86/cpu: Describe hybrid CPUs in cpuinfo_x86

[Ricardo Neri]

On Fri, Oct 02, 2020 at 10:34:52PM +0200, Borislav Petkov wrote:
> On Fri, Oct 02, 2020 at 01:19:30PM -0700, Ricardo Neri wrote:
> > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > index 35ad8480c464..0778b3ad26b3 100644
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -932,6 +932,11 @@ void get_cpu_cap(struct cpuinfo_x86 *c)
> >  		c->x86_capability[CPUID_D_1_EAX] = eax;
> >  	}
> >  
> > +	if (cpu_has(c, X86_FEATURE_HYBRID_CPU)) {
> > +		cpuid_count(0x0000001a, 0, &eax, &ebx, &ecx, &edx);
> > +		c->x86_cpu_type = eax;
> 
> 		c->x86_cpu_type = cpuid_eax(0x0000001a);
> 
> should do too.

Thank you for the quick feedback Boris! Sure I can implement it as you
suggest.

> 
> But send this patch together with the code that uses it.

Sure I can submit it along with the code using it.

What about patches 1 and 3? Should I resubmit the series with only
those?

Thanks and BR,
Ricardo

Re: [PATCH 2/3] x86/cpu: Describe hybrid CPUs in cpuinfo_x86

[Borislav Petkov]

On Fri, Oct 02, 2020 at 02:02:31PM -0700, Ricardo Neri wrote:
> What about patches 1 and 3? Should I resubmit the series with only
> those?

Why would you need to resubmit? They're good to go as is, AFAICT.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH 2/3] x86/cpu: Describe hybrid CPUs in cpuinfo_x86

[Ricardo Neri]

On Fri, Oct 02, 2020 at 11:03:06PM +0200, Borislav Petkov wrote:
> On Fri, Oct 02, 2020 at 02:02:31PM -0700, Ricardo Neri wrote:
> > What about patches 1 and 3? Should I resubmit the series with only
> > those?
> 
> Why would you need to resubmit? They're good to go as is, AFAICT.

Thanks for clarifying Boris. Just wanted to check if there was any
action required from me regarding patches 1 & 3.

Thanks and BR,
Ricardo

Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs

[Thomas Gleixner]

On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote:
> Add support to discover and enumerate CPUs in Intel hybrid parts. A hybrid
> part has CPUs with more than one type of micro-architecture. Thus, certain
> features may only be present in a specific CPU type.
>
> It is useful to know the type of CPUs present in a system. For instance,
> perf may need to handle CPUs differently depending on the type of micro-
> architecture. Decoding machine check error logs may need the additional
> micro-architecture type information, so include that in the log.

'It is useful' as justification just makes me barf.

> A hybrid part can be identified by reading a new CPUID feature bit.
> Likewise, CPUID contains information about the CPU type as well as a new
> native model ID. Details can be found in the Intel manual (SDM, [1]).
>
> This series adds support for Intel hybrid parts in two areas: a) adding
> the hybrid feature bit as well as struct cpuinfo_x86; and b) decode machine
> check errors on hybrid parts.

Bla, bla, bla.

> A later submission will use the proposed functionality to expose the CPU
> topology to user space.

The only patch which is accepted for now is:

    	if (boot_cpu_has(X86_FEATURE_HYBRID_CPU))
        	panic("Unsuppported insanity\n");

I'm not all all willing to take anything else unless you or someone else
provides a reasonable explanation for the overall approach of supporting
this mess inlcuding stable kernels.

This has been clearly communicated years ago when the topic was
discussed at one of the Intel Techday events. It's not my problem if
Intel internal communication is disfunctional.

Just to bring you up to speed:

     1) The whole CPU enumeration of x86 sucks and is in no way prepared
        to deal with heterogenous CPU faetures

        Boris and I have discussed this with Intel and on LKML and there
        are ideas how to clean up that mess.

        This needs to be solved first before we even start to talk about
        this CPU has FOO but the other does not.

     2) Intel has been told clearly that a prerequisite of adding any of
        this is a well defined programming model and a proper design of
        dealing with it at the kernel level.

        Since that discussion at one of the Intel events I haven't heard
        and seen anything related to that.

        If Intel thinks that some magic PDF and some Intel internal
        'works for me' patches are solving it, then I just have to give
        up because explaining the requirements again is just waste of
        time.

So I'm taking Patch 1/3 which defines the misfeature flag and then put
something like the above on top which will prevent booting on any of
these machines.

These two patches are going to be marked for stable simply because any
attempt to use any of these asymetric features is a recipe to
disaster. And that disaster is going to happen simply because user space
can use CPUID to figure out what a CPU supports. I'm not at all
interested in the resulting wreckage reports.

It's a sad state of affairs that the only outcome of a dicsussion which
touched all of the above is a patch set which paves the path to hell.

Not going to happen.

Thanks,

        tglx

Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs

[Luck, Tony]

On Sat, Oct 03, 2020 at 03:39:29AM +0200, Thomas Gleixner wrote:
> On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote:
> > Add support to discover and enumerate CPUs in Intel hybrid parts. A hybrid
> > part has CPUs with more than one type of micro-architecture. Thus, certain
> > features may only be present in a specific CPU type.
> >
> > It is useful to know the type of CPUs present in a system. For instance,
> > perf may need to handle CPUs differently depending on the type of micro-
> > architecture. Decoding machine check error logs may need the additional
> > micro-architecture type information, so include that in the log.
> 
> 'It is useful' as justification just makes me barf.

This isn't "hetero" ... all of the cores are architecturally the same.
If CPUID says that some feature is supported, then it will be supported
on all of the cores.

There might be some model specific performance counter events that only
apply to some cores. Or a machine check error code that is logged in the
model specific MSCOD field of IA32_MCi_STATUS. But any and all code can run
on any core.

Sure there will be some different power/performance tradeoffs on some
cores. But we already have that with some cores able to achieve higher
turbo frequencies than others.

-Tony

Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs

[Borislav Petkov]

On Fri, Oct 02, 2020 at 07:17:30PM -0700, Luck, Tony wrote:
> On Sat, Oct 03, 2020 at 03:39:29AM +0200, Thomas Gleixner wrote:
> > On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote:
> > > Add support to discover and enumerate CPUs in Intel hybrid parts. A hybrid
> > > part has CPUs with more than one type of micro-architecture. Thus, certain
> > > features may only be present in a specific CPU type.
> > >
> > > It is useful to know the type of CPUs present in a system. For instance,
> > > perf may need to handle CPUs differently depending on the type of micro-
> > > architecture. Decoding machine check error logs may need the additional
> > > micro-architecture type information, so include that in the log.
> > 
> > 'It is useful' as justification just makes me barf.
> 
> This isn't "hetero" ... all of the cores are architecturally the same.

But it says above "A hybrid part has CPUs with more than one type of
micro-architecture."

So which is it?

> If CPUID says that some feature is supported, then it will be supported
> on all of the cores.

Ok.

> There might be some model specific performance counter events that only
> apply to some cores.

That sounds like the perf counter scheduling code would have to pay
attention to what is supported. I think we have some functionality for
that due to some AMD parts but I'd prefer if Peter comments here.

> Or a machine check error code that is logged in the model specific
> MSCOD field of IA32_MCi_STATUS. But any and all code can run on any
> core.

As long as that is consumed only by userspace I guess that's ok. The
moment someone starts to want to differentiate on what kind of CPU
kernel code runs and acts accordingly, then it becomes ugly so we better
hash it out upfront.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs

[Thomas Gleixner]

On Fri, Oct 02 2020 at 19:17, Tony Luck wrote:

> On Sat, Oct 03, 2020 at 03:39:29AM +0200, Thomas Gleixner wrote:
>> On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote:
>> > Add support to discover and enumerate CPUs in Intel hybrid parts. A hybrid
>> > part has CPUs with more than one type of micro-architecture. Thus, certain
>> > features may only be present in a specific CPU type.
>> >
>> > It is useful to know the type of CPUs present in a system. For instance,
>> > perf may need to handle CPUs differently depending on the type of micro-
>> > architecture. Decoding machine check error logs may need the additional
>> > micro-architecture type information, so include that in the log.
>> 
>> 'It is useful' as justification just makes me barf.
>
> This isn't "hetero" ... all of the cores are architecturally the same.

The above clearly says:

>> > A hybrid part has CPUs with more than one type of micro-architecture.

Can you folks talk to each other and chose non-ambigous wording in
changelogs and cover letters?

> If CPUID says that some feature is supported, then it will be supported
> on all of the cores.

That's a different story.

> There might be some model specific performance counter events that only
> apply to some cores. Or a machine check error code that is logged in the
> model specific MSCOD field of IA32_MCi_STATUS. But any and all code can run
> on any core.

Ok. The perf side should be doable, IIRC we already have something like
that, but Peter should know better.

> Sure there will be some different power/performance tradeoffs on some
> cores. But we already have that with some cores able to achieve higher
> turbo frequencies than others.

Right, that's not a problem.

Thanks,

        tglx

Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs

[Peter Zijlstra]

On Sat, Oct 03, 2020 at 12:46:29PM +0200, Thomas Gleixner wrote:
> > There might be some model specific performance counter events that only
> > apply to some cores. Or a machine check error code that is logged in the
> > model specific MSCOD field of IA32_MCi_STATUS. But any and all code can run
> > on any core.
> 
> Ok. The perf side should be doable, IIRC we already have something like
> that, but Peter should know better.

Yes, ARM big.LITTLE has horrible hacks. Please look at them for
inspiration.

Also, I once started (and never found time to finish)..

  https://lkml.kernel.org/r/20181010104559.GO5728@hirez.programming.kicks-ass.net

Kan should be aware of all this.

Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs

[Ricardo Neri]

On Sat, Oct 03, 2020 at 12:46:29PM +0200, Thomas Gleixner wrote:
> On Fri, Oct 02 2020 at 19:17, Tony Luck wrote:
> 
> > On Sat, Oct 03, 2020 at 03:39:29AM +0200, Thomas Gleixner wrote:
> >> On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote:
> >> > Add support to discover and enumerate CPUs in Intel hybrid parts. A hybrid
> >> > part has CPUs with more than one type of micro-architecture. Thus, certain
> >> > features may only be present in a specific CPU type.
> >> >
> >> > It is useful to know the type of CPUs present in a system. For instance,
> >> > perf may need to handle CPUs differently depending on the type of micro-
> >> > architecture. Decoding machine check error logs may need the additional
> >> > micro-architecture type information, so include that in the log.
> >> 
> >> 'It is useful' as justification just makes me barf.
> >
> > This isn't "hetero" ... all of the cores are architecturally the same.
> 
> The above clearly says:
> 
> >> > A hybrid part has CPUs with more than one type of micro-architecture.
> 
> Can you folks talk to each other and chose non-ambigous wording in
> changelogs and cover letters?
> 
> > If CPUID says that some feature is supported, then it will be supported
> > on all of the cores.
> 
> That's a different story.

Thank you for the quick reply, Thomas.

I am sorry if my cover letter was not sufficiently clear. I see now that
I should have done a more detailed discussion of the terminology.

Yes, all features and instructions as enumerated in CPUID will be
supported in all CPUs. Thus, the kernel will not have to check if a
feature is supported before running. The hetero/hybrid part means to
reflect that more than one types of CPUs will be present in the package,
and the main difference is power and performance. The same kernel and user code
will run on all CPUs without any other further check.

> 
> > There might be some model specific performance counter events that only
> > apply to some cores. Or a machine check error code that is logged in the
> > model specific MSCOD field of IA32_MCi_STATUS. But any and all code can run
> > on any core.
> 
> Ok. The perf side should be doable, IIRC we already have something like
> that, but Peter should know better.
> 
> > Sure there will be some different power/performance tradeoffs on some
> > cores. But we already have that with some cores able to achieve higher
> > turbo frequencies than others.
> 
> Right, that's not a problem.

We are also working this front.

Thanks and BR,
Ricardo

Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs

[Ricardo Neri]

On Sat, Oct 03, 2020 at 11:04:29AM +0200, Borislav Petkov wrote:
> On Fri, Oct 02, 2020 at 07:17:30PM -0700, Luck, Tony wrote:
> > On Sat, Oct 03, 2020 at 03:39:29AM +0200, Thomas Gleixner wrote:
> > > On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote:
> > > > Add support to discover and enumerate CPUs in Intel hybrid parts. A hybrid
> > > > part has CPUs with more than one type of micro-architecture. Thus, certain
> > > > features may only be present in a specific CPU type.
> > > >
> > > > It is useful to know the type of CPUs present in a system. For instance,
> > > > perf may need to handle CPUs differently depending on the type of micro-
> > > > architecture. Decoding machine check error logs may need the additional
> > > > micro-architecture type information, so include that in the log.
> > > 
> > > 'It is useful' as justification just makes me barf.
> > 
> > This isn't "hetero" ... all of the cores are architecturally the same.
> 
> But it says above "A hybrid part has CPUs with more than one type of
> micro-architecture."
> 
> So which is it?

Yes, even though they have different micro-architectures, all instructions and
features will be the same across CPUs.

> 
> > If CPUID says that some feature is supported, then it will be supported
> > on all of the cores.
> 
> Ok.
> 
> > There might be some model specific performance counter events that only
> > apply to some cores.
> 
> That sounds like the perf counter scheduling code would have to pay
> attention to what is supported. I think we have some functionality for
> that due to some AMD parts but I'd prefer if Peter comments here.
> 
> > Or a machine check error code that is logged in the model specific
> > MSCOD field of IA32_MCi_STATUS. But any and all code can run on any
> > core.
> 
> As long as that is consumed only by userspace I guess that's ok. The
> moment someone starts to want to differentiate on what kind of CPU
> kernel code runs and acts accordingly, then it becomes ugly so we better
> hash it out upfront.

We are not planning to implement changes as such.

Thanks and BR,
Ricardo