mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ashok Raj <ashok.raj@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>, <x86@kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Ashok Raj <ashok.raj@intel.com>
Subject: Re: [patch 28/30] x86/microcode: Handle "offline" CPUs correctly
Date: Thu, 10 Aug 2023 14:49:39 -0700	[thread overview]
Message-ID: <ZNVbc7qy8k49Dwhi@araj-mobl.amr.corp.intel.com> (raw)
In-Reply-To: <20230810210511.GH212435@hirez.programming.kicks-ass.net>

On Thu, Aug 10, 2023 at 11:05:11PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 10, 2023 at 01:50:17PM -0700, Ashok Raj wrote:
> > On Thu, Aug 10, 2023 at 10:46:05PM +0200, Peter Zijlstra wrote:
> > > On Thu, Aug 10, 2023 at 08:38:07PM +0200, Thomas Gleixner wrote:
> > > 
> > > >  	for_each_cpu_and(cpu, cpu_present_mask, &cpus_booted_once_mask) {
> > > > +		/*
> > > > +		 * Offline CPUs sit in one of the play_dead() functions
> > > > +		 * with interrupts disabled, but they still react on NMIs
> > > > +		 * and execute arbitrary code. Also MWAIT being updated
> > > > +		 * while the offline CPU sits there is not necessarily safe
> > > > +		 * on all CPU variants.
> > > > +		 *
> > > > +		 * Mark them in the offline_cpus mask which will be handled
> > > > +		 * by CPU0 later in the update process.
> > > > +		 *
> > > > +		 * Ensure that the primary thread is online so that it is
> > > > +		 * guaranteed that all cores are updated.
> > > > +		 */
> > > >  		if (!cpu_online(cpu)) {
> > > > +			if (topology_is_primary_thread(cpu) || !allow_smt_offline) {
> > > > +				pr_err("CPU %u not online, loading aborted\n", cpu);
> > > 
> > > We could make the NMI handler do the ucode load, no? Also, you just need
> > > any thread online, don't particularly care about primary thread or not
> > > afaict.
> > 
> > Patch 25 does that load in NMI. You are right, we just need "a" CPU in each
> > core online. 
> 
> Patch 25 does it for online CPUs, offline CPUs are having a separate
> code path:
> 
>   microcode_nmi_handler()
> 
> vs
> 
>   microcode_offline_nmi_handler()

Since the code enforces all primary CPUs to be ONLINE, the secondaries are the
other thread of the same core. So they automatically get the update when
primary does it. 

The secondaries are parked in NMI just to avoid the risk of executing code
that might be patched by primary.

Or maybe you had something else in mind. 

  reply	other threads:[~2023-08-10 21:49 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-10 18:37 [patch 00/30] x86/microcode: Cleanup and late loading enhancements Thomas Gleixner
2023-08-10 18:37 ` [patch 01/30] x86/mm: Remove unused microcode.h include Thomas Gleixner
2023-08-10 18:37 ` [patch 02/30] x86/microcode: Hide the config knob Thomas Gleixner
2023-08-10 20:41   ` Ashok Raj
2023-08-11 11:22     ` Borislav Petkov
2023-08-10 18:37 ` [patch 03/30] x86/microcode/intel: Move microcode functions out of cpu/intel.c Thomas Gleixner
2023-08-10 18:37 ` [patch 04/30] x86/microcode: Include vendor headers into microcode.h Thomas Gleixner
2023-08-10 18:37 ` [patch 05/30] x86/microcode: Make reload_early_microcode() static Thomas Gleixner
2023-08-10 18:37 ` [patch 06/30] x86/microcode/intel: Rename get_datasize() since its used externally Thomas Gleixner
2023-08-10 18:37 ` [patch 07/30] x86/microcode: Move core specific defines to local header Thomas Gleixner
2023-08-10 18:37 ` [patch 08/30] x86/microcode/intel: Rip out mixed stepping support for Intel CPUs Thomas Gleixner
2023-08-11 22:25   ` Borislav Petkov
2023-08-12  7:16     ` Thomas Gleixner
2023-08-10 18:37 ` [patch 09/30] x86/microcode/intel: Remove debug code Thomas Gleixner
2023-08-11 10:45   ` Nikolay Borisov
2023-08-10 18:37 ` [patch 10/30] x86/microcode: Remove pointless mutex Thomas Gleixner
2023-08-10 18:37 ` [patch 11/30] x86/microcode/intel: Simplify scan_microcode() Thomas Gleixner
2023-08-10 18:37 ` [patch 12/30] x86/microcode/intel: Simplify and rename generic_load_microcode() Thomas Gleixner
2023-08-10 18:37 ` [patch 13/30] x86/microcode/intel: Cleanup code further Thomas Gleixner
2023-08-11 11:01   ` Nikolay Borisov
2023-08-10 18:37 ` [patch 14/30] x86/microcode/intel: Simplify early loading Thomas Gleixner
2023-08-10 18:37 ` [patch 15/30] x86/microcode/intel: Save the microcode only after a successful late-load Thomas Gleixner
2023-08-10 18:37 ` [patch 16/30] x86/microcode/intel: Switch to kvmalloc() Thomas Gleixner
2023-08-10 18:37 ` [patch 17/30] x86/microcode/intel: Unify microcode apply() functions Thomas Gleixner
2023-08-10 18:37 ` [patch 18/30] x86/microcode: Handle "nosmt" correctly Thomas Gleixner
2023-08-10 18:37 ` [patch 19/30] x86/microcode: Clarify the late load logic Thomas Gleixner
2023-08-10 18:37 ` [patch 20/30] x86/microcode: Sanitize __wait_for_cpus() Thomas Gleixner
2023-08-10 18:37 ` [patch 21/30] x86/microcode: Add per CPU result state Thomas Gleixner
2023-08-10 18:37 ` [patch 22/30] x86/microcode: Add per CPU control field Thomas Gleixner
2023-08-10 18:38 ` [patch 23/30] x86/microcode: Provide new control functions Thomas Gleixner
2023-08-10 20:25   ` Peter Zijlstra
2023-08-10 18:38 ` [patch 24/30] x86/microcode: Replace the all in one rendevouz handler Thomas Gleixner
2023-08-10 18:38 ` [patch 25/30] x86/microcode: Rendezvous and load in NMI Thomas Gleixner
2023-08-10 18:38 ` [patch 26/30] x86/microcode: Protect against instrumentation Thomas Gleixner
2023-08-10 20:36   ` Peter Zijlstra
2023-08-11  9:19     ` Thomas Gleixner
2023-08-10 18:38 ` [patch 27/30] x86/apic: Provide apic_force_nmi_on_cpu() Thomas Gleixner
2023-08-10 18:38 ` [patch 28/30] x86/microcode: Handle "offline" CPUs correctly Thomas Gleixner
2023-08-10 20:46   ` Peter Zijlstra
2023-08-10 20:50     ` Ashok Raj
2023-08-10 21:05       ` Peter Zijlstra
2023-08-10 21:49         ` Ashok Raj [this message]
2023-08-10 22:29           ` Peter Zijlstra
2023-08-10 23:02             ` Ashok Raj
2023-08-11  1:19               ` Thomas Gleixner
2023-08-11  1:31                 ` Thomas Gleixner
2023-08-11  9:36     ` Thomas Gleixner
2023-08-12 16:47       ` Thomas Gleixner
2023-08-10 18:38 ` [patch 29/30] x86/microcode: Prepare for minimal revision check Thomas Gleixner
2023-08-10 20:54   ` Peter Zijlstra
2023-08-11  9:38     ` Thomas Gleixner
2023-08-11 14:20     ` Arjan van de Ven
2023-08-10 18:38 ` [patch 30/30] x86/microcode/intel: Add a minimum required revision for late-loads Thomas Gleixner

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=ZNVbc7qy8k49Dwhi@araj-mobl.amr.corp.intel.com \
    --to=ashok.raj@intel.com \
    --cc=arjan@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®