lkml.org 
[lkml]   [2008]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 10/11] [PATCH 10/11] x86: Major refactoring.
Peter Oruba wrote:
> Refactored code by introducing a two-module solution. There is one
> general module in which vendor specific modules can hook into.
> However, that is exclusive, there is only one vendor specific module
> allowed at a time. A CPU vendor check makes sure only the corect
> module for the underlying system gets called. Functinally in terms
> of patch loading itself there are no changes. This refactoring
> provides a basis for future implementations of other vendors'
> patch loaders.
>
> Signed-off-by: Peter Oruba <peter.oruba@amd.com>
<snip>

> diff --git a/arch/x86/kernel/microcode.c b/arch/x86/kernel/microcode.c
> index c1047d7..1e42e79 100644
> --- a/arch/x86/kernel/microcode.c
> +++ b/arch/x86/kernel/microcode.c
<snip>

> @@ -244,9 +243,9 @@ static void microcode_init_cpu(int cpu, int resume)
>
> set_cpus_allowed_ptr(current, newmask);
> mutex_lock(&microcode_mutex);
> - collect_cpu_info(cpu);
> + microcode_ops->collect_cpu_info(cpu);
> if (uci->valid && system_state == SYSTEM_RUNNING && !resume)
> - cpu_request_microcode(cpu);
> + microcode_ops->cpu_request_microcode(cpu);
> mutex_unlock(&microcode_mutex);
> set_cpus_allowed_ptr(current, &old);
> @@ -274,7 +273,7 @@ static ssize_t reload_store(struct sys_device *dev,
>
> mutex_lock(&microcode_mutex);
> if (uci->valid)
> - err = cpu_request_microcode(cpu);
> + err = microcode_ops->cpu_request_microcode(cpu);
> mutex_unlock(&microcode_mutex);
> put_online_cpus();
> set_cpus_allowed_ptr(current, &old);

Peter, question while we're at it. This came up in another thread and I
asked the same question to Tigran but he is either on vacation or not
paying attention :).

Microcode cpu hotplug handler is messing with the cps_allowed flags of a
random process and can race with sched_setaffinity() (pointed by
Dmitry). It also makes some assumptions on the overall cpu hotplug
sequence which is bad.

It's easy to fix but the question is - does the microcode update need to
happen synchronously ? I'm thinking that it does not but I wanted to
verify that. If it does not need to be synchronous then we can simply
schedule a work queue and do the update there. If it does we could do
collect_cpu_info() and load_microcode() in the IPIs.

Max


\
 
 \ /
  Last update: 2008-07-28 21:39    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean