Hi Patrick,
On Tue, Oct 08, 2019 at 09:50:09AM +0200, Patrick Rudolph wrote:
I proposed the following patch [1], but it turns out that there are different opinions about updating microcode in parallel.
See the functions microcode_reload_late() and __reload_late() here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...
This is Ashok's latest proposal which seems to work so far. :)
In total there are four ways and only one can be correct:
- Up to now coreboot updated all threads in parallel without a lock.
That seems to follow Intel SDM (Order Number: 253668-070US) Chapter 8.7.11
Yes, you don't need to grab a lock but ...
- According to Intel SDM (Order Number: 253668-070US) Chapter
9.11.6.3 microcode updates must only be done on one thread for each core, as long as the sibling thread doesn't do an update at time.
... yes, you need to update on only one thread of a HT core.
- The kernel patch [2] states that the sibling thread must be idle
while updating microcode on one core.
Yes, that's why we're doing the stop_machine() thing which IPIs all threads into __reload_late() and we hold them there or let them update, depending on whether they're HT0 or not. The second call to apply_microcode_local() simply updates the ucode revision number for the thread calling it and exits early.
- The "Bios Writers Guide" (Document Number 504790 / 550049) states
that microcode must be done on all threads, but synchronized between sibling threads to only update one at a time.
I think that's wrong, if the above code is correct.
But this is what I've gathered from recent discussions. I'll let Intel people correct me if I've missed or misrepresented something.
HTH.