From: Yinghai Lu <yinghai@kernel.org>
To: Ingo Molnar <mingo@elte.hu>,
Jason Wessel <jason.wessel@windriver.com>,
Peter Zijlstra <peterz@infradead.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Don Zickus <dzickus@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: perf hw in kexeced kernel broken in tip
Date: Wed, 01 Dec 2010 00:00:21 -0800 [thread overview]
Message-ID: <4CF60095.1020900@kernel.org> (raw)
First kernel:
[ 1.139418] calling init_hw_perf_events+0x0/0xb77 @ 1
[ 1.159111] Performance Events: PEBS fmt1+, Nehalem events, Intel PMU
driver.
[ 1.159567] ... version: 3
[ 1.179121] ... bit width: 48
[ 1.179353] ... generic registers: 4
[ 1.179593] ... value mask: 0000ffffffffffff
[ 1.199211] ... max period: 000000007fffffff
[ 1.199554] ... fixed-purpose events: 3
[ 1.219108] ... event mask: 000000070000000f
[ 1.219454] initcall init_hw_perf_events+0x0/0xb77 returned 0 after
11719 usecs
.....
[ 20.220997] checking TSC synchronization [CPU#0 -> CPU#11]: passed.
[ 20.260818] NMI watchdog enabled, takes one hw-pmu counter.
kexeced kernel.
[ 1.169470] calling init_hw_perf_events+0x0/0xb77 @ 1
[ 1.189265] Performance Events: PEBS fmt1+, Nehalem events, Broken
PMU hardware detected, software events only.
...
[ 21.010407] NMI watchdog failed to create perf event on cpu14:
fffffffffffffffe
caused by:
commit 33c6d6a7ad0ffab9b1b15f8e4107a2af072a05a0
Author: Don Zickus <dzickus@redhat.com>
Date: Mon Nov 22 16:55:23 2010 -0500
x86, perf, nmi: Disable perf if counters are not accessible
In a kvm virt guests, the perf counters are not emulated. Instead they
return zero on a rdmsrl. The perf nmi handler uses the fact that
crossing
a zero means the counter overflowed (for those counters that do not have
specific interrupt bits). Therefore on kvm guests, perf will swallow all
NMIs thinking the counters overflowed.
This causes problems for subsystems like kgdb which needs NMIs to do its
magic. This problem was discovered by running kgdb tests.
The solution is to write garbage into a perf counter during the
initialization and hopefully reading back the same number. On kvm
guests, the value will be read back as zero and we disable perf as
a result.
Reported-by: Jason Wessel <jason.wessel@windriver.com>
Patch-inspired-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
LKML-Reference: <1290462923-30734-1-git-send-email-dzickus@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
diff --git a/arch/x86/kernel/cpu/perf_event.c
b/arch/x86/kernel/cpu/perf_event.c
index ed63101..6d75b91 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -381,6 +381,20 @@ static void release_pmc_hardware(void) {}
#endif
+static bool check_hw_exists(void)
+{
+ u64 val, val_new = 0;
+ int ret = 0;
+
+ val = 0xabcdUL;
+ ret |= checking_wrmsrl(x86_pmu.perfctr, val);
+ ret |= rdmsrl_safe(x86_pmu.perfctr, &val_new);
+ if (ret || val != val_new)
+ return false;
+
+ return true;
+}
+
static void reserve_ds_buffers(void);
static void release_ds_buffers(void);
@@ -1372,6 +1386,12 @@ void __init init_hw_perf_events(void)
pmu_check_apic();
+ /* sanity check that the hardware exists or is emulated */
+ if (!check_hw_exists()) {
+ pr_cont("Broken PMU hardware detected, software events
only.\n");
+ return;
+ }
+
pr_cont("%s PMU driver.\n", x86_pmu.name);
if (x86_pmu.quirks)
next reply other threads:[~2010-12-01 8:02 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-01 8:00 Yinghai Lu [this message]
2010-12-01 11:27 ` perf hw in kexeced kernel broken in tip Peter Zijlstra
2010-12-01 16:06 ` Vivek Goyal
2010-12-01 16:11 ` Peter Zijlstra
2010-12-01 16:23 ` Vivek Goyal
2010-12-01 19:38 ` Peter Zijlstra
2010-12-01 19:46 ` Vivek Goyal
2010-12-01 19:49 ` Peter Zijlstra
2010-12-01 19:58 ` Vivek Goyal
2010-12-01 20:07 ` Peter Zijlstra
2010-12-01 21:48 ` Eric W. Biederman
2010-12-02 5:23 ` Don Zickus
2010-12-02 7:34 ` Peter Zijlstra
2010-12-02 16:15 ` Don Zickus
2010-12-07 23:30 ` Peter Zijlstra
2010-12-08 14:01 ` Don Zickus
2010-12-08 14:20 ` Peter Zijlstra
2010-12-08 14:42 ` Vivek Goyal
2010-12-08 14:48 ` Peter Zijlstra
2010-12-08 15:02 ` Vivek Goyal
2010-12-08 15:15 ` Peter Zijlstra
2010-12-08 15:22 ` Vivek Goyal
2010-12-08 21:16 ` Eric W. Biederman
2010-12-08 14:59 ` Peter Zijlstra
2010-12-08 18:43 ` Yinghai Lu
2010-12-08 19:01 ` Don Zickus
2010-12-08 19:05 ` Yinghai Lu
2010-12-08 19:17 ` Peter Zijlstra
2010-12-08 19:20 ` Yinghai Lu
2010-12-08 19:06 ` Peter Zijlstra
2010-12-08 19:20 ` Yinghai Lu
2010-12-08 22:37 ` Don Zickus
2010-12-08 23:20 ` Eric W. Biederman
2010-12-09 4:34 ` Don Zickus
2010-12-09 20:20 ` Don Zickus
2010-12-09 20:44 ` Cyrill Gorcunov
2010-12-08 14:33 ` Peter Zijlstra
2010-12-08 14:39 ` Vivek Goyal
2010-12-07 21:16 ` Don Zickus
2010-12-08 0:26 ` Yinghai Lu
2010-12-08 10:39 ` Peter Zijlstra
2010-12-01 20:41 ` Eric W. Biederman
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=4CF60095.1020900@kernel.org \
--to=yinghai@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=dzickus@redhat.com \
--cc=jason.wessel@windriver.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/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.