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

Groups > linux.kernel > #1471462 > unrolled thread

[PATCH 00/13] Add support for perf_arch_regs

Back to article view | Back to linux.kernel

Contents

  [PATCH 00/13] Add support for perf_arch_regs Madhavan Srinivasan <maddy@linux.vnet.ibm.com> - 2016-08-28 23:10 +0200
    [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure Madhavan Srinivasan <maddy@linux.vnet.ibm.com> - 2016-08-28 23:10 +0200
      Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to  perf_regs structure kbuild test robot <lkp@intel.com> - 2016-08-29 01:50 +0200
      Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to  perf_regs structure Peter Zijlstra <peterz@infradead.org> - 2016-09-01 09:30 +0200
        Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs  structure Madhavan Srinivasan <maddy@linux.vnet.ibm.com> - 2016-09-06 06:30 +0200
          Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to  perf_regs structure Peter Zijlstra <peterz@infradead.org> - 2016-09-06 11:20 +0200
            Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs  structure Madhavan Srinivasan <maddy@linux.vnet.ibm.com> - 2016-09-09 02:50 +0200
    [PATCH 08/13] powerpc/perf: Add support for perf_arch_regs for newer Power processor Madhavan Srinivasan <maddy@linux.vnet.ibm.com> - 2016-08-28 23:10 +0200
    [PATCH 04/13] perf/core: Extend perf_output_sample_regs() to include perf_arch_regs Madhavan Srinivasan <maddy@linux.vnet.ibm.com> - 2016-08-28 23:10 +0200
      Re: [PATCH 04/13] perf/core: Extend perf_output_sample_regs() to  include perf_arch_regs Nilay Vaish <nilayvaish@gmail.com> - 2016-08-30 18:20 +0200
        Re: [PATCH 04/13] perf/core: Extend perf_output_sample_regs() to  include perf_arch_regs Madhavan Srinivasan <maddy@linux.vnet.ibm.com> - 2016-09-01 05:50 +0200
    [PATCH 02/13] perf/core: Extend perf_sample_regs_intr() to include perf_arch_regs update Madhavan Srinivasan <maddy@linux.vnet.ibm.com> - 2016-08-28 23:10 +0200
    [PATCH 12/13] tool/perf: Add perf_arch_reg mask and arch_reg_names structure Madhavan Srinivasan <maddy@linux.vnet.ibm.com> - 2016-08-28 23:10 +0200
    Re: [PATCH 00/13] Add support for perf_arch_regs Nilay Vaish <nilayvaish@gmail.com> - 2016-08-30 18:10 +0200
      Re: [PATCH 00/13] Add support for perf_arch_regs Madhavan Srinivasan <maddy@linux.vnet.ibm.com> - 2016-09-01 05:10 +0200

#1471462 — [PATCH 00/13] Add support for perf_arch_regs

Patchset to extend PERF_SAMPLE_REGS_INTR to include
platform specific PMU registers.

Patchset applies cleanly on tip:perf/core branch

It's a perennial request from hardware folks to be able to
see the raw values of the pmu registers. Partly it's so that
they can verify perf is doing what they want, and some
of it is that they're interested in some of the more obscure
info that isn't plumbed out through other perf interfaces.

Over the years internally we have used various hack to get
the requested data out but this is an attempt to use a
somewhat standard mechanism (using PERF_SAMPLE_REGS_INTR).

This would also be helpful for those of us working on the perf
hardware backends, to be able to verify that we're programming
things correctly, without resorting to debug printks etc.

Mechanism proposed:

1)perf_regs structure is extended with a perf_arch_regs structure
which each arch/ can populate with their specific platform
registers to sample on each perf interrupt and an arch_regs_mask
variable, which is for perf tool to know about the perf_arch_regs
that are supported.

2)perf/core func perf_sample_regs_intr() extended to update
the perf_arch_regs structure and the perf_arch_reg_mask. Set of new
support functions added perf_get_arch_regs_mask() and
perf_get_arch_reg() to aid the updates from arch/ side.

3) perf/core funcs perf_prepare_sample() and perf_output_sample()
are extended to support the update for the perf_arch_regs_mask and
perf_arch_regs in the sample

4)perf/core func perf_output_sample_regs() extended to dump
the arch_regs to the output sample.

5)Finally, perf tool side is updated to include a new element
"arch_regs_mask" in the "struct regs_dump", event sample funcs
and print functions are updated to support perf_arch_regs.

example usage:

$./perf record -I ls
.....
builtin-data.o           builtin-list.o    builtin-stat.c    Documentation        perf.h
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.009 MB perf.data (12 samples) ]
$./perf script -D
....
0x980 [0x200]: event: 9
.
. ... raw event: size 512 bytes
.  0000:  00 00 00 09 00 01 02 00 00 00 00 00 00 08 fb 4c  ...............L
.  0010:  00 00 16 cb 00 00 16 cb 00 00 01 1d ca 45 9f 52  .............E.R
.  0020:  00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 02  ................
.......
.... dsisr 0x60000000
.... arch_regs 0x7e7f
.... pvr   0x4a0201
.... pmc1  0x7fffffff
.... pmc2  0x0
.... pmc3  0x0
.... pmc4  0x0
.... pmc5  0xa03
.... pmc6  0x38df
.... mmcr0 0x82008080
.... mmcr1 0x1e000000
.... sier  0x1e000000
.... siar  0x8fb4c
.... sdar  0xc00000241b195100
.... mmcra 0x60000000
 ... thread: perf:5835
 ...... dso: <not found>
            perf  5835  1227.459239:          1 cycles:ppp:             8fb4c [unknown] ([unknown])


Option to get only perf_arch_regs values:

$ ./perf record -I?
available registers: r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 r16 r17 r18 r19 r20 r21 r22 r23 r24 r25 r26 r27 r28 r29 r30 r31 nip msr orig_r3 ctr link xer ccr softe trap dar dsisr arch_regs

 Usage: perf record [<options>] [<command>]
    or: perf record [<options>] -- <command> [<options>]

    -I, --intr-regs[=<any register>]
                          sample selected machine registers on interrupt, use -I ? to list register names

