From: Peter Zijlstra <peterz@infradead.org>
To: Borislav Petkov <borislav.petkov@amd.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Stephane Eranian <eranian@google.com>,
linux-kernel@vger.kernel.org, andi@firstfloor.org, mingo@elte.hu,
ming.m.lin@intel.com,
Andreas Herrmann <andreas.herrmann3@amd.com>,
Dimitri Sivanich <sivanich@sgi.com>,
Dmitry Adamushko <dmitry.adamushko@gmail.com>
Subject: Re: [PATCH] perf/x86: check ucode before disabling PEBS on SandyBridge
Date: Fri, 08 Jun 2012 16:45:18 +0200 [thread overview]
Message-ID: <1339166718.2507.37.camel@laptop> (raw)
In-Reply-To: <20120608143636.GG31359@aftab.osrc.amd.com>
On Fri, 2012-06-08 at 16:36 +0200, Borislav Petkov wrote:
> On Fri, Jun 08, 2012 at 04:20:50PM +0200, Peter Zijlstra wrote:
> > On Fri, 2012-06-08 at 16:15 +0200, Borislav Petkov wrote:
> > > have a variable which gets initialized to the number of all CPUs and
> > > each time ->apply_microcode() finishes by returning 0, we decrement it
> > > once.
> >
> > >
> > > Hmm, I'm probably missing some obscure case.
> >
> > Since its all per-cpu sysfs muck, userspace could update a random
> > subsets of cpus.. leaving us hanging.
>
> I'm afraid I don't understand - when you modprobe microcode.ko,
> it goes and loads /lib/firmware/amd-ucode/microcode_amd.bin (in
> the AMD case) on each CPU when the driver gets regged through
> subsys_interface_register().
>
> It calls ->add_dev() on each CPU - this should be guaranteed because it
> uses the cpu_subsys from drivers/base/cpu.c which onlines all CPUs, I'd
> assume.
>
> So, I'd say that once subsys_interface_register() returns, we have
> updated ucode on all CPUs, if successful...
>
> We probably could run the notifier at that moment, before we do
> put_online_cpus().
I was thinking about reload_store(), that seems to only reload ucode for
a single cpu.
> > The 'bestestet' idea I came up with is doing the verify thing I have
> > from a delayed work -- say 1 second into the future. That way, when
> > there's lots of cpus they all try and enqueue the one work, which at
> > the end executes only once, provided the entire update scan took less
> > than the second.
>
> You're saying, you want the last CPU that gets to update its microcode
> gets to also run the delayed work...? Probably, I'd assume ucode update
> on a single CPU takes less than a second IIUC.
Nah.. it'll probably be the first. But it doesn't matter which cpu does
it. So the idea was:
static void intel_snb_verify_work(struct work_struct *work)
{
/* do the verify thing.. */
}
static DECLARE_DELAYED_WORK(intel_snb_delayed_work, intel_snb_verify_ucode);
static int intel_snb_ucode_notifier(struct notifier_block *self,
unsigned long action, void *_uci)
{
/*
* Since ucode cannot be down-graded, and no future ucode revision
* is known to break PEBS again, we're ok with MICROCODE_CAN_UPDATE.
*/
if (action == MICROCODE_UPDATED)
schedule_delayed_work(&intel_snb_delayed_work, HZ);
return NOTIFY_DONE;
}
Thus it will queue the delayed work when the work isn't already queued
for execution. Resulting in the work only happening once a second (at
most).
next prev parent reply other threads:[~2012-06-08 14:45 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-07 7:15 [PATCH] perf/x86: check ucode before disabling PEBS on SandyBridge Stephane Eranian
2012-06-07 10:18 ` Peter Zijlstra
2012-06-07 10:35 ` Stephane Eranian
2012-06-07 10:45 ` Peter Zijlstra
2012-06-07 10:48 ` Stephane Eranian
2012-06-07 11:15 ` Peter Zijlstra
2012-06-08 9:35 ` Ingo Molnar
2012-06-08 10:00 ` Peter Zijlstra
2012-06-08 10:03 ` Stephane Eranian
2012-06-08 13:26 ` Peter Zijlstra
2012-06-08 13:51 ` Borislav Petkov
2012-06-08 13:54 ` Peter Zijlstra
2012-06-08 14:15 ` Borislav Petkov
2012-06-08 14:20 ` Peter Zijlstra
2012-06-08 14:36 ` Borislav Petkov
2012-06-08 14:45 ` Peter Zijlstra [this message]
2012-06-08 15:09 ` Borislav Petkov
2012-06-08 13:56 ` Peter Zijlstra
2012-06-08 14:03 ` Borislav Petkov
2012-06-08 13:59 ` Peter Zijlstra
2012-06-08 14:03 ` Stephane Eranian
2012-06-08 14:17 ` Borislav Petkov
2012-06-08 16:02 ` H. Peter Anvin
2012-06-08 21:02 ` Henrique de Moraes Holschuh
2012-06-08 21:16 ` Borislav Petkov
2012-06-08 14:07 ` Stephane Eranian
2012-06-08 14:13 ` Peter Zijlstra
2012-06-08 14:19 ` Borislav Petkov
2012-06-08 14:23 ` Peter Zijlstra
2012-06-08 14:26 ` Stephane Eranian
2012-06-08 14:25 ` Peter Zijlstra
2012-06-08 14:26 ` Stephane Eranian
2012-06-12 8:14 ` Stephane Eranian
2012-06-08 16:28 ` Stephane Eranian
2012-06-08 18:49 ` Peter Zijlstra
2012-06-08 16:50 ` Andi Kleen
2012-06-08 18:05 ` Borislav Petkov
2012-06-08 18:52 ` Peter Zijlstra
2012-06-08 20:38 ` Borislav Petkov
2012-06-12 17:07 ` Robert Richter
2012-06-12 17:09 ` Stephane Eranian
2012-06-12 17:13 ` Peter Zijlstra
2012-06-12 17:17 ` Borislav Petkov
2012-06-12 17:18 ` Peter Zijlstra
2012-06-12 17:23 ` Borislav Petkov
2012-06-12 17:26 ` Peter Zijlstra
2012-06-12 17:35 ` Borislav Petkov
2012-06-12 17:40 ` Peter Zijlstra
2012-06-12 18:04 ` Andi Kleen
2012-06-12 20:10 ` Borislav Petkov
2012-06-13 1:04 ` Henrique de Moraes Holschuh
2012-06-13 6:51 ` Borislav Petkov
2012-06-13 12:36 ` Henrique de Moraes Holschuh
2012-06-13 16:11 ` Borislav Petkov
2012-06-13 21:41 ` Henrique de Moraes Holschuh
2012-06-15 12:37 ` Borislav Petkov
2012-06-15 12:42 ` Peter Zijlstra
2012-06-15 12:52 ` Borislav Petkov
2012-06-15 16:52 ` [PATCH] x86, microcode: Make reload interface per system Borislav Petkov
2012-06-15 17:16 ` Peter Zijlstra
2012-06-15 17:49 ` Borislav Petkov
2012-06-19 2:46 ` Henrique de Moraes Holschuh
2012-06-19 3:31 ` H. Peter Anvin
2012-06-19 5:11 ` Borislav Petkov
2012-06-19 8:17 ` Peter Zijlstra
2012-06-19 10:22 ` Borislav Petkov
2012-06-19 10:26 ` Peter Zijlstra
2012-06-19 15:06 ` Borislav Petkov
2012-06-19 15:57 ` H. Peter Anvin
2012-06-19 18:22 ` Henrique de Moraes Holschuh
2012-06-19 20:22 ` H. Peter Anvin
2012-06-20 23:46 ` Henrique de Moraes Holschuh
2012-06-20 23:49 ` H. Peter Anvin
2012-06-21 0:06 ` Henrique de Moraes Holschuh
2012-06-21 0:18 ` H. Peter Anvin
2012-06-21 2:33 ` Henrique de Moraes Holschuh
2012-06-19 5:03 ` Borislav Petkov
2012-06-19 18:57 ` Henrique de Moraes Holschuh
2012-06-19 22:19 ` Borislav Petkov
2012-06-19 2:42 ` [PATCH] perf/x86: check ucode before disabling PEBS on SandyBridge Henrique de Moraes Holschuh
2012-06-12 17:23 ` Robert Richter
2012-06-12 17:15 ` Borislav Petkov
2012-06-07 13:28 ` Andi Kleen
2012-06-07 13:27 ` Andi Kleen
2012-06-12 18:35 ` H. Peter Anvin
2012-06-12 19:07 ` Borislav Petkov
2012-06-12 19:33 ` Peter Zijlstra
2012-06-12 19:35 ` Andi Kleen
2012-06-12 19:49 ` Borislav Petkov
2012-06-12 20:28 ` H. Peter Anvin
2012-06-12 20:37 ` Borislav Petkov
2012-06-12 20:42 ` H. Peter Anvin
2012-06-12 20:56 ` Borislav Petkov
2012-06-12 20:58 ` H. Peter Anvin
2012-06-12 21:04 ` Borislav Petkov
2012-06-13 8:38 ` Peter Zijlstra
2012-06-13 14:00 ` H. Peter Anvin
2012-06-13 15:37 ` Peter Zijlstra
2012-06-13 15:46 ` H. Peter Anvin
2012-06-13 12:39 ` Peter Zijlstra
2012-06-13 13:22 ` H. Peter Anvin
2012-06-13 14:01 ` Henrique de Moraes Holschuh
2012-06-13 8:32 ` Peter Zijlstra
2012-06-13 13:59 ` H. Peter Anvin
2012-06-13 15:32 ` Peter Zijlstra
2012-06-13 15:38 ` H. Peter Anvin
2012-06-12 20:27 ` H. Peter Anvin
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=1339166718.2507.37.camel@laptop \
--to=peterz@infradead.org \
--cc=andi@firstfloor.org \
--cc=andreas.herrmann3@amd.com \
--cc=borislav.petkov@amd.com \
--cc=dmitry.adamushko@gmail.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=mingo@kernel.org \
--cc=sivanich@sgi.com \
/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.