diff mbox

[V2,2/3] perf protect LBR when Intel PT is enabled.

Message ID 1404324855-15166-2-git-send-email-kan.liang@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

kan.liang@intel.com July 2, 2014, 6:14 p.m. UTC 
From: Kan Liang <kan.liang@intel.com>

If RTIT_CTL.TraceEn=1, any attempt to read or write the LBR or LER MSRs, including LBR_TOS, will result in a #GP.
Since Intel PT can be enabled/disabled at runtime, LBR MSRs have to be protected by _safe() at runtime.

Signed-off-by: Kan Liang <kan.liang@intel.com>
---
 arch/x86/kernel/cpu/perf_event.h           |  1 -
 arch/x86/kernel/cpu/perf_event_intel.c     |  3 ---
 arch/x86/kernel/cpu/perf_event_intel_lbr.c | 38 +++++++++++++++++-------------
 3 files changed, 21 insertions(+), 21 deletions(-)

Comments

Andi Kleen July 3, 2014, 2:44 a.m. UTC | #1 
On Wed, Jul 02, 2014 at 11:14:14AM -0700, kan.liang@intel.com wrote:
> From: Kan Liang <kan.liang@intel.com>
> 
> If RTIT_CTL.TraceEn=1, any attempt to read or write the LBR or LER MSRs, including LBR_TOS, will result in a #GP.
> Since Intel PT can be enabled/disabled at runtime, LBR MSRs have to be protected by _safe() at runtime.
> 
> Signed-off-by: Kan Liang <kan.liang@intel.com>

Patch looks good to me.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter Zijlstra July 3, 2014, 7:33 a.m. UTC | #2 
On Wed, Jul 02, 2014 at 11:14:14AM -0700, kan.liang@intel.com wrote:
> From: Kan Liang <kan.liang@intel.com>
> 
> If RTIT_CTL.TraceEn=1, any attempt to read or write the LBR or LER MSRs, including LBR_TOS, will result in a #GP.
> Since Intel PT can be enabled/disabled at runtime, LBR MSRs have to be protected by _safe() at runtime.

Lines are too long, and the reasoning is totally broken.

If there's active LBR users out there, we should refuse to enable PT and
vice versa. What we should not be doing is using _safe and fault and
generate crap.
Andi Kleen July 3, 2014, 3:52 p.m. UTC | #3 
> If there's active LBR users out there, we should refuse to enable PT and
> vice versa. 

This doesn't work, e.g. hardware debuggers can take over at any time.

-Andi
Peter Zijlstra July 3, 2014, 5:07 p.m. UTC | #4 
On Thu, Jul 03, 2014 at 05:52:37PM +0200, Andi Kleen wrote:
> > If there's active LBR users out there, we should refuse to enable PT and
> > vice versa. 
> 
> This doesn't work, e.g. hardware debuggers can take over at any time.

Tough cookies. Hardware debuggers get to deal with whatever crap they
cause.
kan.liang@intel.com July 7, 2014, 1:57 p.m. UTC | #5 
> 
> On Thu, Jul 03, 2014 at 05:52:37PM +0200, Andi Kleen wrote:
> > > If there's active LBR users out there, we should refuse to enable PT
> > > and vice versa.
> >
> > This doesn't work, e.g. hardware debuggers can take over at any time.
> 
> Tough cookies. Hardware debuggers get to deal with whatever crap they
> cause.

If so, I think I may discard this patch (2/3). I will resubmit the other two patches as a patch set to only handle the KVM issue we found.
It checks the access of LBR and extra MSRs at the initialization time and set the flags. So we just need to check the flags at runtime and avoid the protection by _safe(). 

For Intel PT and LBR handling, since the PT codes haven't been integrated yet, I will try to implement another patch later.
The patch will add flags for LBR and PT.
When enabling PT, it checks LBR flag and update the PT flag. When enabling LBR, it checks PT flag and update the LBR flag. When disabling LBR/PT, we just update the related flags. we don't need to add _safe or extra rmsr in fast path. 

