Re: [PATCH] x86 microcode: work_on_cpu and cleanup of the synchronization logic

[Hugh Dickins <hugh@veritas.com>]

On Fri, 24 Apr 2009, Dmitry Adamushko wrote:
> 2009/4/23 Hugh Dickins <hugh@veritas.com>:
> >
> > I guess your mutex Synchronization works out, but are interrupts
> > still disabled around the critical wrmsr()s, wherever they're getting
> > called from?
> 
> Yes, *msr() calls are only done from functions that are now being
> called via smp_call_function_single(). The later seems to always do it
> with disabled interrupts. The only exception is mc_sysdev_resume()
> calling  ->apply_microcode() directly but this one in turn is always
> called with disabled interrupts.
> 
> But now that you mentioned it I wonder if we may actually need a
> spinlock there... can we have multi-threaded cpus/cores with (all |
> some) shared msr registers?

Good thinking, yes we can and do, unless I'm misinterpreting the
evidence.  Though P4 Xeon and Atom startup messages give the opposite
impression, claiming to update all cpus from lower revision, more
careful tests starting from "maxcpus=1" and then "echo 1 >online"
(which, unless you've fiddled around putting the microcode_ctl'ed
microcode.dat into /lib/firmware/intel-ucode/wherever, isn't able
to update at online time on Intel) shows that the later onlined
siblings already have the updated microcode applied to their
previously onlined siblings.  Which isn't surprising, but I'd
been lulled into thinking the opposite by the startup sequence.

Please add "HT versus not" to my earlier list of confusions.

microcode_mutex still covers most cases: is it the case of onlining
two threads at the same time that slips through?  Is that permitted
at the outer level?  Though even if it is, I'd feel safest to have
the spin_lock_irqsaves back (or if not, comment to say why not needed).

Hugh