x86, intel: Output microcode revision

From: Andi Kleen <[email protected]>

Now that the cpu update level is available the Atom PSE errata check can use it directly without reading the MSR again.

Signed-off-by Andi Kleen <[email protected]>

---
 arch/x86/kernel/cpu/intel.c |   15 ++++-----------

Subject: [PATCH 3/3] coretemp: Get microcode revision from cpu_data

From: Andi Kleen <[email protected]>

Now that the ucode revision is available in cpu_data remove the existing code in coretemp.c to query it manually. Read the ucode revision from cpu_data instead

Cc [email protected]

Cc [email protected]

Cc [email protected]

Signed-off-by Andi Kleen <[email protected]>

---
 drivers/hwmon/coretemp.c |   29 +++++------------------------
 1 files changed, 5 insertions(+), 24 deletions(-)

drivers/hwmon/coretemp.c +0 -9

index 9577c43..aff3e2c 100644
@@ -324,15 +324,6 @@ static int get_tjmax(struct cpuinfo_x86 *c, u32
 id, struct device *dev)
 	}
 }
 
-static void __devinit get_ucode_rev_on_cpu(void *edx)
-{
-	u32 eax;
-
-	wrmsr(MSR_IA32_UCODE_REV, 0, 0);
-	sync_core();
-	rdmsr(MSR_IA32_UCODE_REV, eax, *(u32 *)edx);
-}
-
 static int get_pkg_tjmax(unsigned int cpu, struct device *dev)
 {

drivers/hwmon/coretemp.c +1 -15

 	int err;

@@ -433,21 +424,11 @@ static int chk_ucode_version(struct
 platform_device *pdev)
 	 * Readings might stop update when processor visited too deep
 sleep,
 	 * fixed for stepping D0 (6EC).
 	 */
-	if (c->x86_model == 0xe && c->x86_mask < 0xc) {
-		/* check for microcode update */
-		err = smp_call_function_single(pdev->id,
 get_ucode_rev_on_cpu,
-					       &edx, 1);
-		if (err) {
-			dev_err(&pdev->dev,
-				"Cannot determine microcode revision of "
-				"CPU#%u (%d)!\n", pdev->id, err);
-			return -ENODEV;
-		} else if (edx < 0x39) {
-			dev_err(&pdev->dev,
-				"Errata AE18 not fixed, update BIOS or "
-				"microcode of the CPU!\n");
-			return -ENODEV;
-		}
+	if (c->x86_model == 0xe && c->x86_mask < 0xc && c->x86_cpu_update

< 0x39) {

drivers/hwmon/coretemp.c +4 -1

+		dev_err(&pdev->dev,
+			"Errata AE18 not fixed, update BIOS or "
+			"microcode of the CPU!\n");
+		return -ENODEV;
 	}
 	return 0;
 }
--

1.7.4.4

arch/x86/kernel/microcode_intel.c static int apply_microcode(int cpu) · line 298

Quoted 5 lines

arch/x86/kernel/microcode_intel.c +1 -0

@@ -300,6 +295,7 @@ static int apply_microcode(int cpu)
      struct ucode_cpu_info *uci;
     unsigned int val[2];
      int cpu_num;
+       struct cpuinfo_x86 *c = &cpu_data(cpu_num);

This is wrong. cpu_num is not initialized yet at this point. You need to assign c after cpu_num is initialized in the next statement.

From: Andi Kleen <[email protected]>

I got a request to make it easier to determine the microcode update level on Intel CPUs. This patch adds a new "cpu update" field to /proc/cpuinfo, which I added at the end to minimize impact on parsers.

The update level is also outputed on fatal machine checks together with the other CPUID model information.

I removed the respective code from the microcode update driver, it just reads the field from cpu_data. Also when the microcode is updated it fills in the new values too.

I had to add a memory barrier to native_cpuid to prevent it being optimized away when the result is not used.

This turns out to clean up further code which already got this information manually. This is done in followon patches.

Signed-off-by Andi Kleen <[email protected]>

---
 arch/x86/include/asm/processor.h  |    5 ++++-
 arch/x86/kernel/cpu/intel.c       |   10 ++++++++++
 arch/x86/kernel/cpu/mcheck/mce.c  |    5 +++--
 arch/x86/kernel/cpu/proc.c        |    6 +++++-
 arch/x86/kernel/microcode_intel.c |    9 +++------
 5 files changed, 25 insertions(+), 10 deletions(-)

arch/x86/include/asm/processor.h +0 -0

index 4c25ab4..23b7e26 100644

arch/x86/kernel/cpu/intel.c +0 -0

index 1edf5ba..150623a 100644
@@ -364,6 +364,16 @@ static void __cpuinit init_intel(struct cpuinfo_x86 *c)
 
 	early_init_intel(c);

arch/x86/kernel/cpu/intel.c +0 -0

 	intel_workarounds(c);
 
 	/*

arch/x86/kernel/cpu/mcheck/mce.c +0 -0

index ff1ae9b..e93c41f 100644

arch/x86/kernel/cpu/proc.c +0 -0

index 62ac8cb..cefcc27 100644

arch/x86/kernel/microcode_intel.c +2 -6

@@ -161,12 +161,7 @@ static int collect_cpu_info(int cpu_num, struct cpu_signature *csig)
 		csig->pf = 1 << ((val[1] >> 18) & 7);
 	}
 
-	wrmsr(MSR_IA32_UCODE_REV, 0, 0);
-	/* see notes above for revision 1.07.  Apparent chip bug */
-	sync_core();
-	/* get the current revision from MSR 0x8B */
-	rdmsr(MSR_IA32_UCODE_REV, val[0], csig->rev);
-
+	csig->rev = c->x86_cpu_update;
 	pr_info("CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n",
 		cpu_num, csig->sig, csig->pf, csig->rev);
 

@@ -300,6 +295,7 @@ static int apply_microcode(int cpu)
 	struct ucode_cpu_info *uci;
 	unsigned int val[2];
 	int cpu_num;
+	struct cpuinfo_x86 *c = &cpu_data(cpu_num);
 
 	cpu_num = raw_smp_processor_id();
 	uci = ucode_cpu_info + cpu;

Quoted 5 lines · Andi Kleen

From: Andi Kleen <[email protected]>

I got a request to make it easier to determine the microcode update level on Intel CPUs. This patch adds a new "cpu update" field to /proc/cpuinfo, which I added at the end to minimize impact on parsers.

Agreed, that is a good idea, adding this to cpuinfo makes sense.

Your patch is rather messy though:

Quoted 22 lines

The update level is also outputed on fatal machine checks together with the other CPUID model information.

I removed the respective code from the microcode update driver, it just reads the field from cpu_data. Also when the microcode is updated it fills in the new values too.

I had to add a memory barrier to native_cpuid to prevent it being optimized away when the result is not used.

This turns out to clean up further code which already got this information manually. This is done in followon patches.

Signed-off-by Andi Kleen <[email protected]>

---
 arch/x86/include/asm/processor.h  |    5 ++++-
 arch/x86/kernel/cpu/intel.c       |   10 ++++++++++
 arch/x86/kernel/cpu/mcheck/mce.c  |    5 +++--
 arch/x86/kernel/cpu/proc.c        |    6 +++++-
 arch/x86/kernel/microcode_intel.c |    9 +++------
 5 files changed, 25 insertions(+), 10 deletions(-)

arch/x86/include/asm/processor.h struct cpuinfo_x86 { · line 115

Quoted 10 lines

arch/x86/include/asm/processor.h +2 -0

index 4c25ab4..23b7e26 100644
@@ -111,6 +111,8 @@ struct cpuinfo_x86 {
 	/* Index into per_cpu list: */
 	u16			cpu_index;
 #endif
+	/* CPU update signature */
+	u32			x86_cpu_update;

This should be cpu_microcode_version instead. We already know its x86 so the x86_ prefix is superfluous. 'cpu_update' is also rather ambigious and does not describe much.

Quoted 8 lines

arch/x86/kernel/cpu/intel.c +0 -0

index 1edf5ba..150623a 100644
@@ -364,6 +364,16 @@ static void __cpuinit init_intel(struct cpuinfo_x86 *c)
 
 	early_init_intel(c);
 

arch/x86/kernel/cpu/intel.c static void __cpuinit init_intel(struct cpuinfo_x86 *c) · line 375

Quoted 9 lines

arch/x86/kernel/cpu/intel.c +9 -0

+	/* Determine CPU update level */
+	if (c->x86 >= 6 && !(cpu_has(c, X86_FEATURE_IA64))) {	
+		unsigned lo;
+
+		wrmsr(MSR_IA32_UCODE_REV, 0, 0);
+		/* The CPUID 1 fills in the MSR */
+		cpuid_eax(1);
+		rdmsr(MSR_IA32_UCODE_REV, lo, c->x86_cpu_update);
+	}

So, during the course of developing this, did it occur to you that other x86 CPUs should fill in this information as well?

If yes, did it occur to you to do the obvious git log arch/x86/kernel/microcode*.c command to figure out who else might be interested in this, and add them to the Cc: instead of forcing the maintainer to do that?

Quoted 7 lines

arch/x86/kernel/cpu/mcheck/mce.c +0 -0

index ff1ae9b..e93c41f 100644
@@ -220,8 +220,9 @@ static void print_mce(struct mce *m)
 		pr_cont("MISC %llx ", m->misc);
 

arch/x86/kernel/cpu/mcheck/mce.c static void print_mce(struct mce *m) · line 225

Quoted 6 lines

arch/x86/kernel/cpu/mcheck/mce.c +3 -2

 	pr_cont("\n");
-	pr_emerg(HW_ERR "PROCESSOR %u:%x TIME %llu SOCKET %u APIC %x\n",
-		m->cpuvendor, m->cpuid, m->time, m->socketid, m->apicid);
+	pr_emerg(HW_ERR "PROCESSOR %u:%x TIME %llu SOCKET %u APIC %x CPU-UPDATE %u\n",
+		m->cpuvendor, m->cpuid, m->time, m->socketid, m->apicid, 
+		cpu_data(m->extcpu).x86_cpu_update);

This text too should be microcode-version or so. Also, while at it please fix that printk() to not shout at users needlessly.

Quoted 10 lines

arch/x86/kernel/cpu/proc.c +1 -0

index 62ac8cb..cefcc27 100644
@@ -132,8 +132,12 @@ static int show_cpuinfo(struct seq_file *m, void *v)
 				seq_printf(m, " [%d]", i);
 		}
 	}
+	seq_printf(m, "\n");
 

arch/x86/kernel/cpu/proc.c static int show_cpuinfo(struct seq_file *m, void *v) · line 140

Quoted 5 lines

arch/x86/kernel/cpu/proc.c +4 -1

-	seq_printf(m, "\n\n");
+	if (c->x86_cpu_update)
+		seq_printf(m, "cpu update\t: %u\n", c->x86_cpu_update);
+
+	seq_printf(m, "\n");

This too should say microcode version.

Also, please move the field to the logical place, next to "stepping:". The argument about parsers is bogus - anyone parsing /proc/cpuinfo is not in a fastpath, full stop.

Also, the above sequence is rather suboptimal to begin with - we can and only want to execute a *single* seq_printf() there.

Quoted 26 lines

arch/x86/kernel/microcode_intel.c +2 -6

@@ -161,12 +161,7 @@ static int collect_cpu_info(int cpu_num, struct cpu_signature *csig)
 		csig->pf = 1 << ((val[1] >> 18) & 7);
 	}
 