How do you think?

Thanks,
Kan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter Zijlstra July 7, 2014, 3:46 p.m. UTC | #6 
On Mon, Jul 07, 2014 at 01:57:16PM +0000, Liang, Kan wrote:
> > > This doesn't work, e.g. hardware debuggers can take over at any time.
> > 
> > Tough cookies. Hardware debuggers get to deal with whatever crap they
> > cause.
> 
> If so, I think I may discard this patch (2/3). I will resubmit the
> other two patches as a patch set to only handle the KVM issue we
> found.  It checks the access of LBR and extra MSRs at the
> initialization time and set the flags. So we just need to check the
> flags at runtime and avoid the protection by _safe(). 

Right.

> For Intel PT and LBR handling, since the PT codes haven't been
> integrated yet, I will try to implement another patch later.  The
> patch will add flags for LBR and PT.  When enabling PT, it checks LBR
> flag and update the PT flag. When enabling LBR, it checks PT flag and
> update the LBR flag. When disabling LBR/PT, we just update the related
> flags. we don't need to add _safe or extra rmsr in fast path. 

Yeah, should be part of the PT patches.

> How do you think?

With my brain, much like all primates :-)
Peter Zijlstra July 7, 2014, 3:47 p.m. UTC | #7 
On Mon, Jul 07, 2014 at 05:46:35PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 07, 2014 at 01:57:16PM +0000, Liang, Kan wrote:
> > > > This doesn't work, e.g. hardware debuggers can take over at any time.
> > > 
> > > Tough cookies. Hardware debuggers get to deal with whatever crap they
> > > cause.
> > 
> > If so, I think I may discard this patch (2/3). I will resubmit the
> > other two patches as a patch set to only handle the KVM issue we
> > found.  It checks the access of LBR and extra MSRs at the
> > initialization time and set the flags. So we just need to check the
> > flags at runtime and avoid the protection by _safe(). 
> 
> Right.
> 
> > For Intel PT and LBR handling, since the PT codes haven't been
> > integrated yet, I will try to implement another patch later.  The
> > patch will add flags for LBR and PT.  When enabling PT, it checks LBR
> > flag and update the PT flag. When enabling LBR, it checks PT flag and
> > update the LBR flag. When disabling LBR/PT, we just update the related
> > flags. we don't need to add _safe or extra rmsr in fast path. 
> 
> Yeah, should be part of the PT patches.
> 
> > How do you think?
> 
> With my brain, much like all primates :-)

Also, teach your mailer to wrap text at 78 chars or so.
diff mbox

Patch

diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 5d977b2..fafb809 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -458,7 +458,6 @@  struct x86_pmu {
 	u64		lbr_sel_mask;		   /* LBR_SELECT valid bits */
 	const int	*lbr_sel_map;		   /* lbr_select mappings */
 	bool		lbr_double_abort;	   /* duplicated lbr aborts */
-	bool		lbr_msr_access;		   /* LBR MSR can be accessed */
 	/*
 	 * Extra registers for events
 	 */
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
index 8011d42..ddd3590 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2565,9 +2565,6 @@  __init int intel_pmu_init(void)
 		}
 	}
 
-	/* Access LBR MSR may cause #GP under certain circumstances. E.g. KVM doesn't support LBR MSR */
-	if (x86_pmu.lbr_nr)
-		x86_pmu.lbr_msr_access = test_msr_access(x86_pmu.lbr_tos) & test_msr_access(x86_pmu.lbr_from);
 	/* Access extra MSR may cause #GP under certain circumstances. E.g. KVM doesn't support offcore event */
 	if (x86_pmu.extra_regs)
 		x86_pmu.extra_msr_access = test_msr_access(x86_pmu.extra_regs->msr);
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index 9508d1e..980b8dc 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -157,7 +157,7 @@  static void intel_pmu_lbr_reset_32(void)
 	int i;
 
 	for (i = 0; i < x86_pmu.lbr_nr; i++)
