From: Jiri Olsa <jolsa@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>, Andi Kleen <ak@linux.intel.com>,
lkml <linux-kernel@vger.kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>
Subject: Re: [RFC,PATCH] VMWARE faults on accessing disabled counters
Date: Wed, 31 Aug 2016 15:19:24 +0200 [thread overview]
Message-ID: <20160831131924.GA2801@krava> (raw)
In-Reply-To: <20160831131104.GC10153@twins.programming.kicks-ass.net>
On Wed, Aug 31, 2016 at 03:11:04PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 31, 2016 at 02:03:58PM +0200, Jiri Olsa wrote:
> > hi,
> > when booting under VMWARE we've got following dmesg lines:
> >
> > [ 0.051567] perf_event_intel: CPUID marked event: 'cpu cycles' unavailable
> > [ 0.051567] perf_event_intel: CPUID marked event: 'instructions' unavailable
> > [ 0.051568] perf_event_intel: CPUID marked event: 'bus cycles' unavailable
> > [ 0.051568] perf_event_intel: CPUID marked event: 'cache references' unavailable
> > [ 0.051569] perf_event_intel: CPUID marked event: 'cache misses' unavailable
> > [ 0.051570] perf_event_intel: CPUID marked event: 'branch instructions' unavailable
> > [ 0.051570] perf_event_intel: CPUID marked event: 'branch misses' unavailable
> >
> > that means all the architectural events are disabled by CPUID(0xa)
> >
> > The kernel code sets intel_perfmon_event_map to prevent
> > those event to be configured by PERF_TYPE_HARDWARE pmu
> > type. However they can still be configured by via
> > PERF_TYPE_RAW type.
> >
> > We're getting GP fault on VMWARE when reading cycles PMC
> > configured throgh the PERF_TYPE_RAW interface:
> >
> > #4 [ffff88007c603e10] do_general_protection at ffffffff8163da9e
> > #5 [ffff88007c603e40] general_protection at ffffffff8163d3a8
> > [exception RIP: native_read_pmc+6]
> > RIP: ffffffff81058d66 RSP: ffff88007c603ef0 RFLAGS: 00010083
> > RAX: ffffffff81957ee0 RBX: 0000000000000000 RCX: 0000000040000002
> > RDX: 000000000ff8f719 RSI: ffff88007c617fa8 RDI: 0000000040000002
> > RBP: ffff88007c603ef0 R8: 00007ffde5053150 R9: 0000000000000000
> > R10: 00007ffde5052530 R11: 00007fbb22aedc70 R12: ffffffff80000001
> > R13: ffff880079b74400 R14: ffff880079b74578 R15: 0000000000000010
> > ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0000
> > #6 [ffff88007c603ef8] x86_perf_event_update at ffffffff81029e03
> > #7 [ffff88007c603f30] x86_pmu_read at ffffffff8102a079
> > #8 [ffff88007c603f40] __perf_event_read at ffffffff811590de
> >
> > I couldn't find what real HW rdpmc does on this situation,
> > so I'm not sure if we actually want to prevent this.. patch
> > below tries to catch this case.
>
> Typically real hardware allows you to program any old crap. The results,
> as in what the counter does, is undefined. Some actually count, some do
> not.
>
> I'm not exactly thrilled by this patch, it adds a lot of code for a
> weird case. What happens when you stuff another non existing even in? GP
> again?
I guess if real HW does not fault on this we dont need to bother,
and treat it as the VMWARE issue.. but I couldn't find this info
jirka
next prev parent reply other threads:[~2016-08-31 13:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-31 12:03 [RFC,PATCH] VMWARE faults on accessing disabled counters Jiri Olsa
2016-08-31 13:11 ` Peter Zijlstra
2016-08-31 13:19 ` Jiri Olsa [this message]
2016-08-31 13:41 ` Peter Zijlstra
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=20160831131924.GA2801@krava \
--to=jolsa@redhat.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).