This patch series is to support for using 'perf script' for CoreSight
trace disassembler, for this purpose this patch series adds a new
python script to parse CoreSight tracing event and use command 'objdump'
for disassembled lines, finally this can generate readable program
execution flow for reviewing tracing data.
Patch 0001 is one fixing patch to generate samples for the start packet
and exception packets.
Patch 0002 is the prerequisite to add addr into sample dict, so this
value can be used by python script to analyze instruction range.
Patch 0003 is to add python script for trace disassembler.
Patch 0004 is to add doc to explain python script usage and give
example for it.
This patch series has been rebased on acme git tree [1] with the commit
19422a9f2a3b ("perf tools: Fix kernel_start for PTI on x86") and tested
on Hikey (ARM64 octa CA53 cores).
In this version the script has no dependency on ARM64 platform and is
expected to support ARM32 platform, but I am lacking ARM32 platform for
testing on it, so firstly upstream to support ARM64 platform.
This patch series is firstly to support 'per-thread' recording tracing
data, but we also need to verify the script can dump trace disassembler
CPU wide tracing and kernel panic kdump tracing data. I also verified
this patch series which can work with kernel panic kdump tracing data,
because Mathieu is working on CPU wide tracing related work, so after
this we need to retest for CPU wide tracing and kdump tracing to ensure
the python script can handle well for all cases.
You are very welcome to test the script in this patch series, your
testing result and suggestion are very valuable to perfect this script
to cover more cases.
Changes from v2:
* Synced with Rob for handling CS_ETM_TRACE_ON packet, so refined 0001
patch according to dicussion;
* Minor cleanup and fixes in 0003 patch for python script: remove 'svc'
checking.
Changes from v1:
* According to Mike and Rob suggestion, add the fixing to generate samples
for the start packet and exception packets.
* Simplify the python script to remove the exception prediction algorithm,
we can rely on the sane exception packets for disassembler.
Leo Yan (4):
perf cs-etm: Generate branch sample for missed packets
perf script python: Add addr into perf sample dict
perf script python: Add script for CoreSight trace disassembler
coresight: Document for CoreSight trace disassembler
Documentation/trace/coresight.txt | 52 +++++
tools/perf/scripts/python/arm-cs-trace-disasm.py | 235 +++++++++++++++++++++
tools/perf/util/cs-etm.c | 93 ++++++--
.../util/scripting-engines/trace-event-python.c | 2 +
4 files changed, 362 insertions(+), 20 deletions(-)
create mode 100644 tools/perf/scripts/python/arm-cs-trace-disasm.py
--
2.7.4
This series is split of the Coresight ETR perf support patches posted
here [0]. The CATU support and perf backend support will be posted as
separate series for better management and review of the patches.
This series adds the support for TMC ETR Scatter-Gather mode to allow
using physical non-contiguous buffer for holding the trace data. It
also adds a layer to handle the buffer management in a transparent
manner, independent of the underlying mode used by the TMC ETR.
The layer chooses the ETR mode based on different parameters (size,
re-using a set of pages, presence of an SMMU etc.).
Finally we add a sysfs parameter to tune the buffer size for ETR in
sysfs-mode.
During the testing, we found out that if the TMC ETR is not properly
connected to the memory subsystem, the ETR could lock-up the system
while waiting for the "read" transactions to complete in scatter-gather
mode. So, we do not use the mode on a system unless it is safe to do
so. This is specified by a DT property "arm,scatter-gather".
Applies on v4.17-rc4
Changes since v2 in [0] :
- Split the series in [0]
- Address comments on v2
- Rename DT property "scatter-gather" to "arm,scatter-gather"
- Add ETM PID for Cortex-A35, use macros to make the listing easier
[0] - http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/574875.html
Suzuki K Poulose (11):
coresight: ETM: Add support for Arm Cortex-A73 and Cortex-A35
coresight: tmc: Hide trace buffer handling for file read
coresight: tmc-etr: Do not clean trace buffer
coresight: tmc-etr: Disallow perf mode
coresight: Add helper for inserting synchronization packets
dts: bindings: Restrict coresight tmc-etr scatter-gather mode
dts: juno: Add scatter-gather support for all revisions
coresight: Add generic TMC sg table framework
coresight: Add support for TMC ETR SG unit
coresight: tmc-etr: Add transparent buffer management
coresight: tmc: Add configuration support for trace buffer size
.../ABI/testing/sysfs-bus-coresight-devices-tmc | 8 +
.../devicetree/bindings/arm/coresight.txt | 5 +-
arch/arm64/boot/dts/arm/juno-base.dtsi | 1 +
drivers/hwtracing/coresight/coresight-etb10.c | 12 +-
drivers/hwtracing/coresight/coresight-etm4x.c | 32 +-
drivers/hwtracing/coresight/coresight-priv.h | 10 +-
drivers/hwtracing/coresight/coresight-tmc-etf.c | 45 +-
drivers/hwtracing/coresight/coresight-tmc-etr.c | 1032 ++++++++++++++++++--
drivers/hwtracing/coresight/coresight-tmc.c | 83 +-
drivers/hwtracing/coresight/coresight-tmc.h | 111 ++-
drivers/hwtracing/coresight/coresight.c | 3 +-
11 files changed, 1169 insertions(+), 173 deletions(-)
--
2.7.4
This patch series is to support for using 'perf script' for CoreSight
trace disassembler, for this purpose this patch series adds a new
python script to parse CoreSight tracing event and use command 'objdump'
for disassembled lines, finally this can generate readable program
execution flow for reviewing tracing data.
Patch 0001 is one fixing patch to generate samples for the start packet
and exception packets.
Patch 0002 is the prerequisite to add addr into sample dict, so this
value can be used by python script to analyze instruction range.
Patch 0003 is to add python script for trace disassembler.
Patch 0004 is to add doc to explain python script usage and give
example for it.
This patch series has been rebased on acme git tree [1] with the last
commit 19422a9f2a3b ("perf tools: Fix kernel_start for PTI on x86") and
tested on Hikey (ARM64 octa CA53 cores).
In this version the script has no dependency on ARM64 platform and is
expected to support ARM32 platform, but I am lacking ARM32 platform for
testing on it, so firstly upstream to support ARM64 platform.
This patch series is firstly to support 'per-thread' recording tracing
data, but we also need to verify the script can dump trace disassembler
CPU wide tracing and kernel panic kdump tracing data. I also verified
this patch series which can work with kernel panic kdump tracing data,
because Mathieu is working on CPU wide tracing related work, so after
this we need to retest for CPU wide tracing and kdump tracing to ensure
the python script can handle well for all cases.
You are very welcome to test the script in this patch series, your
testing result and suggestion are very valuable to perfect this script
to cover more cases.
Changes from v1:
* According to Mike and Rob suggestion, add the fixing to generate samples
for the start packet and exception packets.
* Simplify the python script to remove the exception prediction algorithm,
we can rely on the sane exception packets for disassembler.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
Leo Yan (4):
perf cs-etm: Generate sample for missed packets
perf script python: Add addr into perf sample dict
perf script python: Add script for CoreSight trace disassembler
coresight: Document for CoreSight trace disassembler
Documentation/trace/coresight.txt | 52 +++++
tools/perf/scripts/python/arm-cs-trace-disasm.py | 234 +++++++++++++++++++++
tools/perf/util/cs-etm.c | 35 ++-
.../util/scripting-engines/trace-event-python.c | 2 +
4 files changed, 316 insertions(+), 7 deletions(-)
create mode 100644 tools/perf/scripts/python/arm-cs-trace-disasm.py
--
2.7.4
Good morning Al,
Suzuki sent me this patch [1] that has the effect of printing the
following [2] in the kernel boot log at initialisation time. I think
it is quite useful since one can correlate CPU information and ETM
engine without having to go back to the DT or having to look at all
the tracers in sysFS. On the flip side I'm a little weary (since
peripheral numbers are implementation specific) that at one point we
may end up with say, a Cortex-A53 with different peripheral IDs or
another CPU type advertising a peripheral ID that is already taken.
As I said I think this is a good idea but before applying a change
that will be very public I'd like to make sure there aren't any
ramification we haven't thought about. Please let me know what you
think.
Best regards,
Mathieu
[1]. https://www.spinics.net/lists/arm-kernel/msg653904.html
[2]. https://pastebin.com/gbiLaJHJ
This patch series is to support for using 'perf script' for CoreSight
trace disassembler, for this purpose this patch series adds a new
python script to parse CoreSight tracing event and use command 'objdump'
for disassembled lines, finally this can generate readable program
execution flow for reviewing tracing data.
Patch 0001 is the prerequisite to add addr into sample dict, so this
value can be used by python script to analyze instruction range.
Patch 0002 is to add python script for trace disassembler.
Patch 0003 is to add doc to explain python script usage and give
example for it.
This patch series has been tested on Hikey (ARM64 octa CA53 cores).
The script is expected to extend a bit to support ARM32 platform, but
I am lacking ARM32 platform for testing on it, so firstly upstream to
support ARM64 platform firstly.
You are very welcome to test the script in this patch series, your
testing result and suggestion are very valuable to perfect this script
to cover more cases, at the end we will have more confidence to upstream
into mainline kernel.
Leo Yan (3):
perf script python: Add addr into perf sample dict
perf script python: Add script for CoreSight trace disassembler
coresight: Document for CoreSight trace disassembler
Documentation/trace/coresight.txt | 52 ++++
tools/perf/scripts/python/arm-cs-trace-disasm.py | 324 +++++++++++++++++++++
.../util/scripting-engines/trace-event-python.c | 2 +
3 files changed, 378 insertions(+)
create mode 100644 tools/perf/scripts/python/arm-cs-trace-disasm.py
--
2.7.4
Hello Mathieu,
Thank for the config file. It works. I was able to build the OpenCSD kernel (form the perf-opencsd-master branch) and install on the USB (I used the ArchLinuxARM-aarch64-latest.tar.gz). I also built the perf tool (make -C tools/perf). Everything is booting but the perf has some issues:
[root@alarm home]# ./perf record -vvv -e cs_etm/(a)20070000.etr/u --per-thread uname
map_groups__set_modules_path_dir: cannot open /lib/modules/4.13.0-rc1-ge565ad6 dir
Problems setting modules path maps, continuing anyway...
------------------------------------------------------------
perf_event_attr:
type 8
size 112
{ sample_period, sample_freq } 1
sample_type IP|TID|IDENTIFIER
read_format ID
disabled 1
exclude_kernel 1
exclude_hv 1
enable_on_exec 1
sample_id_all 1
------------------------------------------------------------
sys_perf_event_open: pid 2242 cpu -1 group_fd -1 flags 0x8 = 4
------------------------------------------------------------
perf_event_attr:
type 1
size 112
config 0x9
{ sample_period, sample_freq } 1
sample_type IP|TID|IDENTIFIER
read_format ID
disabled 1
exclude_kernel 1
exclude_hv 1
mmap 1
comm 1
enable_on_exec 1
task 1
sample_id_all 1
mmap2 1
comm_exec 1
------------------------------------------------------------
sys_perf_event_open: pid 2242 cpu -1 group_fd -1 flags 0x8 = 5
mmap size 528384B
AUX area mmap length 4194304
perf event ring buffer mmapped per thread
failed to mmap AUX area
failed to mmap with 12 (Cannot allocate memory)
I fixed the "map_groups__set_modules_path_dir: cannot open /lib/modules/4.13.0-rc1-ge565ad6 dir" issue by adding appropriate symbolic link but I still have an issue with the mmap. Any idea what can be wrong here (below limits that I have on my Juno)?
[root@alarm ~]# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31798
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 31798
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[root@alarm ~]#
Regards
Marek
W dniu 2017-08-18 16:54:42 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał:
> On 18 August 2017 at 04:22, marekzmyslowski
> <marekzmyslowski(a)poczta.onet.pl> wrote:
> > Hello Mathieu,
> >
> > I've decided that currently I don't need Android. The Linux is enough.
>
> That is probably a better place to start.
>
> > However I have another issue. I've downloaded the perf-opencsd-master branch. I run the config with the ARCH=arm64 and CROSS_COMPLIE=aarch64-linux-gnu- and added support for Versatile board. Then I compiled kernel - everything was OK. Next I built the USB using the following instruction:
> > https://archlinuxarm.org/platforms/armv8/arm/juno (it works fine. The linux boot on the Juno).
> > Next I copied the Image file and juno.dtb into the USB but it doesn't boot. It hangs here:
> >
> > initrd: address 0x0
> > initrd: length 0x0
> > PEI 1132 ms
> > DXE 1695 ms
> > BDS 368934875444 ms
> > BDS 368934873448 ms
> > BDS 1535 ms
> > Total Time = 368934871781 ms
> >
> > linux: address 0x80080000
> > linux: length 0x1150200
> > fdt: address 0x9FE00000
> > fdt: length 0x5F54
> >
> > Any idea what I'm doing wrong? Any help will be appreciated (I'm so close to have Juno + CoreSight + perf :) )
>
> I can't help you with booting the board itself. The best I can do is
> advise to use u-boot instead of UEFI and give you my kernel .config
> file (attached). For the rest there is plenty of documentation out
> there.
>
> >
> > Regards
> > Marek
> >
> > W dniu 2017-08-16 23:08:04 użytkownik Mathieu Poirier <mathieu.poirier(a)linaro.org> napisał:
> >> Hello Marek,
> >>
> >> Please CC the CoreSight mailing list when asking questions as someone
> >> else may also be able to answer.
> >>
> >> First and foremost I advise using the official CoreSight kernel found
> >> on the openCSD site [1] rather than my personal branch [2] - you
> >> never know what you'll get with the latter.
> >>
> >> That being said the CoreSight kernel on the openCSD site is not an
> >> Android kernel - it is simply a mainline kernel supplemented with
> >> patches that haven't made their way to mainline yet. You will have to
> >> either add the android patches to the CoreSight kernel or the other
> >> way around (CoreSight patches on android kernel).
> >>
> >> Android user space is also different and does not include the
> >> perf-tools. You will have to add them manually along with the
> >> dependencies they require. I haven't gone through that process and as
> >> such can't advise more on that portion.
> >>
> >> Get back to me with your questions if the above isn't sufficient.
> >>
> >> Best regards,
> >> Mathieu
> >>
> >> [1]. https://github.com/Linaro/OpenCSD/tree/perf-opencsd-master
> >> [2]. https://git.linaro.org/people/mathieu.poirier/coresight.git/
> >>
> >> On 16 August 2017 at 14:32, marekzmyslowski
> >> <marekzmyslowski(a)poczta.onet.pl> wrote:
> >> > Hello Mathieu,
> >> >
> >> > I'm sorry for bothering but I think you may be person that can help me. I'm trying to install and run Android on Juno Board r0. I tested Android 17.05 from Linaro and it works. Now I'm trying to have a perf using Coresight but I'm little confused. Do I need to build Android from Linaro and the kernel from here https://git.linaro.org/people/mathieu.poirier/coresight.git/ or here https://github.com/Linaro/OpenCSD/tree/perf-opencsd-4.12.
> >> > Any help with this will be appreciated :)
> >> >
> >> > Regards
> >> > Marek Zmysłowski
> >>
> >
> >
> >
>
<div dir="ltr"><p class="gmail-MsoNoSpacing"><span
style="color:rgb(31,78,121)">Hi,<span></span></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Hope this
note finds you well!</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Would you
be interested in <b>Point Of Sale Software Users List</b>? We are a Global
Technology
User’s List Provider’s with 90 Million Plus data and counting.</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">It is good
if you keep track of all your competitors'
movements and their campaign strategies. But do not make their strategies of
your own; you can never beat them that way. Even if the industry is the
same,
each organization has some specific business goals in mind that requires a
campaign-plan that is different from others. Considering the fact that data
requirement for every marketer will be non-identical as per their campaign
planning, we at first consult with our clients to understand their
strategies
and then tailor personalized <b>list of
companies using POS software </b>accordingly<b>.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Do not
hesitate to take the smart step for improving your
business. Deliver highly targeted campaign to your customers and prospects
using the comprehensive <b>Retail
Management (POS) Software user</b> group’s data, drive the right traffic to
your website and <b>generate quality leads
through targeted b2b marketing.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">By
partnering with us you can obtain an effective email
list of Point of Sale software customers, where each record comes with
<b>full contact name, complete postal address,
mobile telephone number and email addresses, and much more.</b></span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Please let
us know your targeted criteria and geography to
provide you with detailed information for your review.</span></p>
<p class="gmail-MsoNoSpacing"><span style="color:rgb(31,78,121)">Let me
know your thoughts!</span></p>
<p class="gmail-MsoNoSpacing"><span
style="color:rgb(31,78,121)">Thanks,<span></span></span></p>
<p class="gmail-MsoNoSpacing"><b><span style="color:rgb(31,78,121)">Gemma
White<span></span></span></b></p>
<p class="gmail-MsoNoSpacing"><b><span style="color:rgb(31,78,121)">Senior
Database Executive</span></b></p>
<p class="gmail-MsoNoSpacing"><span
style="color:rgb(156,194,229)">
To “opt out” response not interested<span></span></span></p>
<p class="MsoNormal"><span> </span></p></div>
<p> </p><a style='display: block; margin: 32px 0 40px 0; padding:
10px; font-size: 1em; text-align: center; border: 0; border-top: 1px solid
gray; ' href='https://goo.gl/2ksdRv'>powered by GSM. Free mail merge and
email marketing software for Gmail.</a>
CoreSight doesn't allocate thread structure for unknown_thread in etm
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in segmentation fault when
thread__find_addr_map() accesses thread handler.
This commit creates new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier(a)linaro.org>
---
tools/perf/util/cs-etm.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 6533b1a..69f21de 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -239,6 +239,7 @@ static void cs_etm__free(struct perf_session *session)
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -1355,6 +1356,23 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(999999999, 999999999);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+ * Initialize list node so that at thread__zput() we can avoid
+ * segmentation fault at list_del_init().
+ */
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -1369,16 +1387,18 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
--
2.7.4
CoreSight doesn't allocate thread structure for unknown_thread in etm
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in segmentation fault when
thread__find_addr_map() accesses thread handler.
This commit creates new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan <leo.yan(a)linaro.org>
---
tools/perf/util/cs-etm.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 6533b1a..417302c 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -239,6 +239,7 @@ static void cs_etm__free(struct perf_session *session)
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -266,6 +267,7 @@ static u32 cs_etm__mem_access(struct cs_etm_queue *etmq, u64 address,
if (!thread) {
if (cpumode != PERF_RECORD_MISC_KERNEL)
return -EINVAL;
+
thread = etmq->etm->unknown_thread;
}
@@ -1355,6 +1357,23 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(999999999, 999999999);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+ * Initialize list node so that at thread__zput() we can avoid
+ * segmentation fault at list_del_init().
+ */
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -1369,16 +1388,18 @@ int cs_etm__process_auxtrace_info(union perf_event *event,
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
--
2.7.4