$./perf record -Iarch_regs ls
.....
$./perf script -D
.....
104621404208 0xa28 [0xa8]: PERF_RECORD_SAMPLE(IP, 0x1): 5823/5823: 0xc00000000008fb4c period: 1 addr: 0
... intr regs: mask 0x80000000000 ABI 64-bit
.... arch_regs 0x7e7f
.... pvr   0x4a0201
.... pmc1  0x7fffffff
.... pmc2  0x0
.... pmc3  0x0
.... pmc4  0x0
.... pmc5  0x39551
.... pmc6  0xe6d99
.... mmcr0 0x82008080
.... mmcr1 0x1e000000
.... sier  0x1e000000
.... siar  0xc00000000008fb4c
.... sdar  0xc00000235f592500
.... mmcra 0x60000000
 ... thread: perf:5823
 ...... dso: /boot/vmlinux
            perf  5823   104.621404:          1 cycles:ppp:  c00000000008fb4c .power_check_constraints (/boot/vmlinux)
....

RFC:

https://lkml.org/lkml/2015/11/4/530
https://lkml.org/lkml/2015/11/4/531
https://lkml.org/lkml/2015/11/4/532
https://lkml.org/lkml/2015/11/4/533

Patch 11 in this patchset is a fix which is already posted, but not yet
to be pulled in. So I have added that to this patchset.

https://patchwork.kernel.org/patch/9285421/

Kindly let me know you comments and feedbacks.
Madhavan Srinivasan (13):
  perf/core: Add perf_arch_regs and mask to perf_regs structure
  perf/core: Extend perf_sample_regs_intr() to include perf_arch_regs
    update
  perf/core: Update perf_*_sample() to include perf_arch_regs
  perf/core: Extend perf_output_sample_regs() to include perf_arch_regs
  powerpc/perf: Define enums for perf_arch_regs registers
  powerpc/perf: Add support for perf_arch_regs in powerpc
  powerpc/perf: Add support for perf_arch_regs for Power7 processor
  powerpc/perf: Add support for perf_arch_regs for newer Power processor
  powerpc/perf: Add support for perf_arch_regs for PPC970 processor
  tool/perf: Add support for perf_arch_regs
  tools/perf: Fix the mask in regs_dump__printf and print_sample_iregs
  tool/perf: Add perf_arch_reg mask and arch_reg_names structure
  powerpc/perf: Add support to dump only arch_regs

 arch/powerpc/include/asm/perf_event_server.h    | 11 +++++
 arch/powerpc/include/uapi/asm/perf_regs.h       | 39 ++++++++++++++++++
 arch/powerpc/perf/core-book3s.c                 | 38 ++++++++++++++++++
 arch/powerpc/perf/isa207-common.c               | 18 +++++++++
 arch/powerpc/perf/isa207-common.h               | 10 +++++
 arch/powerpc/perf/perf_regs.c                   |  3 ++
 arch/powerpc/perf/power7-pmu.c                  | 28 +++++++++++++
 arch/powerpc/perf/power8-pmu.c                  |  2 +
 arch/powerpc/perf/power9-pmu.c                  |  2 +
 arch/powerpc/perf/ppc970-pmu.c                  | 23 +++++++++++
 include/linux/perf_regs.h                       | 26 ++++++++++++
 kernel/events/core.c                            | 53 +++++++++++++++++++++----
 tools/arch/powerpc/include/uapi/asm/perf_regs.h | 40 +++++++++++++++++++
 tools/include/linux/bitmap.h                    |  2 +
 tools/lib/bitmap.c                              | 18 +++++++++
 tools/perf/arch/arm/include/perf_regs.h         |  5 +++
 tools/perf/arch/arm64/include/perf_regs.h       |  5 +++
 tools/perf/arch/powerpc/include/perf_regs.h     | 28 ++++++++++++-
 tools/perf/arch/powerpc/util/perf_regs.c        |  1 +
 tools/perf/arch/x86/include/perf_regs.h         |  5 +++
 tools/perf/builtin-script.c                     | 11 ++++-
 tools/perf/util/event.h                         |  1 +
 tools/perf/util/evsel.c                         | 11 +++++
 tools/perf/util/perf_regs.h                     |  5 +++
 tools/perf/util/session.c                       | 16 ++++++--
 25 files changed, 388 insertions(+), 13 deletions(-)

--
2.7.4

[toc] | [next] | [standalone]

#1471463 — [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure

It's a perennial request from hardware folks to be able to
see the raw values of the pmu registers. Partly it's so that
they can verify perf is doing what they want, and some
of it is that they're interested in some of the more obscure
info that isn't plumbed out through other perf interfaces.

Over the years internally have used various hack to get
the requested data out but this is an attempt to use a
somewhat standard mechanism (using PERF_SAMPLE_REGS_INTR).

This would also be helpful for those of us working on the perf
hardware backends, to be able to verify that we're programming
things correctly, without resorting to debug printks etc.

Mechanism proposed:

1)perf_regs structure is extended with a perf_arch_regs structure
which each arch/ can populate with their specific platform
registers to sample on each perf interrupt and an arch_regs_mask
variable, which is for perf tool to know about the perf_arch_regs
that are supported.

2)perf/core func perf_sample_regs_intr() extended to update
the perf_arch_regs structure and the perf_arch_reg_mask. Set of new
support functions added perf_get_arch_regs_mask() and
perf_get_arch_reg() to aid the updates from arch/ side.

3) perf/core funcs perf_prepare_sample() and perf_output_sample()
are extended to support the update for the perf_arch_regs_mask and
perf_arch_regs in the sample

4)perf/core func perf_output_sample_regs() extended to dump
the arch_regs to the output sample.

5)Finally, perf tool side is updated a) to include a new element
"arch_regs_mask" in the "struct regs_dump", b) event sample funcs
to updated to include "arch_regs_mask" and c) print functions
are updated.

This foundation patch just extends the perf_regs structure, defines
support function and subsequent patches completes the implimentation
for powerpc arch.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Stephane Eranian <eranian@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
 include/linux/perf_regs.h | 26 ++++++++++++++++++++++++++
 kernel/events/core.c      | 16 ++++++++++++++++
 2 files changed, 42 insertions(+)

diff --git a/include/linux/perf_regs.h b/include/linux/perf_regs.h
index a5f98d53d732..bd19b15703e2 100644
--- a/include/linux/perf_regs.h
+++ b/include/linux/perf_regs.h
@@ -4,8 +4,14 @@
 struct perf_regs {
 	__u64		abi;
 	struct pt_regs	*regs;
+	struct perf_arch_regs	*arch_regs;
+	u64		arch_regs_mask;
 };
 
+#ifndef perf_arch_regs
+struct perf_arch_regs { };
+#endif
+
 #ifdef CONFIG_HAVE_PERF_REGS
 #include <asm/perf_regs.h>
 u64 perf_reg_value(struct pt_regs *regs, int idx);
