From: Henrique de Moraes Holschuh <email@example.com> To: Borislav Petkov <firstname.lastname@example.org> Cc: X86 ML <email@example.com>, Arjan Van De Ven <firstname.lastname@example.org>, Ashok Raj <email@example.com>, Tom Lendacky <firstname.lastname@example.org>, LKML <email@example.com> Subject: Re: [PATCH 7/7] x86/microcode: Synchronize late microcode loading Date: Wed, 28 Feb 2018 10:59:31 -0300 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> 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
next prev parent 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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.