Re: [patch 0/4] x86: AMD microcode patch loading v2 fixes

[Max Krasnyansky]

Dmitry Adamushko wrote:
> 2008/7/29 Peter Oruba <peter.oruba@xxxxxxx>:
> > Fixed coding style issues.
>
> I have a comment on the abstraction layer (microcode_ops).
>
> [ Not that I've looked very carefully at it so far, nor I pretend to
> be at-ease with this 'microcode' topic to make any design judgements
> :-) ]
>
> but would it be somehow possible to not have set_cpus_allowed_ptr()
> code in arch-dependent parts? Let's say the mechanism of how to run
> certain arch-specific code (and synchronization) on a given cpu should
> be a prerogative of (and placed in) the generic part...
>
> Note, this code will likely happily give you an oops if you run
> cpu_down/up() ;-)
>
> I also wondered, is there a requirement that when a new cpu is brought
> up, microcode updates {should,must} be done as early as possible, say
> before any tasks have a chance to run on it? Or can the update be a
> bit delayed? e.g. we don't do it from cpu-hotplug handlers.

Dmitry looks like you missed my email. I already asked that question and 
proposed a couple of options (workqueue and ipi).
Tigran said that he does not know. Maybe Peter does.

My guess is that it does not have to be done synchronously and can be 
delayed. There is no guaranty that microcode CPU hotplug handler will 
run before all the other handlers. Which by definition means that some 
things will start running on the cpu before the microcode is updated. 
Hence we might as well do the update outside of the cpu hotplug path.

Max


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/