@@ -14,6 +20,11 @@ u64 perf_reg_abi(struct task_struct *task);
 void perf_get_regs_user(struct perf_regs *regs_user,
 			struct pt_regs *regs,
 			struct pt_regs *regs_user_copy);
+
+u64 perf_get_arch_regs_mask(void);
+struct perf_arch_regs *perf_get_arch_reg(void);
+u64 perf_arch_reg_value(struct perf_arch_regs *regs, int idx);
+
 #else
 static inline u64 perf_reg_value(struct pt_regs *regs, int idx)
 {
@@ -37,5 +48,20 @@ static inline void perf_get_regs_user(struct perf_regs *regs_user,
 	regs_user->regs = task_pt_regs(current);
 	regs_user->abi = perf_reg_abi(current);
 }
+
+u64 perf_get_arch_regs_mask(void)
+{
+	return 0;
+}
+
+struct perf_arch_regs *perf_get_arch_reg(void)
+{
+	return 0;
+}
+
+u64 perf_arch_reg_value(struct perf_arch_regs *regs, int idx)
+{
+	return 0;
+}
 #endif /* CONFIG_HAVE_PERF_REGS */
 #endif /* _LINUX_PERF_REGS_H */
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 3f07e6cfc1b6..2f6e6a16b117 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5353,6 +5353,22 @@ int perf_unregister_guest_info_callbacks(struct perf_guest_info_callbacks *cbs)
 }
 EXPORT_SYMBOL_GPL(perf_unregister_guest_info_callbacks);
 
+u64 __attribute__((weak)) perf_get_arch_regs_mask()
+{
+	return 0;
+}
+
+struct perf_arch_regs *__attribute__((weak)) perf_get_arch_reg()
+{
+	return 0;
+}
+
+u64 __attribute__((weak)) perf_arch_reg_value(struct perf_arch_regs *regs,
+								int idx)
+{
+	return 0;
+}
+
 static void
 perf_output_sample_regs(struct perf_output_handle *handle,
 			struct pt_regs *regs, u64 mask)
-- 
2.7.4

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

#1471493 — Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure

[Multipart message — attachments visible in raw view] — view raw

Hi Madhavan,

[auto build test WARNING on tip/perf/core]
[also build test WARNING on v4.8-rc4 next-20160825]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:    https://github.com/0day-ci/linux/commits/Madhavan-Srinivasan/perf-core-Add-perf_arch_regs-and-mask-to-perf_regs-structure/20160829-050443
config: frv-defconfig (attached as .config)
compiler: frv-linux-gcc (GCC) 4.9.0
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=frv 

All warnings (new ones prefixed by >>):

   kernel/sched/idle.o: In function `perf_get_arch_regs_mask':
   idle.c:(.text+0x0): multiple definition of `perf_get_arch_regs_mask'
   kernel/sched/core.o:core.c:(.text+0x310): first defined here
>> frv-linux-ld: Warning: size of symbol `perf_get_arch_regs_mask' changed from 44 in kernel/sched/core.o to 12 in kernel/sched/idle.o
   kernel/sched/idle.o: In function `perf_get_arch_reg':
   idle.c:(.text+0x10): multiple definition of `perf_get_arch_reg'
   kernel/sched/core.o:core.c:(.text+0x340): first defined here
>> frv-linux-ld: Warning: size of symbol `perf_get_arch_reg' changed from 40 in kernel/sched/core.o to 8 in kernel/sched/idle.o
   kernel/sched/idle.o: In function `perf_arch_reg_value':
   idle.c:(.text+0x20): multiple definition of `perf_arch_reg_value'
   kernel/sched/core.o:core.c:(.text+0x370): first defined here
