All of lore.kernel.org
 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 14:48:48 -0300	[thread overview]
Message-ID: <20180228174848.cs5jn2y7nzh6pu6u@khazad-dum.debian.net> (raw)
In-Reply-To: <20180228140806.GD3769@pd.tnic>

On Wed, 28 Feb 2018, Borislav Petkov wrote:
> On Wed, Feb 28, 2018 at 10:59:31AM -0300, Henrique de Moraes Holschuh wrote:
> > 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
> 
> I think *you* should relax. :)

Well, I don't expect any general-use distro to unleash late loading on
the users, certainly :-)  Least of all, Debian...  It is, nowadays, "use
it only if you know what you're doing" land.

But it is not yet sufficiently documented as such, I fear.

> Late microcode loading on a long running box is not something you do
> more than 2-3 times a year. And if the box needs to restart, it'll get
> the early microcode.

Sure, but the thing is so damn expensive (and the time it takes is
directly proportional to the number of cores, thus likely to hurt worse
exactly those who would want to use it), that I was left wondering if it
should not be optimized further to do the work in parallel (if that can
be made safe enough).

Besides, we likely don't want to have early microcode updates end up
being the reason AP bringup has to be serialized during boot either (and
it *is* likely to dominate the time taken for AP bringup, too!), so it
would be nice to have a way to make parallel microcode updates possible
in general...  but I don't think we're there, yet.

No matter. I am not opposing the patch in the first place.  And any
paralell microcode update work would be best done in an incremental
fashion, on top of working serial updates, anyway.

> And yes, this is addressing *late* loading, if you haven't noticed yet.

I did get that message, yes :)

> So keep doing the early method and you'll be fine.

We need that in the documentation :-P  Microcode updates have always
been somewhat slow, but now they are potentially going to be *much* more
painful and noticeable in the late-update case...

-- 
  Henrique Holschuh

  reply	other threads:[~2018-02-28 17:48 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
2018-02-28 14:08     ` Borislav Petkov
2018-02-28 17:48       ` Henrique de Moraes Holschuh [this message]
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=20180228174848.cs5jn2y7nzh6pu6u@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 \
    --subject='Re: [PATCH 7/7] x86/microcode: Synchronize late microcode loading' \
    /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

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.