-	wrmsr(MSR_IA32_UCODE_REV, 0, 0);
-	/* see notes above for revision 1.07.  Apparent chip bug */
-	sync_core();
-	/* get the current revision from MSR 0x8B */
-	rdmsr(MSR_IA32_UCODE_REV, val[0], csig->rev);
-
+	csig->rev = c->x86_cpu_update;
 	pr_info("CPU%d sig=0x%x, pf=0x%x, revision=0x%x\n",
 		cpu_num, csig->sig, csig->pf, csig->rev);
 

@@ -300,6 +295,7 @@ static int apply_microcode(int cpu)
 	struct ucode_cpu_info *uci;
 	unsigned int val[2];
 	int cpu_num;
+	struct cpuinfo_x86 *c = &cpu_data(cpu_num);
 
 	cpu_num = raw_smp_processor_id();
 	uci = ucode_cpu_info + cpu;

arch/x86/kernel/microcode_intel.c static int apply_microcode(int cpu) · line 336

Quoted 6 lines

arch/x86/kernel/microcode_intel.c +1 -0

@@ -335,6 +331,7 @@ static int apply_microcode(int cpu)
 		(mc_intel->hdr.date >> 16) & 0xff);
 
 	uci->cpu_sig.rev = val[1];
+	c->x86_cpu_update = val[1];
 
 	return 0;