>> frv-linux-ld: Warning: size of symbol `perf_arch_reg_value' changed from 44 in kernel/sched/core.o to 12 in kernel/sched/idle.o

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

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

#1474126 — Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure

On Mon, Aug 29, 2016 at 02:30:46AM +0530, Madhavan Srinivasan wrote:
> It's a perennial request from hardware folks to be able to
> see the raw values of the pmu registers. Partly it's so that
> they can verify perf is doing what they want, and some
> of it is that they're interested in some of the more obscure
> info that isn't plumbed out through other perf interfaces.

How much and what is that? Can't we try and get interfaces sorted?

> Over the years internally have used various hack to get
> the requested data out but this is an attempt to use a
> somewhat standard mechanism (using PERF_SAMPLE_REGS_INTR).

Not really liking that. It assumes too much and doesn't seem to cover
about half the perf use-cases.

It assumes the machine state can be captured by registers (this is false
for things like Intel DS/PT, which have state in memory), it might
assume <= 64 registers but I didn't look that closely, this too might
become somewhat restrictive.

Worse, it doesn't work for !sampling workloads, of which you also very
much want to verify programming etc.

> This would also be helpful for those of us working on the perf
> hardware backends, to be able to verify that we're programming
> things correctly, without resorting to debug printks etc.

On x86 we can trace the MSR writes. No need to add debug printk()s.
We could (and I have on occasion) added tracepoints (well trace_printk)
to the Intel DS memory stores to see what was written there.

Tracing is much more flexible for debugging this stuff.

Can't you do something along those lines?

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

#1477062 — Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure

On Thursday 01 September 2016 12:56 PM, Peter Zijlstra wrote:
> On Mon, Aug 29, 2016 at 02:30:46AM +0530, Madhavan Srinivasan wrote:
>> It's a perennial request from hardware folks to be able to
>> see the raw values of the pmu registers. Partly it's so that
>> they can verify perf is doing what they want, and some
>> of it is that they're interested in some of the more obscure
>> info that isn't plumbed out through other perf interfaces.
> How much and what is that? Can't we try and get interfaces sorted?

We have bunch of registers which exports information regarding the
sampled instruction like SIER/SIAR/SDAR/MMCRA. Lot of bits in these
registers are not yet architected and incase of SIER register, some of
the bits are not plumbed out and we are working on getting some these
exposed via perf.

>
>> Over the years internally have used various hack to get
>> the requested data out but this is an attempt to use a
>> somewhat standard mechanism (using PERF_SAMPLE_REGS_INTR).
> Not really liking that. It assumes too much and doesn't seem to cover
> about half the perf use-cases.
>
> It assumes the machine state can be captured by registers (this is false
> for things like Intel DS/PT, which have state in memory), it might
> assume <= 64 registers but I didn't look that closely, this too might
> become somewhat restrictive.
>
> Worse, it doesn't work for !sampling workloads, of which you also very
> much want to verify programming etc.

Yes, I agree, my bad. I did assume and implemented considering
pmu registers primarily, but we can extend with additional flags
on the content being copied. Good point that patchset not handling
!sampling case. Let me explore on this and also the tracing options.

Thanks for the comments.
Maddy

>
>> This would also be helpful for those of us working on the perf
>> hardware backends, to be able to verify that we're programming
>> things correctly, without resorting to debug printks etc.
> On x86 we can trace the MSR writes. No need to add debug printk()s.
> We could (and I have on occasion) added tracepoints (well trace_printk)
> to the Intel DS memory stores to see what was written there.
>
> Tracing is much more flexible for debugging this stuff.
>
> Can't you do something along those lines?
>

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

#1477203 — Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure

On Tue, Sep 06, 2016 at 09:55:43AM +0530, Madhavan Srinivasan wrote:
> 
> 
> On Thursday 01 September 2016 12:56 PM, Peter Zijlstra wrote:
> >On Mon, Aug 29, 2016 at 02:30:46AM +0530, Madhavan Srinivasan wrote:
> >>It's a perennial request from hardware folks to be able to
> >>see the raw values of the pmu registers. Partly it's so that
> >>they can verify perf is doing what they want, and some
> >>of it is that they're interested in some of the more obscure
> >>info that isn't plumbed out through other perf interfaces.
> >How much and what is that? Can't we try and get interfaces sorted?
> 
> We have bunch of registers which exports information regarding the
> sampled instruction like SIER/SIAR/SDAR/MMCRA. Lot of bits in these
> registers are not yet architected and incase of SIER register, some of
> the bits are not plumbed out and we are working on getting some these
> exposed via perf.

What kind of information is this? I'm not familiar with the Power PMU
all that much, so you'll have to spell it out, not just mention the
registers its stuffed in.

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

#1479595 — Re: [PATCH 01/13] perf/core: Add perf_arch_regs and mask to perf_regs structure

On Tuesday 06 September 2016 02:40 PM, Peter Zijlstra wrote:
> On Tue, Sep 06, 2016 at 09:55:43AM +0530, Madhavan Srinivasan wrote:
>>
>> On Thursday 01 September 2016 12:56 PM, Peter Zijlstra wrote:
>>> On Mon, Aug 29, 2016 at 02:30:46AM +0530, Madhavan Srinivasan wrote:
>>>> It's a perennial request from hardware folks to be able to
>>>> see the raw values of the pmu registers. Partly it's so that
>>>> they can verify perf is doing what they want, and some
>>>> of it is that they're interested in some of the more obscure
>>>> info that isn't plumbed out through other perf interfaces.
>>> How much and what is that? Can't we try and get interfaces sorted?
>> We have bunch of registers which exports information regarding the
>> sampled instruction like SIER/SIAR/SDAR/MMCRA. Lot of bits in these
>> registers are not yet architected and incase of SIER register, some of
>> the bits are not plumbed out and we are working on getting some these
>> exposed via perf.
> What kind of information is this? I'm not familiar with the Power PMU
> all that much, so you'll have to spell it out, not just mention the
> registers its stuffed in.


Sure. When we profile for sample events,
SIER (Sampled Instruction Event Register) provides additional
information about the sampled event when PMI occurred.

SIER [41:42] indicates whether the SIAR(Sampled instruction address 
registers)
and SDAR (Sampled data address register) are valid for the sampled event.

SIER [46:48] indicates the type of intructions,

001 Load Instruction
010 Store instruction
011 Branch Instruction
100 Floating Point Instruction other than a Load or Store instruction
101 Fixed Point Instruction other than a Load or Store instruction
110 Condition Register or System Call Instruction

SIER[49:51] gives information on the source of the sampled
instruction like instruction came from primary, secondary,
tertiary cache or beyond.

SIER[52:55] provide information on branch type instructions
Like mispredict and cause of it.

SIER[56:59] provides information on translation and also
source of translation like TLB, secondary cache, tertiary
or beyond

SIER[60:62] provides the interesting data on the storage
access like L1/l2/L3... so on.

Most of these could be plumbed out through standard mechanisms
and it's all the other bits that are more interesting, but
these are not architected and not public.

Like wise, MMCRA (Monitor Mode Control Register A) is a
configuration register for sampling and thresholding events.
Provide data on various event configuration information.

Link to the PowerISA v2.07 and Chapters 9 describes in
detail on these registers.

https://www.power.org/wp-content/uploads/2013/05/PowerISA_V2.07_PUBLIC.pdf

Maddy


>

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

#1471464 — [PATCH 08/13] powerpc/perf: Add support for perf_arch_regs for newer Power processor

Add code to define support functions and registers mask for
Power8 and later processor.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Stephane Eranian <eranian@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
 arch/powerpc/perf/isa207-common.c | 18 ++++++++++++++++++
 arch/powerpc/perf/isa207-common.h | 10 ++++++++++
 arch/powerpc/perf/power8-pmu.c    |  2 ++
 arch/powerpc/perf/power9-pmu.c    |  2 ++
 4 files changed, 32 insertions(+)

diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index 6143c99f3ec5..43931c695ecb 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -261,3 +261,21 @@ void isa207_disable_pmc(unsigned int pmc, unsigned long mmcr[])
 	if (pmc <= 3)
 		mmcr[1] &= ~(0xffUL << MMCR1_PMCSEL_SHIFT(pmc + 1));
 }
+
+void isa207_get_arch_regs(struct perf_arch_regs *regs)
+{
+	regs->regs[PERF_ARCH_REG_POWERPC_PVR] = mfspr(SPRN_PVR);
+	regs->regs[PERF_ARCH_REG_POWERPC_PMC1] = mfspr(SPRN_PMC1);
+	regs->regs[PERF_ARCH_REG_POWERPC_PMC2] = mfspr(SPRN_PMC2);
+	regs->regs[PERF_ARCH_REG_POWERPC_PMC3] = mfspr(SPRN_PMC3);
+	regs->regs[PERF_ARCH_REG_POWERPC_PMC4] = mfspr(SPRN_PMC4);
+	regs->regs[PERF_ARCH_REG_POWERPC_PMC5] = mfspr(SPRN_PMC5);
+	regs->regs[PERF_ARCH_REG_POWERPC_PMC6] = mfspr(SPRN_PMC6);
+	regs->regs[PERF_ARCH_REG_POWERPC_MMCR0] = mfspr(SPRN_MMCR0);
+	regs->regs[PERF_ARCH_REG_POWERPC_MMCR1] = mfspr(SPRN_MMCR1);
+	regs->regs[PERF_ARCH_REG_POWERPC_SIER] = mfspr(SPRN_SIER);
+	regs->regs[PERF_ARCH_REG_POWERPC_SIAR] = mfspr(SPRN_SIAR);
+	regs->regs[PERF_ARCH_REG_POWERPC_SDAR] = mfspr(SPRN_SDAR);
+	regs->regs[PERF_ARCH_REG_POWERPC_MMCRA] = mfspr(SPRN_MMCRA);
+	regs->regs[PERF_ARCH_REG_POWERPC_MMCR2] = mfspr(SPRN_MMCR2);
+}
diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
index 4d0a4e5017c2..94bf8dd548ac 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -16,6 +16,7 @@
 #include <linux/perf_event.h>
 #include <asm/firmware.h>
 #include <asm/cputable.h>
+#include <uapi/asm/perf_regs.h>
 
 /*
  * Raw event encoding for PowerISA v2.07:
@@ -227,10 +228,19 @@
 #define MAX_ALT				2
 #define MAX_PMU_COUNTERS		6
 
+#define	ISA207_ARCH_REGS_MASK  (PERF_ARCH_REG_PVR |\
+		PERF_ARCH_REG_PMC1 | PERF_ARCH_REG_PMC2 |\
+		PERF_ARCH_REG_PMC3 | PERF_ARCH_REG_PMC4 |\
+		PERF_ARCH_REG_PMC5 | PERF_ARCH_REG_PMC6 |\
+		PERF_ARCH_REG_MMCR0 | PERF_ARCH_REG_MMCR1 |\
+		PERF_ARCH_REG_SIER | PERF_ARCH_REG_SIAR |\
+		PERF_ARCH_REG_SDAR | PERF_ARCH_REG_MMCRA | PERF_ARCH_REG_MMCR2)
+
 int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp);
 int isa207_compute_mmcr(u64 event[], int n_ev,
 				unsigned int hwc[], unsigned long mmcr[],
 				struct perf_event *pevents[]);
 void isa207_disable_pmc(unsigned int pmc, unsigned long mmcr[]);
+void isa207_get_arch_regs(struct perf_arch_regs *regs);
 
 #endif
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 5fde2b192fec..8c8bc5083eb2 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -394,6 +394,8 @@ static struct power_pmu power8_pmu = {
 	.cache_events		= &power8_cache_events,
 	.attr_groups		= power8_pmu_attr_groups,
 	.bhrb_nr		= 32,
+	.ar_mask		= ISA207_ARCH_REGS_MASK,
+	.get_arch_regs		= isa207_get_arch_regs,
 };
 
 static int __init init_power8_pmu(void)
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 788346303852..1e66ec36b90f 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -307,6 +307,8 @@ static struct power_pmu power9_pmu = {
 	.cache_events		= &power9_cache_events,
 	.attr_groups		= power9_pmu_attr_groups,
 	.bhrb_nr		= 32,
+	.ar_mask                = ISA207_ARCH_REGS_MASK,
+	.get_arch_regs          = isa207_get_arch_regs,
 };
 
 static int __init init_power9_pmu(void)
-- 
2.7.4

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

#1471466 — [PATCH 04/13] perf/core: Extend perf_output_sample_regs() to include perf_arch_regs

Extend perf_output_sample_regs() to take in perf_regs structure as
a parameter instead of pt_regs. Add code to check for arch_regs_mask
and dump the arch registers to the output sample.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Stephane Eranian <eranian@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
 kernel/events/core.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 274288819829..e16bf4d057d1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5371,16 +5371,24 @@ u64 __attribute__((weak)) perf_arch_reg_value(struct perf_arch_regs *regs,
 
 static void
 perf_output_sample_regs(struct perf_output_handle *handle,
-			struct pt_regs *regs, u64 mask)
+				struct perf_regs *regs, u64 mask)
 {
 	int bit;
 	DECLARE_BITMAP(_mask, 64);
+	u64 arch_regs_mask = regs->arch_regs_mask;
 
 	bitmap_from_u64(_mask, mask);
 	for_each_set_bit(bit, _mask, sizeof(mask) * BITS_PER_BYTE) {
 		u64 val;
 
-		val = perf_reg_value(regs, bit);
+		val = perf_reg_value(regs->regs, bit);
+		perf_output_put(handle, val);
+	}
+
+	bitmap_from_u64(_mask, arch_regs_mask);
+	for_each_set_bit(bit, _mask, sizeof(mask) * BITS_PER_BYTE) {
+		u64 val;
+		val = perf_arch_reg_value(regs->arch_regs, bit);
 		perf_output_put(handle, val);
 	}
 }
@@ -5792,7 +5800,7 @@ void perf_output_sample(struct perf_output_handle *handle,
 		if (abi) {
 			u64 mask = event->attr.sample_regs_user;
 			perf_output_sample_regs(handle,
-						data->regs_user.regs,
+						&data->regs_user,
 						mask);
 		}
 	}
@@ -5827,7 +5835,7 @@ void perf_output_sample(struct perf_output_handle *handle,
 			u64 mask = event->attr.sample_regs_intr;
 
 			perf_output_sample_regs(handle,
-						data->regs_intr.regs,
+						&data->regs_intr,
 						mask);
 		}
 	}
-- 
2.7.4

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

#1472613 — Re: [PATCH 04/13] perf/core: Extend perf_output_sample_regs() to include perf_arch_regs

On 28 August 2016 at 16:00, Madhavan Srinivasan
<maddy@linux.vnet.ibm.com> wrote:
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 274288819829..e16bf4d057d1 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5371,16 +5371,24 @@ u64 __attribute__((weak)) perf_arch_reg_value(struct perf_arch_regs *regs,
>
>  static void
>  perf_output_sample_regs(struct perf_output_handle *handle,
> -                       struct pt_regs *regs, u64 mask)
> +                               struct perf_regs *regs, u64 mask)
>  {
>         int bit;
>         DECLARE_BITMAP(_mask, 64);
> +       u64 arch_regs_mask = regs->arch_regs_mask;
>
>         bitmap_from_u64(_mask, mask);
>         for_each_set_bit(bit, _mask, sizeof(mask) * BITS_PER_BYTE) {
>                 u64 val;
>
> -               val = perf_reg_value(regs, bit);
> +               val = perf_reg_value(regs->regs, bit);
> +               perf_output_put(handle, val);
> +       }
> +
> +       bitmap_from_u64(_mask, arch_regs_mask);
> +       for_each_set_bit(bit, _mask, sizeof(mask) * BITS_PER_BYTE) {
> +               u64 val;
> +               val = perf_arch_reg_value(regs->arch_regs, bit);
>                 perf_output_put(handle, val);
>         }
>  }
> @@ -5792,7 +5800,7 @@ void perf_output_sample(struct perf_output_handle *handle,
>                 if (abi) {
>                         u64 mask = event->attr.sample_regs_user;
>                         perf_output_sample_regs(handle,
> -                                               data->regs_user.regs,
> +                                               &data->regs_user,
>                                                 mask);
>                 }
>         }
> @@ -5827,7 +5835,7 @@ void perf_output_sample(struct perf_output_handle *handle,
>                         u64 mask = event->attr.sample_regs_intr;
>
>                         perf_output_sample_regs(handle,
> -                                               data->regs_intr.regs,
> +                                               &data->regs_intr,
>                                                 mask);
>                 }
>         }
> --
> 2.7.4
>

I would like to suggest a slightly different version.  Would it make
more sense to have something like following:

@@ -5792,7 +5800,7 @@ void perf_output_sample(struct perf_output_handle *handle,
                 if (abi) {
                        u64 mask = event->attr.sample_regs_user;
                        perf_output_sample_regs(handle,
                                                data->regs_user.regs,
                                                mask);
                }
+
+              if (arch_regs_mask) {
+                   perf_output_pmu_regs(handle,
data->regs_users.arch_regs, arch_regs_mask);
+              }
        }


Somehow I don't like outputting the two sets of registers through the
same function call.

--
Nilay

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

#1474048 — Re: [PATCH 04/13] perf/core: Extend perf_output_sample_regs() to include perf_arch_regs

On Tuesday 30 August 2016 09:41 PM, Nilay Vaish wrote:
> On 28 August 2016 at 16:00, Madhavan Srinivasan
> <maddy@linux.vnet.ibm.com> wrote:
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> index 274288819829..e16bf4d057d1 100644
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
>> @@ -5371,16 +5371,24 @@ u64 __attribute__((weak)) perf_arch_reg_value(struct perf_arch_regs *regs,
>>
>>   static void
>>   perf_output_sample_regs(struct perf_output_handle *handle,
>> -                       struct pt_regs *regs, u64 mask)
>> +                               struct perf_regs *regs, u64 mask)
>>   {
>>          int bit;
>>          DECLARE_BITMAP(_mask, 64);
>> +       u64 arch_regs_mask = regs->arch_regs_mask;
>>
>>          bitmap_from_u64(_mask, mask);
>>          for_each_set_bit(bit, _mask, sizeof(mask) * BITS_PER_BYTE) {
>>                  u64 val;
>>
>> -               val = perf_reg_value(regs, bit);
>> +               val = perf_reg_value(regs->regs, bit);
>> +               perf_output_put(handle, val);
>> +       }
>> +
>> +       bitmap_from_u64(_mask, arch_regs_mask);
>> +       for_each_set_bit(bit, _mask, sizeof(mask) * BITS_PER_BYTE) {
>> +               u64 val;
>> +               val = perf_arch_reg_value(regs->arch_regs, bit);
>>                  perf_output_put(handle, val);
>>          }
>>   }
>> @@ -5792,7 +5800,7 @@ void perf_output_sample(struct perf_output_handle *handle,
>>                  if (abi) {
>>                          u64 mask = event->attr.sample_regs_user;
>>                          perf_output_sample_regs(handle,
>> -                                               data->regs_user.regs,
>> +                                               &data->regs_user,
>>                                                  mask);
>>                  }
>>          }
>> @@ -5827,7 +5835,7 @@ void perf_output_sample(struct perf_output_handle *handle,
>>                          u64 mask = event->attr.sample_regs_intr;
>>
>>                          perf_output_sample_regs(handle,
>> -                                               data->regs_intr.regs,
>> +                                               &data->regs_intr,
>>                                                  mask);
>>                  }
>>          }
>> --
>> 2.7.4
>>
> I would like to suggest a slightly different version.  Would it make
> more sense to have something like following:

I agree we are outputting two different structures, but since we use the
INTR_REG infrastructure to dump the arch pmu registers, I preferred to
extend perf_output_sample_regs. But I guess I can break it up.

Maddy

>
> @@ -5792,7 +5800,7 @@ void perf_output_sample(struct perf_output_handle *handle,
>                   if (abi) {
>                          u64 mask = event->attr.sample_regs_user;
>                          perf_output_sample_regs(handle,
>                                                  data->regs_user.regs,
>                                                  mask);
>                  }
> +
> +              if (arch_regs_mask) {
> +                   perf_output_pmu_regs(handle,
> data->regs_users.arch_regs, arch_regs_mask);
> +              }
>          }
>
>
> Somehow I don't like outputting the two sets of registers through the
> same function call.
>
> --
> Nilay
>

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

#1471468 — [PATCH 02/13] perf/core: Extend perf_sample_regs_intr() to include perf_arch_regs update

Extend perf_sample_regs_intr() to support the updates needed for
perf_arch_reg structure and perf_arch_regs_mask. Also add code to
init the arch_regs_mask to zero incase of regs_user in
perf_sample_regs_user(). Ideally this should be done in perf_sample_data_init,
but due to commit 2565711fb7d7 ("perf: Improve the perf_sample_data struct layout")
moving it to this function.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Stephane Eranian <eranian@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
 kernel/events/core.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 2f6e6a16b117..8cf540275c34 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5398,6 +5398,9 @@ static void perf_sample_regs_user(struct perf_regs *regs_user,
 		regs_user->abi = PERF_SAMPLE_REGS_ABI_NONE;
 		regs_user->regs = NULL;
 	}
+
+	/* Init arch_regs_mask to zero */
+	regs_user->arch_regs_mask = 0;
 }
 
 static void perf_sample_regs_intr(struct perf_regs *regs_intr,
@@ -5405,6 +5408,8 @@ static void perf_sample_regs_intr(struct perf_regs *regs_intr,
 {
 	regs_intr->regs = regs;
 	regs_intr->abi  = perf_reg_abi(current);
+	regs_intr->arch_regs_mask = perf_get_arch_regs_mask();
+	regs_intr->arch_regs = perf_get_arch_reg();
 }
 
 
-- 
2.7.4

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

#1471469 — [PATCH 12/13] tool/perf: Add perf_arch_reg mask and arch_reg_names structure

Add arch_reg_names structure and define perf_arch_reg_name() function
to aid the printing of arch_regs values. Also, extend regs_dump__printf()
to include perf_arch_regs_mask to enable printing support.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Stephane Eranian <eranian@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
 tools/perf/arch/arm/include/perf_regs.h     |  5 +++++
 tools/perf/arch/arm64/include/perf_regs.h   |  5 +++++
 tools/perf/arch/powerpc/include/perf_regs.h | 25 +++++++++++++++++++++++++
 tools/perf/arch/x86/include/perf_regs.h     |  5 +++++
 tools/perf/builtin-script.c                 |  7 +++++++
 tools/perf/util/perf_regs.h                 |  5 +++++
 tools/perf/util/session.c                   | 12 ++++++++++--
 7 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/tools/perf/arch/arm/include/perf_regs.h b/tools/perf/arch/arm/include/perf_regs.h
index f619c9c5a4bf..db5a5f0ad439 100644
--- a/tools/perf/arch/arm/include/perf_regs.h
+++ b/tools/perf/arch/arm/include/perf_regs.h
@@ -56,4 +56,9 @@ static inline const char *perf_reg_name(int id)
 	return NULL;
 }
 
+static inline const char *perf_arch_reg_name(int id __maybe_unused)
+{
+	return NULL;
+}
+
 #endif /* ARCH_PERF_REGS_H */
diff --git a/tools/perf/arch/arm64/include/perf_regs.h b/tools/perf/arch/arm64/include/perf_regs.h
index 4e5af27e3fbf..20f8067b3e93 100644
--- a/tools/perf/arch/arm64/include/perf_regs.h
+++ b/tools/perf/arch/arm64/include/perf_regs.h
@@ -90,4 +90,9 @@ static inline const char *perf_reg_name(int id)
 	return NULL;
 }
 
+static inline const char *perf_arch_reg_name(int id __maybe_unused)
+{
+	return NULL;
+}
+
 #endif /* ARCH_PERF_REGS_H */
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h b/tools/perf/arch/powerpc/include/perf_regs.h
index 75de0e92e71e..801de6def8da 100644
--- a/tools/perf/arch/powerpc/include/perf_regs.h
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -4,6 +4,7 @@
 #include <stdlib.h>
 #include <linux/types.h>
 #include <asm/perf_regs.h>
+#include <uapi/asm/perf_regs.h>
 
 #define PERF_REGS_MASK  ((1ULL << PERF_REG_POWERPC_MAX) - 1)
 #define PERF_REGS_MAX   PERF_REG_POWERPC_MAX
@@ -66,4 +67,28 @@ static inline const char *perf_reg_name(int id)
 {
 	return reg_names[id];
 }
+
+static const char *arch_reg_names[] = {
+	[PERF_ARCH_REG_POWERPC_PVR] = "pvr",
+	[PERF_ARCH_REG_POWERPC_PMC1] = "pmc1",
+	[PERF_ARCH_REG_POWERPC_PMC2] = "pmc2",
+	[PERF_ARCH_REG_POWERPC_PMC3] = "pmc3",
+	[PERF_ARCH_REG_POWERPC_PMC4] = "pmc4",
+	[PERF_ARCH_REG_POWERPC_PMC5] = "pmc5",
+	[PERF_ARCH_REG_POWERPC_PMC6] = "pmc6",
+	[PERF_ARCH_REG_POWERPC_PMC7] = "pmc7",
+	[PERF_ARCH_REG_POWERPC_PMC8] = "pmc8",
+	[PERF_ARCH_REG_POWERPC_MMCR0] = "mmcr0",
+	[PERF_ARCH_REG_POWERPC_MMCR1] = "mmcr1",
+	[PERF_ARCH_REG_POWERPC_SIER] = "sier",
+	[PERF_ARCH_REG_POWERPC_SIAR] = "siar",
+	[PERF_ARCH_REG_POWERPC_SDAR] = "sdar",
+	[PERF_ARCH_REG_POWERPC_MMCRA] = "mmcra",
+	[PERF_ARCH_REG_POWERPC_MMCR2] = "mmcr2"
+};
+
+static inline const char *perf_arch_reg_name(int id)
+{
+	return arch_reg_names[id];
+}
 #endif /* ARCH_PERF_REGS_H */
diff --git a/tools/perf/arch/x86/include/perf_regs.h b/tools/perf/arch/x86/include/perf_regs.h
index 7df517acfef8..a555541697b3 100644
--- a/tools/perf/arch/x86/include/perf_regs.h
+++ b/tools/perf/arch/x86/include/perf_regs.h
@@ -83,4 +83,9 @@ static inline const char *perf_reg_name(int id)
 	return NULL;
 }
 
+static inline const char *perf_arch_reg_name(int id __maybe_unused)
+{
+	return NULL;
+}
+
 #endif /* ARCH_PERF_REGS_H */
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index db270b4f892a..c2a84484b95b 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -420,6 +420,7 @@ static void print_sample_iregs(struct perf_sample *sample,
 {
 	struct regs_dump *regs = &sample->intr_regs;
 	uint64_t mask = attr->sample_regs_intr;
+	uint64_t arch_regs_mask = regs->arch_regs_mask;
 	unsigned i = 0, r;
 	DECLARE_BITMAP(_mask, 64);
 
@@ -431,6 +432,12 @@ static void print_sample_iregs(struct perf_sample *sample,
 		u64 val = regs->regs[i++];
 		printf("%5s:0x%"PRIx64" ", perf_reg_name(r), val);
 	}
+
+	bitmap_from_u64(_mask, arch_regs_mask);
+	for_each_set_bit(r, _mask, sizeof(mask) * 8) {
+		u64 val = regs->regs[i++];
+		printf("%5s:0x%"PRIx64" ", perf_arch_reg_name(r), val);
+	}
 }
 
 static void print_sample_start(struct perf_sample *sample,
diff --git a/tools/perf/util/perf_regs.h b/tools/perf/util/perf_regs.h
index 679d6e493962..1a044728bd45 100644
--- a/tools/perf/util/perf_regs.h
+++ b/tools/perf/util/perf_regs.h
@@ -29,6 +29,11 @@ static inline const char *perf_reg_name(int id __maybe_unused)
 	return NULL;
 }
 
+static inline const char *perf_arch_reg_name(int id __maybe_unused)
+{
+	return NULL;
+}
+
 static inline int perf_reg_value(u64 *valp __maybe_unused,
 				 struct regs_dump *regs __maybe_unused,
 				 int id __maybe_unused)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 440a9fb2a6fb..ca5c057c88af 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -941,7 +941,7 @@ static void branch_stack__printf(struct perf_sample *sample)
 	}
 }
 
-static void regs_dump__printf(u64 mask, u64 *regs)
+static void regs_dump__printf(u64 mask, u64 arch_regs_mask, u64 *regs)
 {
 	unsigned rid, i = 0;
 	DECLARE_BITMAP(_mask, 64);
@@ -953,6 +953,14 @@ static void regs_dump__printf(u64 mask, u64 *regs)
 		printf(".... %-5s 0x%" PRIx64 "\n",
 		       perf_reg_name(rid), val);
 	}
+
+	bitmap_from_u64(_mask, arch_regs_mask);
+	for_each_set_bit(rid, _mask, sizeof(mask) * 8) {
+		u64 val = regs[i++];
+
+		printf(".... %-5s 0x%" PRIx64 "\n",
+			perf_arch_reg_name(rid), val);
+	}
 }
 
 static const char *regs_abi[] = {
@@ -978,7 +986,7 @@ static void regs__printf(const char *type, struct regs_dump *regs)
 	       mask,
 	       regs_dump_abi(regs));
 
-	regs_dump__printf(mask, regs->regs);
+	regs_dump__printf(mask, regs->arch_regs_mask, regs->regs);
 }
 
 static void regs_user__printf(struct perf_sample *sample)
-- 
2.7.4

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

#1472601

On 28 August 2016 at 16:00, Madhavan Srinivasan
<maddy@linux.vnet.ibm.com> wrote:
> Patchset to extend PERF_SAMPLE_REGS_INTR to include
> platform specific PMU registers.
>
> Patchset applies cleanly on tip:perf/core branch
>
> It's a perennial request from hardware folks to be able to
> see the raw values of the pmu registers. Partly it's so that
> they can verify perf is doing what they want, and some
> of it is that they're interested in some of the more obscure
> info that isn't plumbed out through other perf interfaces.
>
> Over the years internally we have used various hack to get
> the requested data out but this is an attempt to use a
> somewhat standard mechanism (using PERF_SAMPLE_REGS_INTR).
>
> This would also be helpful for those of us working on the perf
> hardware backends, to be able to verify that we're programming
> things correctly, without resorting to debug printks etc.
>
> Mechanism proposed:
>
> 1)perf_regs structure is extended with a perf_arch_regs structure
> which each arch/ can populate with their specific platform
> registers to sample on each perf interrupt and an arch_regs_mask
> variable, which is for perf tool to know about the perf_arch_regs
> that are supported.
>
> 2)perf/core func perf_sample_regs_intr() extended to update
> the perf_arch_regs structure and the perf_arch_reg_mask. Set of new
> support functions added perf_get_arch_regs_mask() and
> perf_get_arch_reg() to aid the updates from arch/ side.
>
> 3) perf/core funcs perf_prepare_sample() and perf_output_sample()
> are extended to support the update for the perf_arch_regs_mask and
> perf_arch_regs in the sample
>
> 4)perf/core func perf_output_sample_regs() extended to dump
> the arch_regs to the output sample.
>
> 5)Finally, perf tool side is updated to include a new element
> "arch_regs_mask" in the "struct regs_dump", event sample funcs
> and print functions are updated to support perf_arch_regs.
>

I read the patch series and I have one suggestion to make.  I think we
should not use 'arch regs' to refer to these pmu registers.  I think
architectural registers typically refer to the ones that hold the
state of the process.  Can we replace arch_regs by pmu_regs, or some
other choice?

Thanks
Nilay

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

#1474034

On Tuesday 30 August 2016 09:31 PM, Nilay Vaish wrote:
> On 28 August 2016 at 16:00, Madhavan Srinivasan
> <maddy@linux.vnet.ibm.com> wrote:
>> Patchset to extend PERF_SAMPLE_REGS_INTR to include
>> platform specific PMU registers.
>>
>> Patchset applies cleanly on tip:perf/core branch
>>
>> It's a perennial request from hardware folks to be able to
>> see the raw values of the pmu registers. Partly it's so that
>> they can verify perf is doing what they want, and some
>> of it is that they're interested in some of the more obscure
>> info that isn't plumbed out through other perf interfaces.
>>
>> Over the years internally we have used various hack to get
>> the requested data out but this is an attempt to use a
>> somewhat standard mechanism (using PERF_SAMPLE_REGS_INTR).
>>
>> This would also be helpful for those of us working on the perf
>> hardware backends, to be able to verify that we're programming
>> things correctly, without resorting to debug printks etc.
>>
>> Mechanism proposed:
>>
>> 1)perf_regs structure is extended with a perf_arch_regs structure
>> which each arch/ can populate with their specific platform
>> registers to sample on each perf interrupt and an arch_regs_mask
>> variable, which is for perf tool to know about the perf_arch_regs
>> that are supported.
>>
>> 2)perf/core func perf_sample_regs_intr() extended to update
>> the perf_arch_regs structure and the perf_arch_reg_mask. Set of new
>> support functions added perf_get_arch_regs_mask() and
>> perf_get_arch_reg() to aid the updates from arch/ side.
>>
>> 3) perf/core funcs perf_prepare_sample() and perf_output_sample()
>> are extended to support the update for the perf_arch_regs_mask and
>> perf_arch_regs in the sample
>>
>> 4)perf/core func perf_output_sample_regs() extended to dump
>> the arch_regs to the output sample.
>>
>> 5)Finally, perf tool side is updated to include a new element
>> "arch_regs_mask" in the "struct regs_dump", event sample funcs
>> and print functions are updated to support perf_arch_regs.
>>
> I read the patch series and I have one suggestion to make.  I think we
> should not use 'arch regs' to refer to these pmu registers.  I think
Reason is that they are arch specific pmu regs. But I guess we can go with
pmu_regs also. And having a "pregs" as option to list in -I? will be fine?
(patch 13 in the patch series)


Maddy

> architectural registers typically refer to the ones that hold the
> state of the process.  Can we replace arch_regs by pmu_regs, or some
> other choice?
>
> Thanks
> Nilay
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web