linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Borislav Petkov <bp@alien8.de>
Cc: X86 ML <x86@kernel.org>,
	Arjan Van De Ven <arjan.van.de.ven@intel.com>,
	Ashok Raj <ashok.raj@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 7/7] x86/microcode: Synchronize late microcode loading
Date: Wed, 28 Feb 2018 10:59:31 -0300	[thread overview]
Message-ID: <20180228135931.uwveegfdv5afozxe@khazad-dum.debian.net> (raw)
In-Reply-To: <20180228102846.13447-8-bp@alien8.de>

On Wed, 28 Feb 2018, Borislav Petkov wrote:
> + * Late loading dance. Why the heavy-handed stomp_machine effort?
> + *
> + * - HT siblings must be idle and not execute other code while the other sibling
> + *   is loading microcode in order to avoid any negative interactions caused by
> + *   the loading.
> + *
> + * - In addition, microcode update on the cores must be serialized until this
> + *   requirement can be relaxed in the future. Right now, this is conservative
> + *   and good.

Eek! If I read that right, this effectively halts the entire box until
every core is updated, with one core entering deep-coma at a time (the
rest are left either spinning or cpu_relax()ing depending on whether
they have already updated or not)?

If this is correct, I shudder at what it would do on a server with
dozens, or hundreds of cores...  According to Ben Hawkes' paper, Intel's
on-die microcode update loader takes linear time relative to the update
size to do the crypto dance.

On my single-xeon X5550 workstation, which should be relatively fast
since its microcode update is small, the whole thing would take about
3,2 million cycles (circa 800k cycles per core, 4 cores, skipping
hyperthreads) to do a sync late update.  I don't believe this has
changed much, but I *did not* test, e.g., a Skylake Xeon, or anything
newer than that Xeon X5550.

Anyway, maybe there is a safe way to do it in a more parallel fashion
based on cpu topology?

AFAIK, it is not like there is any way to make OS microcode updates
(early or late) safe against SMIs and NMIs hitting the sibling
hyperthread while updating the other, so we don't have to care about
*that* nasty corner case simply because we can't avoid it in the first
place.

Hopefully AMD has none of those pitfalls, and could just trigger an
update on half the cores at a time, easily bounding it to approximately
twice the time it takes to update a single core :-(

-- 
  Henrique Holschuh

  reply	other threads:[~2018-02-28 13:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-28 10:28 [PATCH 0/7] x86/microcode: Improve late loading Borislav Petkov
2018-02-28 10:28 ` [PATCH 1/7] x86/microcode: Get rid of struct apply_microcode_ctx Borislav Petkov
2018-03-08  9:25   ` [tip:x86/pti] " tip-bot for Borislav Petkov
2018-02-28 10:28 ` [PATCH 2/7] x86/microcode/intel: Check microcode revision before updating sibling threads Borislav Petkov
2018-03-08  9:25   ` [tip:x86/pti] " tip-bot for Ashok Raj
2018-02-28 10:28 ` [PATCH 3/7] x86/microcode/intel: Writeback and invalidate caches before updating microcode Borislav Petkov
2018-03-08  9:26   ` [tip:x86/pti] " tip-bot for Ashok Raj
2018-02-28 10:28 ` [PATCH 4/7] x86/microcode: Do not upload microcode if CPUs are offline Borislav Petkov
2018-02-28 13:11   ` Henrique de Moraes Holschuh
2018-02-28 13:26     ` Raj, Ashok
2018-02-28 19:07       ` Henrique de Moraes Holschuh
2018-03-05 22:06   ` Tom Lendacky
2018-03-08  9:26   ` [tip:x86/pti] " tip-bot for Ashok Raj
2018-02-28 10:28 ` [PATCH 5/7] x86/microcode/intel: Look into the patch cache first Borislav Petkov
2018-03-08  9:27   ` [tip:x86/pti] " tip-bot for Borislav Petkov
2018-02-28 10:28 ` [PATCH 6/7] x86/microcode: Request microcode on the BSP Borislav Petkov
2018-03-05 22:08   ` Tom Lendacky
2018-03-08  9:27   ` [tip:x86/pti] " tip-bot for Borislav Petkov
2018-02-28 10:28 ` [PATCH 7/7] x86/microcode: Synchronize late microcode loading Borislav Petkov
2018-02-28 13:59   ` Henrique de Moraes Holschuh [this message]
2018-02-28 14:08     ` Borislav Petkov
2018-02-28 17:48       ` Henrique de Moraes Holschuh
2018-03-05 22:09   ` Tom Lendacky
2018-03-08  9:28   ` [tip:x86/pti] " tip-bot for Ashok Raj
2018-03-05 22:12 ` [PATCH 0/7] x86/microcode: Improve late loading Tom Lendacky
2018-03-05 23:51   ` Raj, Ashok

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=20180228135931.uwveegfdv5afozxe@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=arjan.van.de.ven@intel.com \
    --cc=ashok.raj@intel.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas.lendacky@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).