Please factor out the reading of the microcode version - you have now created two duplicated open-coded versions of it in cpu.c and microcode_intel.c, with mismatching comments - not good.

Also, in this branch:

        if (val[1] != mc_intel->hdr.rev) {
                pr_err("CPU%d update to revision 0x%x failed\n",
                       cpu_num, mc_intel->hdr.rev);
                return -1;
        }

it would be nice to put a check:

		WARN_ON_ONCE(val[1] != c->x86_cpu_update);

To make sure that our notion of the version is still in sync with what the hardware's notion is. (it should be)

Quoted 9 lines · Ingo Molnar

Quoted 5 lines · Andi Kleen

From: Andi Kleen <[email protected]>

I got a request to make it easier to determine the microcode update level on Intel CPUs. This patch adds a new "cpu update" field to /proc/cpuinfo, which I added at the end to minimize impact on parsers.

Quoted 1 line

Agreed, that is a good idea, adding this to cpuinfo makes sense.

Frankly, I'm not even 100% persuaded this is needed. The coretemp.c jump-through-hoops to get the ucode revision is maybe the only case that warrants adding that field to /proc/cpuinfo.

Quoted 10 lines

arch/x86/include/asm/processor.h struct cpuinfo_x86 { · line 115

Quoted 6 lines

arch/x86/include/asm/processor.h +2 -0

@@ -111,6 +111,8 @@ struct cpuinfo_x86 {
 	/* Index into per_cpu list: */
 	u16			cpu_index;
 #endif
+	/* CPU update signature */
+	u32			x86_cpu_update;

This should be cpu_microcode_version instead. We already know its x86 so the x86_ prefix is superfluous. 'cpu_update' is also rather ambigious and does not describe much.

Or shorter: 'cpu_ucode_version'.

Quoted 3 lines

Frankly, I'm not even 100% persuaded this is needed. The coretemp.c jump-through-hoops to get the ucode revision is maybe the only case that warrants adding that field to /proc/cpuinfo.

I've often wondered whether the CPU involved in a particular bugreport has the latest microcode installed.

Sure we have /sys/devices/system/cpu/cpuN/microcode/version, but that's both privileged to get

and also has to be asked for separately.

Arguably the microcode version is a natural extension to the existing family/model/stepping sequence:

cpu family : 6
model : 26
stepping : 5

We'd now see:

cpu family : 6
model : 26
stepping : 5
ucode_version : 17

Where 'stepping' is a hardware revison number and 'ucode_version' is a dual software/hw revision number.

Quoted 11 lines

Quoted 10 lines

arch/x86/include/asm/processor.h struct cpuinfo_x86 { · line 115

Quoted 6 lines

arch/x86/include/asm/processor.h +2 -0

@@ -111,6 +111,8 @@ struct cpuinfo_x86 {
 	/* Index into per_cpu list: */
 	u16			cpu_index;
 #endif
+	/* CPU update signature */
+	u32			x86_cpu_update;

This should be cpu_microcode_version instead. We already know its x86 so the x86_ prefix is superfluous. 'cpu_update' is also rather ambigious and does not describe much.

Quoted 1 line

Or shorter: 'cpu_ucode_version'.

We already know it's a cpu data structure, since it's called 'struct cpuinfo_x86' and the local variable is named 'c' which is the typical shortcut for that data structure.

so c->ucode_version is the right name here.

Btw, can we dump the ucode version in hex since ours are much easier to read that way:

[86483.770976] microcode: CPU0: patch_level=0x010000c4
[86483.826987] microcode: CPU1: patch_level=0x010000c4
[86483.835071] microcode: CPU2: patch_level=0x010000c4

...

I guess for Intel the ucode version format won't matter that much.

Quoted 7 lines · Borislav Petkov

Btw, can we dump the ucode version in hex since ours are much easier to read that way:

[86483.770976] microcode: CPU0: patch_level=0x010000c4
[86483.826987] microcode: CPU1: patch_level=0x010000c4
[86483.835071] microcode: CPU2: patch_level=0x010000c4

...

How is that version constructed and iterated, or example is the 0x01000000 bit always set?

If it's always set then it might make sense to turn this into a more human-readable version number: mask out the 0x01000000 and report 0xc4 as 194? Or is the *real* version above just '4'?

Should 0x010000c4 perhaps be printed as 1.10.4?

Quoted 2 lines

I guess for Intel the ucode version format won't matter that much.

Well, if Intel does similar encodings as AMD,

then it would be nice to turn that into human-readable version strings as well.

Quoted 2 lines

Sure we have /sys/devices/system/cpu/cpuN/microcode/version, but that's both privileged to get

Not only that but you have to load the ucode driver to be able to read it. /proc/cpuinfo looks like the easiest and most generic place.

arch/x86/include/asm/processor.h struct cpuinfo_x86 { · line 115

Quoted 2 lines

arch/x86/include/asm/processor.h +2 -0

+	/* CPU update signature */
+	u32			x86_cpu_update;

This should be cpu_microcode_version instead. We already know its x86 so the x86_ prefix is superfluous. 'cpu_update' is also rather ambigious and does not

So, during the course of developing this, did it occur to you that other x86 CPUs should fill in this information as well?

arch/x86/kernel/microcode_intel.c static int collect_cpu_info(int cpu_num, struct cpu_signature *csig) · line 165

Quoted 1 line

arch/x86/kernel/microcode_intel.c +0 -1

-	/* see notes above for revision 1.07.  Apparent chip bug */

Why? If you think it's not a bug (but got documented meanwhile as the official

way of updating the microcode and reading out the version) then update the comments in a *separate* patch, and update the *other* reference to it as well.

arch/x86/kernel/cpu/proc.c static int show_cpuinfo(struct seq_file *m, void *v) · line 140

Quoted 2 lines

arch/x86/kernel/cpu/proc.c +2 -0

+
+	seq_printf(m, "\n");

This too should say microcode version.

Also, please move the field to the logical place, next to "stepping:". The argument about parsers is bogus - anyone parsing /proc/cpuinfo is not in a fastpath, full stop.

Also, the above sequence is rather suboptimal to begin with - we can and only want to execute a *single* seq_printf() there.

Please factor out the reading of the microcode version - you have now created two duplicated open-coded versions of it in cpu.c and microcode_intel.c, with mismatching comments - not good.

it would be nice to put a check:

		WARN_ON_ONCE(val[1] != c->x86_cpu_update);

Quoted 4 lines · Ingo Molnar

Quoted 4 lines

/* Index into per_cpu list: */
u16 cpu_index;

Quoted 5 lines

arch/x86/include/asm/processor.h struct cpuinfo_x86 { · line 115

Quoted 2 lines

arch/x86/include/asm/processor.h +2 -0

+	/* CPU update signature */
+	u32			x86_cpu_update;

This should be cpu_microcode_version instead. We already know its x86 so the x86_ prefix is superfluous. 'cpu_update' is also rather ambigious and does not

I followed the convention of the other fields in cpu_data, [...]

[...] but I'll drop the prefix.

"cpu update" was the name that was suggested to me. Sorry if it's a bit vague. Apparently calling it microcode is not politically correct. I'll keep it for now. If you want to really change it please send another email.

Quoted 2 lines

So, during the course of developing this, did it occur to you that other x86 CPUs should fill in this information as well?

Yes, it did in fact, but I hope someone else will do that because I have no way to test it.

Quoted 1 line

arch/x86/kernel/microcode_intel.c static int collect_cpu_info(int cpu_num, struct cpu_signature *csig) · line 165

Quoted 1 line

arch/x86/kernel/microcode_intel.c +0 -1

-	/* see notes above for revision 1.07.  Apparent chip bug */

This particular code pattern has no chip bug. The CPUID is required by the documentation! So whoever wrote it didn't read the documentation. So yes I dropped that obviously bogus comment.

Quoted 2 lines

Why? If you think it's not a bug (but got documented meanwhile as the official

It always was documented this way.

Quoted 3 lines

way of updating the microcode and reading out the version) then update the comments in a *separate* patch, and update the *other* reference to it as well.

I'm not sure about the other references. The documentation just states the CPUID is needed for reading the revision.

Anyways I'll just leave the comment around for now.

Quoted 8 lines

arch/x86/kernel/cpu/proc.c static int show_cpuinfo(struct seq_file *m, void *v) · line 140

Quoted 2 lines

arch/x86/kernel/cpu/proc.c +2 -0

+
+	seq_printf(m, "\n");

This too should say microcode version.

Also, please move the field to the logical place, next to "stepping:". The argument about parsers is bogus - anyone parsing /proc/cpuinfo is not in a fastpath, full stop.

The rationale was not cycles, but if someone was stupid enough to hardcode the line number offsets while parsing. You never know with user space /proc parsers and assuming the worst is always the best.

I thought it was safest to add new fields at the end.

Quoted 2 lines

Also, the above sequence is rather suboptimal to begin with - we can and only want to execute a *single* seq_printf() there.

Sorry I don't understand the comment. Anyways as you say above it's no fast path, so it shouldn't matter.

Quoted 3 lines

Please factor out the reading of the microcode version - you have now created two duplicated open-coded versions of it in cpu.c and microcode_intel.c, with mismatching comments - not good.

Huh? There's only a single one now.

Look at the context diff above, it has 'cpu_index', so no, there was no consistent convention to follow.

attention to that lack of means of testing? :-)

Quoted 5 lines

Quoted 1 line

arch/x86/kernel/microcode_intel.c static int collect_cpu_info(int cpu_num, struct cpu_signature *csig) · line 165

Quoted 1 line

arch/x86/kernel/microcode_intel.c +0 -1

-	/* see notes above for revision 1.07.  Apparent chip bug */

This particular code pattern has no chip bug. The CPUID is required by the documentation! So whoever wrote it didn't read the documentation. So yes I dropped that obviously bogus comment.

And you thus 'obviously' forked away the reading of the microcode version into another file, with the same 'obviously wrong' comment left behind in another place?

Quoted 1 line

It always was documented this way.

FYI, the x86 microcode driver actually predates official public

No, it's not a problem to add /proc/cpuinfo fields in the middle - please add this new field to the logical place.

Quoted 2 lines

Huh? There's only a single one now.

That's not actually true. With your patches applied a trivial git grep shows the two places reading the microcode version:

arch/x86/include/asm/processor.h struct cpuinfo_x86 { · line 115

Quoted 8 lines · Andi Kleen

arch/x86/include/asm/processor.h +2 -0

@@ -111,6 +111,8 @@ struct cpuinfo_x86 {
 	/* Index into per_cpu list: */
 	u16			cpu_index;
 #endif
+	/* CPU update signature */
+	u32			x86_cpu_update;

Btw,. there's one subtle thing here: it's possible to have *different* microcode versions on different CPUs in te system.

This can happen if for example the BIOS somehow does not apply the right microcode to all CPUs. It can also happen if physically different microcode version CPUs are mixed. In theory people can mix steppings as well.

been brought online, and print some very visible boot warning message if there's a mismatch between the steppings or microcode versions? Perhaps also taint the kernel.

Quoted 3 lines

This can happen if for example the BIOS somehow does not apply the right microcode to all CPUs. It can also happen if physically different microcode version CPUs are mixed. In theory people can mix steppings as well.

In PRACTICE people WILL mix steppings as well.

Quoted 5 lines

Quoted 3 lines

This can happen if for example the BIOS somehow does not apply the right microcode to all CPUs. It can also happen if physically different microcode version CPUs are mixed. In theory people can mix steppings as well.

In PRACTICE people WILL mix steppings as well.

Yes exactly. I used to have a system with one P3 supporting FXSAVE and other not :-) I had to fix the kernel back then to support this. The system worked perfectly fine after the kernel was fixed.

So the check proposed is a bad idea. It would trigger on real boxes which don't have any obvious problems.

So displaying a non-fatal 'info' message about it would in fact be rather wise. Nothing scary, but we'd like to be informed.

Quoted 3 lines · Ingo Molnar

So displaying a non-fatal 'info' message about it would in fact be rather wise. Nothing scary, but we'd like to be informed.

A printk with levels info or notice, I do agree to be a good idea. In fact, I like the idea a lot.

WARN() and kernel tainting, which is what I understand was being proposed before, I cannot agree with.

OTOH, IMO mismatched microcode should be grounds for more serious measures. And that includes fixing the annoying userspace ABI that encourages bad behaviour in the first place and makes it harder to do the proper thing.

Many years ago i had an old P3 system where i mixed steppings and it was not stable, it would crash after i have put some load on the system.

I hadn't really expected this simple patchkit to generate that much email :-)

Quoted 3 lines

Many years ago i had an old P3 system where i mixed steppings and it was not stable, it would crash after i have put some load on the system.

Ok.

But it's not clear to me how to reliably do it for the microcode at boot. Because a future microcode update could fix it up, but the kernel can't know if there will be a microcode update or not. So I don't think it can be done at boot at least.

If you want me to rewrite the microcode update driver or something like that that's outside the scope of my patchkit, sorry.

From: Andi Kleen<[email protected]>

I got a request to make it easier to determine the microcode update level on Intel CPUs. This patch adds a new "cpu update" field to /proc/cpuinfo, which I added at the end to minimize impact on parsers.

The update level is also outputed on fatal machine checks together with the other CPUID model information.