public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	x86@kernel.org, Borislav Petkov <bp@alien8.de>,
	Ashok Raj <ashok.raj@intel.com>,
	Arjan van de Ven <arjan@linux.intel.com>
Subject: Re: [patch 28/30] x86/microcode: Handle "offline" CPUs correctly
Date: Sat, 12 Aug 2023 18:47:03 +0200	[thread overview]
Message-ID: <875y5kgqd4.ffs@tglx> (raw)
In-Reply-To: <874jl5j4y2.ffs@tglx>

On Fri, Aug 11 2023 at 11:36, Thomas Gleixner wrote:
> On Thu, Aug 10 2023 at 22:46, Peter Zijlstra wrote:
> OTOH, it's not really required. Right now we mandate that _all_ present
> cores have at least one sibling online. For simplicity (and practical
> reasons - think "nosmt") we require the "primary" thread to be online.
>
> Microcode is strict per core, no matter how many threads are there. We
> would not need any of this mess if Intel would have synchronized the
> threads on microcode update like AMD does. This is coming with future
> CPUs which advertise "uniform" update with a scope ranging from core,
> package to systemwide.

Which still requires the "offline" CPU treatment as the siblings are not
allowed to sit in MWAIT or HLT. So this whole NMI exercise is bound to
stay.

Thanks,

        tglx


  reply	other threads:[~2023-08-12 16:47 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
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 [this message]
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=875y5kgqd4.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=arjan@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --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