-		wrmsrl(x86_pmu.lbr_from + i, 0);
+		wrmsrl_safe(x86_pmu.lbr_from + i, 0ULL);
 }
 
 static void intel_pmu_lbr_reset_64(void)
@@ -165,14 +165,14 @@  static void intel_pmu_lbr_reset_64(void)
 	int i;
 
 	for (i = 0; i < x86_pmu.lbr_nr; i++) {
-		wrmsrl(x86_pmu.lbr_from + i, 0);
-		wrmsrl(x86_pmu.lbr_to   + i, 0);
+		wrmsrl_safe(x86_pmu.lbr_from + i, 0ULL);
+		wrmsrl_safe(x86_pmu.lbr_to   + i, 0ULL);
 	}
 }
 
 void intel_pmu_lbr_reset(void)
 {
-	if (!x86_pmu.lbr_nr  || !x86_pmu.lbr_msr_access)
+	if (!x86_pmu.lbr_nr)
 		return;
 
 	if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_32)
@@ -237,19 +237,14 @@  void intel_pmu_lbr_disable_all(void)
 /*
  * TOS = most recently recorded branch
  */
-static inline u64 intel_pmu_lbr_tos(void)
+static inline int intel_pmu_lbr_tos(u64 *tos)
 {
-	u64 tos;
-
-	rdmsrl(x86_pmu.lbr_tos, tos);
-
-	return tos;
+	return rdmsrl_safe(x86_pmu.lbr_tos, tos);
 }
 
-static void intel_pmu_lbr_read_32(struct cpu_hw_events *cpuc)
+static void intel_pmu_lbr_read_32(struct cpu_hw_events *cpuc, u64 tos)
 {
 	unsigned long mask = x86_pmu.lbr_nr - 1;
-	u64 tos = intel_pmu_lbr_tos();
 	int i;
 
 	for (i = 0; i < x86_pmu.lbr_nr; i++) {
@@ -278,11 +273,10 @@  static void intel_pmu_lbr_read_32(struct cpu_hw_events *cpuc)
  * is the same as the linear address, allowing us to merge the LIP and EIP
  * LBR formats.
  */
-static void intel_pmu_lbr_read_64(struct cpu_hw_events *cpuc)
+static void intel_pmu_lbr_read_64(struct cpu_hw_events *cpuc, u64 tos)
 {
 	unsigned long mask = x86_pmu.lbr_nr - 1;
 	int lbr_format = x86_pmu.intel_cap.lbr_format;
-	u64 tos = intel_pmu_lbr_tos();
 	int i;
 	int out = 0;
 
@@ -333,14 +327,24 @@  static void intel_pmu_lbr_read_64(struct cpu_hw_events *cpuc)
 void intel_pmu_lbr_read(void)
 {
 	struct cpu_hw_events *cpuc = &__get_cpu_var(cpu_hw_events);
+	u64 tos;
 
-	if (!cpuc->lbr_users || !x86_pmu.lbr_msr_access)
+	if (!cpuc->lbr_users)
+		return;
+
+	/*
+	 * If KVM doesn't support LBR MSRs or Intel PT is enabled,
+	 * accessing LBR MSRs cause GP#.
+	 * Since Intel PT can be enabled/disabled at runtime,
+	 * checking the LBR MSRs access right here.
+	 */
+	if (intel_pmu_lbr_tos(&tos) < 0)
 		return;
 
 	if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_32)
-		intel_pmu_lbr_read_32(cpuc);
+		intel_pmu_lbr_read_32(cpuc, tos);
 	else
-		intel_pmu_lbr_read_64(cpuc);
+		intel_pmu_lbr_read_64(cpuc, tos);
 
 	intel_pmu_lbr_filter(cpuc);
 }