Messages in this thread | | | Date | Mon, 28 Jul 2008 12:36:49 -0700 | From | Max Krasnyansky <> | Subject | Re: [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(µcode_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(µcode_mutex); > set_cpus_allowed_ptr(current, &old); > @@ -274,7 +273,7 @@ static ssize_t reload_store(struct sys_device *dev, > > mutex_lock(µcode_mutex); > if (uci->valid) > - err = cpu_request_microcode(cpu); > + err = microcode_ops->cpu_request_microcode(cpu); > mutex_unlock(µcode_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
| |