Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 17 Jan 2023 19:40:31 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH v4 6/6] x86/microcode/intel: Print when early microcode loading fails |
| |
On Tue, Jan 17, 2023 at 10:32:50AM -0800, Dave Hansen wrote: > Well, we have an awful lot of pr_warn()'s in the kernel that talk about > something that was tried and failed.
Well, is microcode loading failure worth to warn about?
What if there's no microcode for that CPU?
Now imagine in that case you issue a warning and then you get all those bugzillas opened:
"Heeey, is my CPU broken, it says it cannot load microcode"
I sure don't want to be on the receiving end of this.
I don't think you wanna be there either.
> I actually kinda like the inverse. > > The common (boring) case where an update was needed and was successful. > It's the one we don't need to tell users about at all. It barely > deserves a message. Users expect that if there's an early update > available, it'll get attempted, it will be successful and the kernel > won't say much.
No argument there.
> The time we need to spam dmesg is when something upends user > expectations and they might need to go do something. An early loading > failure is exactly the place where they want to know. They want to know > if they're running with known CPU bugs that would have been fixed by the > early update
No, we already warn about that in the CPU mitigations code.
> or if they somehow have a botched early loading image.
If you can pick apart from this here:
/* write microcode via MSR 0x79 */ native_wrmsrl(MSR_IA32_UCODE_WRITE, (unsigned long)mc->bits);
what type of failure it is, then sure, let's warn.
But we should not warn just for every revision mismatch in there...
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| ![\](/images/icornerr.gif) |