On systems where a runtime microcode update has occurred the
microcode version is wrong because boot_cpu_data.microcode is
not updated during runtime.
Use the per-CPU microcode version in the MCE message.
Signed-off-by: Prarit Bhargava <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
arch/x86/kernel/cpu/mcheck/mce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index c102ad51025e..64fee27433e9 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -134,7 +134,7 @@ void mce_setup(struct mce *m)
if (this_cpu_has(X86_FEATURE_INTEL_PPIN))
rdmsrl(MSR_PPIN, m->ppin);
- m->microcode = boot_cpu_data.microcode;
+ m->microcode = cpu_data(m->extcpu).microcode;
}
DEFINE_PER_CPU(struct mce, injectm);
--
2.14.4
On Tue, Jul 03, 2018 at 12:48:44PM -0400, Prarit Bhargava wrote:
> On systems where a runtime microcode update has occurred the
> microcode version is wrong because boot_cpu_data.microcode is
> not updated during runtime.
>
> Use the per-CPU microcode version in the MCE message.
Other option would be to fix the microcode update code to make
sure that boot_cpu_data.microcode is right.
But if we go this route we should add:
Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check records")
Cc: [email protected]
Can also get a:
Reviewed-by: Tony Luck <[email protected]>
-Tony Luck
On 07/03/2018 12:58 PM, Luck, Tony wrote:
> On Tue, Jul 03, 2018 at 12:48:44PM -0400, Prarit Bhargava wrote:
>> On systems where a runtime microcode update has occurred the
>> microcode version is wrong because boot_cpu_data.microcode is
>> not updated during runtime.
>>
>> Use the per-CPU microcode version in the MCE message.
>
> Other option would be to fix the microcode update code to make
> sure that boot_cpu_data.microcode is right.
I thought about that too [1] but TBH I've always been a bit confused by
boot_cpu_data vs. cpu_data(). At one point I thought that boot_cpu_data is
valid only up to a specific point in boot and from that point on the cpu_data()
should be used but I'm no longer sure if that's correct.
If that is not correct when should boot_cpu_data be used vs cpu_data()? Is
boot_cpu_data truly supposed to represent the general state of the boot cpu at
boot time?
Look at the same function mce_setup() that I modified in my patch. There is
another reference to boot_cpu_data.x86_vendor (which obviously will never change
during runtime) that likely should be cpu_data() if my understanding above is
correct.
P.
[1] Since the kernel now uses a cpu rendezvous model to update the microcode it
would be trivial to set boot_cpu_data.microcode to the new value.
>
> But if we go this route we should add:
>
> Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check records")
> Cc: [email protected]
>
> Can also get a:
>
> Reviewed-by: Tony Luck <[email protected]>
>
> -Tony Luck
>
On Tue, Jul 03, 2018 at 09:58:49AM -0700, Luck, Tony wrote:
> On Tue, Jul 03, 2018 at 12:48:44PM -0400, Prarit Bhargava wrote:
> > On systems where a runtime microcode update has occurred the
> > microcode version is wrong because boot_cpu_data.microcode is
> > not updated during runtime.
> >
> > Use the per-CPU microcode version in the MCE message.
>
> Other option would be to fix the microcode update code to make
> sure that boot_cpu_data.microcode is right.
Yes, I already requested that:
https://lkml.kernel.org/r/[email protected]
Looks like Filippo has a patch already. CCed.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On 07/03/2018 05:43 PM, Borislav Petkov wrote:
> On Tue, Jul 03, 2018 at 09:58:49AM -0700, Luck, Tony wrote:
>> On Tue, Jul 03, 2018 at 12:48:44PM -0400, Prarit Bhargava wrote:
>>> On systems where a runtime microcode update has occurred the
>>> microcode version is wrong because boot_cpu_data.microcode is
>>> not updated during runtime.
>>>
>>> Use the per-CPU microcode version in the MCE message.
>>
>> Other option would be to fix the microcode update code to make
>> sure that boot_cpu_data.microcode is right.
>
> Yes, I already requested that:
>
> https://lkml.kernel.org/r/[email protected]
>
> Looks like Filippo has a patch already. CCed.
Filippo & Borislav, did the patch get committed to a -next tree?
P.
>
On Mon, Jul 30, 2018 at 11:23:18AM -0400, Prarit Bhargava wrote:
> Filippo & Borislav, did the patch get committed to a -next tree?
No, I'm still waiting for it - looks like Filippo is busy.
Care to send one instead as suggested here?
https://lore.kernel.org/lkml/[email protected]/
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
> On 30. Jul 2018, at 18:16, Borislav Petkov <[email protected]> wrote:
>
> On Mon, Jul 30, 2018 at 11:23:18AM -0400, Prarit Bhargava wrote:
>> Filippo & Borislav, did the patch get committed to a -next tree?
>
> No, I'm still waiting for it - looks like Filippo is busy.
>
> Care to send one instead as suggested here?
>
> https://lore.kernel.org/lkml/[email protected]/
>
> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --
Sorry, I was out of office for a while.
I'll look into this today.
Filippo
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
On Tue, Jul 31, 2018 at 07:43:46AM +0000, Sironi, Filippo wrote:
> Sorry, I was out of office for a while.
> I'll look into this today.
Prarit is doing a patch too - you might wanna save effort. I leave it up
to you guys to figure out who should do it.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--