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    [W:0.024 / U:0.472 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site