From: Max Krasnyansky <maxk@qualcomm.com>
To: Peter Oruba <peter.oruba@amd.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Tigran Aivazian <tigran@aivazian.fsnet.co.uk>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [patch 10/11] [PATCH 10/11] x86: Major refactoring.
Date: Mon, 28 Jul 2008 12:36:49 -0700 [thread overview]
Message-ID: <488E1FD1.8060902@qualcomm.com> (raw)
In-Reply-To: <20080728164449.234580245@amd.com>
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
next prev parent reply other threads:[~2008-07-28 19:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-28 16:44 [patch 00/11] x86: AMD microcode patch loading support v2 Peter Oruba
2008-07-28 16:44 ` [patch 02/11] [PATCH 02/11] x86: Moved Intel microcode patch loader declarations to seperate header file Peter Oruba
2008-07-28 16:44 ` [patch 03/11] [PATCH 03/11] x86: Typedef removal Peter Oruba
2008-07-28 16:44 ` [patch 04/11] [PATCH 04/11] x86: Moved per CPU microcode structure declaration to header file Peter Oruba
2008-07-28 16:44 ` [patch 05/11] [PATCH 05/11] x86: Moved microcode.c to microcode_intel.c Peter Oruba
2008-09-07 19:08 ` Arjan van de Ven
2008-09-12 11:54 ` Peter Oruba
2008-09-12 13:35 ` Arjan van de Ven
2008-09-12 13:53 ` Giacomo A. Catenazzi
2008-09-19 11:59 ` Peter Oruba
2008-09-19 12:37 ` Dmitry Adamushko
2008-09-19 12:58 ` Giacomo A. Catenazzi
2008-09-19 13:03 ` Peter Oruba
2008-09-19 13:52 ` Giacomo A. Catenazzi
2008-09-20 6:11 ` Ingo Molnar
2008-09-19 14:06 ` Giacomo A. Catenazzi
2008-09-19 14:29 ` Arjan van de Ven
2008-09-20 6:07 ` Ingo Molnar
2008-09-19 13:07 ` Arjan van de Ven
2008-07-28 16:44 ` [patch 06/11] [PATCH 06/11] x86: Code split to two parts Peter Oruba
2008-07-28 16:44 ` [patch 07/11] [PATCH 07/11] x86: Structure declaration renaming Peter Oruba
2008-07-28 16:44 ` [patch 08/11] [PATCH 08/11] x86: Add AMD specific declarations Peter Oruba
2008-07-28 16:44 ` [patch 09/11] [PATCH 09/11] x86: First step of refactoring, introducing microcode_ops Peter Oruba
2008-07-28 16:44 ` [patch 10/11] [PATCH 10/11] x86: Major refactoring Peter Oruba
2008-07-28 19:36 ` Max Krasnyansky [this message]
2008-07-28 19:50 ` Tigran Aivazian
2008-07-28 16:44 ` [patch 11/11] [PATCH 11/11] x86: AMD microcode patch loading support Peter Oruba
2008-07-28 18:01 ` [patch 00/11] x86: AMD microcode patch loading support v2 Ingo Molnar
2008-07-29 8:10 ` [PATCH] x86, microcode support: fix build error Ingo Molnar
2008-07-29 8:10 ` [patch 00/11] x86: AMD microcode patch loading support v2 Ingo Molnar
2008-07-29 8:10 ` Ingo Molnar
2008-07-29 8:12 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=488E1FD1.8060902@qualcomm.com \
--to=maxk@qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peter.oruba@amd.com \
--cc=tglx@linutronix.de \
--cc=tigran@aivazian.fsnet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.