Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1384373 > unrolled thread

[PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

Started byAlexander Shishkin <alexander.shishkin@linux.intel.com>
First post2016-04-21 17:40 +0200
Last post2016-04-22 11:40 +0200
Articles 8 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-04-21 17:40 +0200
    Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid  bits Borislav Petkov <bp@alien8.de> - 2016-04-21 19:50 +0200
      Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid  bits Thomas Gleixner <tglx@linutronix.de> - 2016-04-21 21:00 +0200
        Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid  bits Peter Zijlstra <peterz@infradead.org> - 2016-04-21 21:20 +0200
          Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid  bits Borislav Petkov <bp@alien8.de> - 2016-04-21 22:50 +0200
        Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid  bits Borislav Petkov <bp@alien8.de> - 2016-04-21 22:40 +0200
          Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid  bits Thomas Gleixner <tglx@linutronix.de> - 2016-04-22 10:10 +0200
            Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid  bits Borislav Petkov <bp@alien8.de> - 2016-04-22 11:40 +0200

#1384373 — [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

FromAlexander Shishkin <alexander.shishkin@linux.intel.com>
Date2016-04-21 17:40 +0200
Subject[PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits
Message-ID<rqoRY-2Wv-27@gated-at.bofh.it>
New versions of Intel PT support address range-based filtering. These
are the registers, bit definitions and relevant CPUID bits.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
---
 arch/x86/events/intel/pt.c       |  2 ++
 arch/x86/events/intel/pt.h       |  2 ++
 arch/x86/include/asm/msr-index.h | 18 ++++++++++++++++++
 3 files changed, 22 insertions(+)

diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
index 127f58c179..891447dd61 100644
--- a/arch/x86/events/intel/pt.c
+++ b/arch/x86/events/intel/pt.c
@@ -67,11 +67,13 @@ static struct pt_cap_desc {
 	PT_CAP(max_subleaf,		0, CR_EAX, 0xffffffff),
 	PT_CAP(cr3_filtering,		0, CR_EBX, BIT(0)),
 	PT_CAP(psb_cyc,			0, CR_EBX, BIT(1)),
+	PT_CAP(ip_filtering,		0, CR_EBX, BIT(2)),
 	PT_CAP(mtc,			0, CR_EBX, BIT(3)),
 	PT_CAP(topa_output,		0, CR_ECX, BIT(0)),
 	PT_CAP(topa_multiple_entries,	0, CR_ECX, BIT(1)),
 	PT_CAP(single_range_output,	0, CR_ECX, BIT(2)),
 	PT_CAP(payloads_lip,		0, CR_ECX, BIT(31)),
+	PT_CAP(num_address_ranges,	1, CR_EAX, 0x3),
 	PT_CAP(mtc_periods,		1, CR_EAX, 0xffff0000),
 	PT_CAP(cycle_thresholds,	1, CR_EBX, 0xffff),
 	PT_CAP(psb_periods,		1, CR_EBX, 0xffff0000),
diff --git a/arch/x86/events/intel/pt.h b/arch/x86/events/intel/pt.h
index 336878a5d2..6ce8cd20b9 100644
--- a/arch/x86/events/intel/pt.h
+++ b/arch/x86/events/intel/pt.h
@@ -52,11 +52,13 @@ enum pt_capabilities {
 	PT_CAP_max_subleaf = 0,
 	PT_CAP_cr3_filtering,
 	PT_CAP_psb_cyc,
+	PT_CAP_ip_filtering,
 	PT_CAP_mtc,
 	PT_CAP_topa_output,
 	PT_CAP_topa_multiple_entries,
 	PT_CAP_single_range_output,
 	PT_CAP_payloads_lip,
+	PT_CAP_num_address_ranges,
 	PT_CAP_mtc_periods,
 	PT_CAP_cycle_thresholds,
 	PT_CAP_psb_periods,
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index e0e2f7dfbd..964d7e17a6 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -105,11 +105,29 @@
 #define RTIT_CTL_CYC_THRESH		(0x0full << RTIT_CTL_CYC_THRESH_OFFSET)
 #define RTIT_CTL_PSB_FREQ_OFFSET	24
 #define RTIT_CTL_PSB_FREQ      		(0x0full << RTIT_CTL_PSB_FREQ_OFFSET)
+#define RTIT_CTL_ADDR0_OFFSET		32
+#define RTIT_CTL_ADDR0      		(0x0full << RTIT_CTL_ADDR0_OFFSET)
+#define RTIT_CTL_ADDR1_OFFSET		36
+#define RTIT_CTL_ADDR1      		(0x0full << RTIT_CTL_ADDR1_OFFSET)
+#define RTIT_CTL_ADDR2_OFFSET		40
+#define RTIT_CTL_ADDR2      		(0x0full << RTIT_CTL_ADDR2_OFFSET)
+#define RTIT_CTL_ADDR3_OFFSET		44
+#define RTIT_CTL_ADDR3      		(0x0full << RTIT_CTL_ADDR3_OFFSET)
 #define MSR_IA32_RTIT_STATUS		0x00000571
+#define RTIT_STATUS_FILTEREN		BIT(0)
 #define RTIT_STATUS_CONTEXTEN		BIT(1)
 #define RTIT_STATUS_TRIGGEREN		BIT(2)
+#define RTIT_STATUS_BUFFOVF		BIT(3)
 #define RTIT_STATUS_ERROR		BIT(4)
 #define RTIT_STATUS_STOPPED		BIT(5)
+#define MSR_IA32_RTIT_ADDR0_A		0x00000580
+#define MSR_IA32_RTIT_ADDR0_B		0x00000581
+#define MSR_IA32_RTIT_ADDR1_A		0x00000582
+#define MSR_IA32_RTIT_ADDR1_B		0x00000583
+#define MSR_IA32_RTIT_ADDR2_A		0x00000584
+#define MSR_IA32_RTIT_ADDR2_B		0x00000585
+#define MSR_IA32_RTIT_ADDR3_A		0x00000586
+#define MSR_IA32_RTIT_ADDR3_B		0x00000587
 #define MSR_IA32_RTIT_CR3_MATCH		0x00000572
 #define MSR_IA32_RTIT_OUTPUT_BASE	0x00000560
 #define MSR_IA32_RTIT_OUTPUT_MASK	0x00000561
-- 
2.8.0.rc3

[toc] | [next] | [standalone]

#1384455 — Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

FromBorislav Petkov <bp@alien8.de>
Date2016-04-21 19:50 +0200
SubjectRe: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits
Message-ID<rqqTM-4ry-3@gated-at.bofh.it>
In reply to#1384373
On Thu, Apr 21, 2016 at 06:17:00PM +0300, Alexander Shishkin wrote:
> New versions of Intel PT support address range-based filtering. These
> are the registers, bit definitions and relevant CPUID bits.
> 
> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> ---
>  arch/x86/events/intel/pt.c       |  2 ++
>  arch/x86/events/intel/pt.h       |  2 ++
>  arch/x86/include/asm/msr-index.h | 18 ++++++++++++++++++
>  3 files changed, 22 insertions(+)
> 
> diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c
> index 127f58c179..891447dd61 100644
> --- a/arch/x86/events/intel/pt.c
> +++ b/arch/x86/events/intel/pt.c
> @@ -67,11 +67,13 @@ static struct pt_cap_desc {
>  	PT_CAP(max_subleaf,		0, CR_EAX, 0xffffffff),
>  	PT_CAP(cr3_filtering,		0, CR_EBX, BIT(0)),
>  	PT_CAP(psb_cyc,			0, CR_EBX, BIT(1)),
> +	PT_CAP(ip_filtering,		0, CR_EBX, BIT(2)),
>  	PT_CAP(mtc,			0, CR_EBX, BIT(3)),
>  	PT_CAP(topa_output,		0, CR_ECX, BIT(0)),
>  	PT_CAP(topa_multiple_entries,	0, CR_ECX, BIT(1)),
>  	PT_CAP(single_range_output,	0, CR_ECX, BIT(2)),
>  	PT_CAP(payloads_lip,		0, CR_ECX, BIT(31)),
> +	PT_CAP(num_address_ranges,	1, CR_EAX, 0x3),
>  	PT_CAP(mtc_periods,		1, CR_EAX, 0xffff0000),
>  	PT_CAP(cycle_thresholds,	1, CR_EBX, 0xffff),
>  	PT_CAP(psb_periods,		1, CR_EBX, 0xffff0000),
> diff --git a/arch/x86/events/intel/pt.h b/arch/x86/events/intel/pt.h
> index 336878a5d2..6ce8cd20b9 100644
> --- a/arch/x86/events/intel/pt.h
> +++ b/arch/x86/events/intel/pt.h
> @@ -52,11 +52,13 @@ enum pt_capabilities {
>  	PT_CAP_max_subleaf = 0,
>  	PT_CAP_cr3_filtering,
>  	PT_CAP_psb_cyc,
> +	PT_CAP_ip_filtering,
>  	PT_CAP_mtc,
>  	PT_CAP_topa_output,
>  	PT_CAP_topa_multiple_entries,
>  	PT_CAP_single_range_output,
>  	PT_CAP_payloads_lip,
> +	PT_CAP_num_address_ranges,
>  	PT_CAP_mtc_periods,
>  	PT_CAP_cycle_thresholds,
>  	PT_CAP_psb_periods,
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index e0e2f7dfbd..964d7e17a6 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -105,11 +105,29 @@
>  #define RTIT_CTL_CYC_THRESH		(0x0full << RTIT_CTL_CYC_THRESH_OFFSET)
>  #define RTIT_CTL_PSB_FREQ_OFFSET	24
>  #define RTIT_CTL_PSB_FREQ      		(0x0full << RTIT_CTL_PSB_FREQ_OFFSET)
> +#define RTIT_CTL_ADDR0_OFFSET		32
> +#define RTIT_CTL_ADDR0      		(0x0full << RTIT_CTL_ADDR0_OFFSET)
> +#define RTIT_CTL_ADDR1_OFFSET		36
> +#define RTIT_CTL_ADDR1      		(0x0full << RTIT_CTL_ADDR1_OFFSET)
> +#define RTIT_CTL_ADDR2_OFFSET		40
> +#define RTIT_CTL_ADDR2      		(0x0full << RTIT_CTL_ADDR2_OFFSET)
> +#define RTIT_CTL_ADDR3_OFFSET		44
> +#define RTIT_CTL_ADDR3      		(0x0full << RTIT_CTL_ADDR3_OFFSET)
>  #define MSR_IA32_RTIT_STATUS		0x00000571
> +#define RTIT_STATUS_FILTEREN		BIT(0)
>  #define RTIT_STATUS_CONTEXTEN		BIT(1)
>  #define RTIT_STATUS_TRIGGEREN		BIT(2)
> +#define RTIT_STATUS_BUFFOVF		BIT(3)
>  #define RTIT_STATUS_ERROR		BIT(4)
>  #define RTIT_STATUS_STOPPED		BIT(5)
> +#define MSR_IA32_RTIT_ADDR0_A		0x00000580
> +#define MSR_IA32_RTIT_ADDR0_B		0x00000581
> +#define MSR_IA32_RTIT_ADDR1_A		0x00000582
> +#define MSR_IA32_RTIT_ADDR1_B		0x00000583
> +#define MSR_IA32_RTIT_ADDR2_A		0x00000584
> +#define MSR_IA32_RTIT_ADDR2_B		0x00000585
> +#define MSR_IA32_RTIT_ADDR3_A		0x00000586
> +#define MSR_IA32_RTIT_ADDR3_B		0x00000587

So can we not turn msr-index.h a dumping ground for MSRs pls?

If those are only PT-relevant, why not define them all in pt.h?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1384521 — Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

FromThomas Gleixner <tglx@linutronix.de>
Date2016-04-21 21:00 +0200
SubjectRe: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits
Message-ID<rqrZv-5rZ-3@gated-at.bofh.it>
In reply to#1384455
On Thu, 21 Apr 2016, Borislav Petkov wrote:
> > +#define MSR_IA32_RTIT_ADDR0_A		0x00000580
> > +#define MSR_IA32_RTIT_ADDR0_B		0x00000581
> > +#define MSR_IA32_RTIT_ADDR1_A		0x00000582
> > +#define MSR_IA32_RTIT_ADDR1_B		0x00000583
> > +#define MSR_IA32_RTIT_ADDR2_A		0x00000584
> > +#define MSR_IA32_RTIT_ADDR2_B		0x00000585
> > +#define MSR_IA32_RTIT_ADDR3_A		0x00000586
> > +#define MSR_IA32_RTIT_ADDR3_B		0x00000587
> 
> So can we not turn msr-index.h a dumping ground for MSRs pls?
> 
> If those are only PT-relevant, why not define them all in pt.h?

I have to disagree here. The MSRs itself can really go into msr-index.h while
the bit definitions might go elsewhere. What's wrong with having all MSRs at a
central place?

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1384527 — Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

FromPeter Zijlstra <peterz@infradead.org>
Date2016-04-21 21:20 +0200
SubjectRe: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits
Message-ID<rqsiS-5YO-7@gated-at.bofh.it>
In reply to#1384521
On Thu, Apr 21, 2016 at 08:55:38PM +0200, Thomas Gleixner wrote:
> On Thu, 21 Apr 2016, Borislav Petkov wrote:
> > > +#define MSR_IA32_RTIT_ADDR0_A		0x00000580
> > > +#define MSR_IA32_RTIT_ADDR0_B		0x00000581
> > > +#define MSR_IA32_RTIT_ADDR1_A		0x00000582
> > > +#define MSR_IA32_RTIT_ADDR1_B		0x00000583
> > > +#define MSR_IA32_RTIT_ADDR2_A		0x00000584
> > > +#define MSR_IA32_RTIT_ADDR2_B		0x00000585
> > > +#define MSR_IA32_RTIT_ADDR3_A		0x00000586
> > > +#define MSR_IA32_RTIT_ADDR3_B		0x00000587
> > 
> > So can we not turn msr-index.h a dumping ground for MSRs pls?
> > 
> > If those are only PT-relevant, why not define them all in pt.h?
> 
> I have to disagree here. The MSRs itself can really go into msr-index.h while
> the bit definitions might go elsewhere. What's wrong with having all MSRs at a
> central place?

So I agree with Thomas; the risk of not doing this is that we'll
introduce the same MSR again, in another file, under another name.

That's confusion we can do without.

[toc] | [prev] | [next] | [standalone]

#1384563 — Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

FromBorislav Petkov <bp@alien8.de>
Date2016-04-21 22:50 +0200
SubjectRe: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits
Message-ID<rqtHY-6XI-5@gated-at.bofh.it>
In reply to#1384527
On Thu, Apr 21, 2016 at 09:17:02PM +0200, Peter Zijlstra wrote:
> So I agree with Thomas; the risk of not doing this is that we'll
> introduce the same MSR again, in another file, under another name.

... only if that MSR is useful in other compilation units. If not, then
you're unlikely to need it somewhere else. That's why I meant if it is
PT-relevant only, to define it in its header instead.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1384559 — Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

FromBorislav Petkov <bp@alien8.de>
Date2016-04-21 22:40 +0200
SubjectRe: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits
Message-ID<rqtyi-6T4-1@gated-at.bofh.it>
In reply to#1384521
On Thu, Apr 21, 2016 at 08:55:38PM +0200, Thomas Gleixner wrote:
> I have to disagree here. The MSRs itself can really go into msr-index.h while
> the bit definitions might go elsewhere. What's wrong with having all MSRs at a
> central place?

Same reason as for pci_ids.h - to contain only MSRs which are used in
multiple compilation units.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [next] | [standalone]

#1384767 — Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

FromThomas Gleixner <tglx@linutronix.de>
Date2016-04-22 10:10 +0200
SubjectRe: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits
Message-ID<rqEk2-7fW-17@gated-at.bofh.it>
In reply to#1384559
On Thu, 21 Apr 2016, Borislav Petkov wrote:

> On Thu, Apr 21, 2016 at 08:55:38PM +0200, Thomas Gleixner wrote:
> > I have to disagree here. The MSRs itself can really go into msr-index.h while
> > the bit definitions might go elsewhere. What's wrong with having all MSRs at a
> > central place?
> 
> Same reason as for pci_ids.h - to contain only MSRs which are used in
> multiple compilation units.

That's really not the same thing. pci ids are issued by a gazillion of vendors
for a bazillion of different devices. There is no consistent view for them.

MSRs on the other hand are x86 specific registers nicely defined in the
SDM/APM and having at least the MSR defines in a single header makes a lot of
sense.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1384824 — Re: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

FromBorislav Petkov <bp@alien8.de>
Date2016-04-22 11:40 +0200
SubjectRe: [PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits
Message-ID<rqFJ9-8d9-23@gated-at.bofh.it>
In reply to#1384767
On Fri, Apr 22, 2016 at 09:58:31AM +0200, Thomas Gleixner wrote:
> That's really not the same thing. pci ids are issued by a gazillion of vendors
> for a bazillion of different devices. There is no consistent view for them.

So my reasoning was to not add *every* MSR to that file, especially the
ones which are strictly topical. For example, the MCA MSRs which can
easily live in mce.h as nothing else needs to touch them...

> MSRs on the other hand are x86 specific registers nicely defined in the
> SDM/APM and having at least the MSR defines in a single header makes a lot of
> sense.

... but ok. I see there could be some merit of keeping them all in the
same place. We can always change that if the handling of msr-index.h
starts becoming too unwieldy.

In any case, we'd need to zap

053080a9d1c8 ("x86/msr: Document msr-index.h rule for addition")

now.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web