From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Oleg Nesterov <oleg@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
mingo@kernel.org
Subject: Re: [RFC][PATCH] perf, intel: Don't touch MSR_IA32_DEBUGCTLMSR from NMI context
Date: Thu, 13 Sep 2012 12:23:09 +0200 [thread overview]
Message-ID: <1347531789.15764.124.camel@twins> (raw)
In-Reply-To: <1347466967.15764.63.camel@twins>
On Wed, 2012-09-12 at 18:22 +0200, Peter Zijlstra wrote:
> Oleg and Sebastian found that touching MSR_IA32_DEBUGCTLMSR from NMI
> context is problematic since the only way to change the various
> unrelated bits in there is:
>
> debugctl = get_debugctlmsr()
> /* frob flags in debugctl */
> update_debugctlmsr(debugctl);
>
> Which is entirely unsafe if we prod at the MSR from NMI context.
>
> In particular the path that is responsible is:
>
> x86_pmu_handle_irq() (NMI handler)
> x86_pmu_stop()
> x86_pmu.disable -> intel_pmu_disable_event()
> intel_pmu_lbr_disable()
> __intel_pmu_lbr_disable()
> wrmsrl(MSR_IA32_DEBUGCTLMSR,... );
>
> So remove intel_pmu_lbr_{en,dis}able() from
> intel_pmu_{en,dis}able_event() and stick them in
> intel_{get,put}_event_constraints() which are only ever called from
> regular contexts.
>
> We combine intel_pmu_needs_lbr_smpl(), which tells us if the events
> wants LBR data, with event->hw.branch_reg.alloc, which given
> intel_shared_regs_constraints() is set if our event got the shared
> resource, to give us a correctly balanced condition in
> {get,put}_event_constraints() for intel_pmu_lbr_{en,dis}able().
>
> Also change core_pmu to only use x86_get_event_constraints since it
> doesn't support any of the fancy DS (BTS,PEBS), LBR and OFFCORE features
> that make up intel_{get,put}_event_constraints.
OK, so with the added stipulation that touching the MSR from the NMI
isn't a problem as long as we ensure we leave the MSR in the same state
that we found it in, and the above is the only path found so far that
could cause this to be violated, the patch is fine?
In particular we could note that both LBR and BTS use the DEBUGCTL MSR,
but BTS doesn't throttle, so the LBR code is the only thing needing
attention as per the above description.
next prev parent reply other threads:[~2012-09-13 10:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 16:22 [RFC][PATCH] perf, intel: Don't touch MSR_IA32_DEBUGCTLMSR from NMI context Peter Zijlstra
2012-09-12 16:42 ` Stephane Eranian
2012-09-12 17:37 ` Peter Zijlstra
2012-09-12 17:45 ` Peter Zijlstra
2012-09-12 18:00 ` Stephane Eranian
2012-09-12 18:17 ` Peter Zijlstra
2012-09-12 18:50 ` Stephane Eranian
2012-09-12 18:52 ` Peter Zijlstra
2012-09-12 19:00 ` Stephane Eranian
2012-09-12 17:36 ` Oleg Nesterov
2012-09-12 17:41 ` Peter Zijlstra
2012-09-13 10:23 ` Peter Zijlstra [this message]
2012-09-13 11:49 ` Stephane Eranian
2012-09-13 12:11 ` 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=1347531789.15764.124.camel@twins \
--to=peterz@infradead.org \
--cc=bigeasy@linutronix.de \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=oleg@redhat.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 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).