From: Ashok Raj <ashok.raj@intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Tony Luck <tony.luck@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
"LKML Mailing List" <linux-kernel@vger.kernel.org>,
X86-kernel <x86@kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Tom Lendacky <thomas.lendacky@amd.com>,
Jacon Jun Pan <jacob.jun.pan@intel.com>,
Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCH v3 3/5] x86/microcode: Avoid any chance of MCE's during microcode update
Date: Wed, 17 Aug 2022 11:40:35 +0000 [thread overview]
Message-ID: <YvzTsxilM1kUGeFQ@araj-dh-work> (raw)
In-Reply-To: <Yvybq+hYT4tG/yAg@gmail.com>
On Wed, Aug 17, 2022 at 09:41:31AM +0200, Ingo Molnar wrote:
>
> > +void mce_set_mcip(void)
> > +{
> > + mce_wrmsrl(MSR_IA32_MCG_STATUS, 0x1);
> > +}
> > +
> > +void mce_clear_mcip(void)
> > +{
> > + mce_wrmsrl(MSR_IA32_MCG_STATUS, 0x0);
> > +}
>
> Instead of naming new APIs after how they are doing stuff, please name them
> after *what* they are doing at the highest level: they disable/enable MCEs.
>
> Ie. I'd suggest something like:
>
> mce_disable()
> mce_enable()
We actually aren't disabling MCE's we set things up to promote it to a more
severe shutdown if an MCE were to be signaled while in the ucode update
flow.
I'm struggling to find a suitable name. But I agree with what you are
saying.
promote_mce_to_fatal()? I'll take any names that seem fit.
>
> I'd also suggest to at minimum add a WARN_ON_ONCE() if MSR_IA32_MCG_STATUS
> is already 1 when we disable it - because whoever wanted it disabled will
> now be surprised by us enabling them again.
Ok, will add.
>
> > + /*
> > + * Its dangerous to let MCE while microcode update is in progress.
>
> s/let MCE while
> /let MCEs execute while
>
> > + * Its extremely rare and even if happens they are fatal errors.
> > + * But reading patched areas before the update is complete can be
> > + * leading to unpredictable results. Setting MCIP will guarantee
>
> s/can be leading to
> /can lead to
>
> > + * the platform is taken to reset predictively.
>
> What does 'the platform is taken to reset predictively' mean?
Since we are setting MCG_STATUS.MCIP=1, since MCE's aren't nestable,
if there is a hardware event trying to signal a MCE, it will turn into a
platform reset. The MCE registers that logged the event will be sticky
and preserve in a warm reset case. BIOS or OS can pickup values after the
reboot is complete.
>
> Did you mean 'predictibly'/'reliably'?
I don't know the difference, except both are a trustworthy topic :-)
I like predictable, the system is going down.. not reliable :-)
>
> > + */
> > + mce_set_mcip();
> > /*
> > * On an SMT system, it suffices to load the microcode on one sibling of
> > * the core because the microcode engine is shared between the threads.
> > @@ -457,6 +466,7 @@ static int __reload_late(void *info)
> > * loading attempts happen on multiple threads of an SMT core. See
> > * below.
> > */
> > +
> > if (cpumask_first(topology_sibling_cpumask(cpu)) == cpu)
> > apply_microcode_local(&err);
> > else
>
> Spurious newline added?
It's a gonner !
Cheers,
Ashok
next prev parent reply other threads:[~2022-08-17 11:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-17 5:11 [PATCH v3 0/5] Making microcode late-load robust Ashok Raj
2022-08-17 5:11 ` [PATCH v3 1/5] x86/microcode/intel: Check against CPU signature before saving microcode Ashok Raj
2022-08-17 7:43 ` Ingo Molnar
2022-08-17 10:45 ` Ashok Raj
2022-08-19 10:24 ` Borislav Petkov
2022-08-23 11:13 ` Ashok Raj
2022-08-24 19:27 ` Borislav Petkov
2022-08-25 3:27 ` Ashok Raj
2022-08-26 16:24 ` Borislav Petkov
2022-08-26 17:18 ` Ashok Raj
2022-08-26 17:29 ` Borislav Petkov
2022-08-17 5:11 ` [PATCH v3 2/5] x86/microcode/intel: Allow a late-load only if a min rev is specified Ashok Raj
2022-08-17 7:45 ` Ingo Molnar
2022-08-19 11:11 ` Borislav Petkov
2022-08-23 0:08 ` Ashok Raj
2022-08-24 19:52 ` Borislav Petkov
2022-08-25 4:02 ` Ashok Raj
2022-08-26 12:09 ` Borislav Petkov
2022-08-17 5:11 ` [PATCH v3 3/5] x86/microcode: Avoid any chance of MCE's during microcode update Ashok Raj
2022-08-17 7:41 ` Ingo Molnar
2022-08-17 7:58 ` Ingo Molnar
2022-08-17 8:09 ` Borislav Petkov
2022-08-17 11:57 ` Ashok Raj
2022-08-17 12:10 ` Borislav Petkov
2022-08-17 12:30 ` Ashok Raj
2022-08-17 14:19 ` Borislav Petkov
2022-08-17 15:06 ` Ashok Raj
2022-08-29 14:23 ` Andy Lutomirski
2022-08-17 11:40 ` Ashok Raj [this message]
2022-08-17 5:11 ` [PATCH v3 4/5] x86/x2apic: Support x2apic self IPI with NMI_VECTOR Ashok Raj
2022-08-17 5:11 ` [PATCH v3 5/5] x86/microcode: Place siblings in NMI loop while update in progress Ashok Raj
2022-08-30 19:15 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YvzTsxilM1kUGeFQ@araj-dh-work \
--to=ashok.raj@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=jacob.jun.pan@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.