CoreSight

coresight@lists.linaro.org

4 participants
2387 discussions

[RFC PATCH 0/5] Mods to extend ETMv4 support to ETM v4.4

by Mike Leach

Patchset updates ETMv4 trace decoder to support protocols up to ETMv4.4 Update of instruction decode library made to cover new instructions - primarily authenticated pointer calls and returns. Set will form part of next OpenCSD library release at 0.11.0 Mike Mike Leach (5): opencsd: ETMv4.4: update common types and etm 4 config opencsd: ETMv4.4: Update all decoders to init new parameters opencsd: ETMv4.4: Update instruction decoder. opencsd: ETMv4.4: protocol decoder modifications. opencsd: Update lib version decoder/include/i_dec/trc_i_decode.h | 1 + decoder/include/i_dec/trc_idec_arminst.h | 9 + .../include/opencsd/etmv4/trc_cmp_cfg_etmv4.h | 20 +- .../opencsd/etmv4/trc_etmv4_stack_elem.h | 3 +- .../opencsd/etmv4/trc_pkt_elem_etmv4i.h | 5 +- .../opencsd/etmv4/trc_pkt_types_etmv4.h | 137 ++++--- decoder/include/opencsd/ocsd_if_types.h | 11 +- decoder/include/opencsd/ocsd_if_version.h | 6 +- decoder/source/etmv4/trc_cmp_cfg_etmv4.cpp | 2 + .../source/etmv4/trc_pkt_decode_etmv4i.cpp | 24 ++ .../source/etmv4/trc_pkt_proc_etmv4i_impl.cpp | 374 ++++++++++++------ .../source/etmv4/trc_pkt_proc_etmv4i_impl.h | 75 ++-- decoder/source/i_dec/trc_i_decode.cpp | 50 ++- decoder/source/i_dec/trc_idec_arminst.cpp | 99 ++++- decoder/source/ocsd_code_follower.cpp | 1 + decoder/source/ptm/trc_pkt_decode_ptm.cpp | 1 + 16 files changed, 586 insertions(+), 232 deletions(-) -- 2.20.1

6 years, 4 months

Timestamps always 0x0 on Xilinx Zynq Ultrascale+

by Wojciech Żmuda

Hi, I'm trying to run Coresight on XIlinx Zynq Ultrascale+ with ZCU104 board. I have already made some progress, however I'm stuck on getting valid timestamp packets in the decoded trace. I'm using mainline Linux forked at v5.0-rc4. So far, I manually added Coresight nodes to DTS basing on the Ultrascale+ datasheet, since neither mainline Linux nor the Xilinx fork seem to have it. Looks like this step went fine, since I can see drivers reporting in dmesg and related sysfs nodes being registered: root@zynq:~# dmesg | grep -i coresight [ 3.745681] coresight-etm4x fec40000.etm0: CPU0: ETM v4.0 initialized [ 3.752318] coresight-etm4x fed40000.etm1: CPU1: ETM v4.0 initialized [ 3.758952] coresight-etm4x fee40000.etm2: CPU2: ETM v4.0 initialized [ 3.765587] coresight-etm4x fef40000.etm3: CPU3: ETM v4.0 initialized [ 3.772190] coresight-stm fe9c0000.stm: stm_register_device failed, probing deferred [ 3.780004] coresight-cpu-debug fec10000.debug0: Coresight debug-CPU0 initialized [ 3.787531] coresight-cpu-debug fed10000.debug1: Coresight debug-CPU1 initialized [ 3.795058] coresight-cpu-debug fee10000.debug2: Coresight debug-CPU2 initialized [ 3.802587] coresight-cpu-debug fef10000.debug3: Coresight debug-CPU3 initialized [ 3.917423] coresight-stm fe9c0000.stm: STM500 initialized root@zynq:~# ls /sys/bus/coresight/devices/ fe920000.funnel1 fe940000.etf1 fe970000.etr fe9c0000.stm fed40000.etm1 fef40000.etm3 fe930000.funnel2 fe950000.etf2 fe980000.tpiu fec40000.etm0 fee40000.etm2 replicator Overall trace acquisition and decoding with perf+OpenCSD also looks good, apart from timestamp packets. When I request timestamping, the value is constant 0x0: root@zynq:~/cs_test# perf record -e cs_etm/timestamp,(a)fe940000.etf1/u --filter 'filter 0x764/0x2c@./sum' --per-thread ./sum Val: 20 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.002 MB perf.data ] root@zynq:~/cs_test# perf report --dump | grep TIMESTAMP Idx:231; ID:12; I_TIMESTAMP : Timestamp.; Updated val = 0x0 Idx:254; ID:12; I_TIMESTAMP : Timestamp.; Updated val = 0x0 Idx:279; ID:12; I_TIMESTAMP : Timestamp.; Updated val = 0x0 According to the datasheet, Ultrascale+ has a timestamp generator. Perf confirms it in the registers values dump: root@zynq:~/cs_test# perf report --dump | grep 'TRCCONFIGR\|TRCIDR0' TRCCONFIGR 800 TRCIDR0 28000ea1 TRCCONFIGR 800 TRCIDR0 28000ea1 TRCCONFIGR 800 TRCIDR0 28000ea1 TRCCONFIGR 800 TRCIDR0 28000ea1 These value match what ETMv4 architecture specs says: - bit 11 (TS) of TRCCONFIGR is 1, what indicates global timestamping is enabled - bits 24:28 (TSSIZE) of TRCIDR0 are 0b1000, what indicates support for 64-bit-long timestamps In the kernel source code I can see that the ETMv4 driver writes the EVENT bits (0:7) of the TRCTSCTLR register. I didn't thoroughly analyze this code, but I take it as another hint that timestamping is actually supported. At this point I wonder if anybody has witnessed timestamps working on this platform, whether under Linux or baremetal. I would appreciate even the tiniest suggestions where should I look next to get them working. Thanks and best regards, Wojciech

6 years, 4 months

Database Sellers

by Katherine Allison

Hi, Can I send you a Price of one of our Database Sellers based on your requirement? Kindly just share your requirements by filling in the below table: Industries : ----------------------- Job Titles : ----------------------- Geography : ---------------------- I'll come up with the data counts, costs & few sample contacts for your review. Regards, Katherine Allison Business Development

6 years, 4 months

[v5.0-rc6 regression] "perf/core: Don't WARN() for impossible ring-buffer sizes"

by Mathieu Poirier

Hi Mark, CoreSight trace collection is broken on v5.0-rc6 due to this commit: 9dff0aa95a32 perf/core: Don't WARN() for impossible ring-buffer sizes Before: root@juno:/home/linaro# perf record -e cs_etm/(a)20070000.etr/u --per-thread uname [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.036 MB perf.data ] root@juno:/home/linaro# After: root@juno:/home/linaro# perf record -e cs_etm/(a)20070000.etr/u --per-thread uname failed to mmap with 12 (Cannot allocate memory) root@juno:/home/linaro# The problem is related to the order_base_2() [1] test with a size of 1264, stemming from nr_pages equal to 128. The combination yields an order of 11, something leading directly to the error path. The results are the same with linux-next 20190213. This was tested on a Juno R0 and R1 with a 4K page configuration. I haven't tried but I'm pretty sure it breaks IntelPT as well. Please have a look when you have a minute. Leo Yan and I will be happy to test patches. Thanks, Mathieu [1]. https://elixir.bootlin.com/linux/v5.0-rc6/source/kernel/events/ring_buffer.…

6 years, 4 months

[v5.0-rc6 regression] "perf/core: Don't WARN() for impossible ring-buffer sizes"

by Mathieu Poirier

6 years, 4 months

Fwd: HEADS UP: disable building with opencsd by default

by Mathieu Poirier

This is important - see below. Once this change is released I will send a patch to update the HOWTO.md on github. Mathieu ---------- Forwarded message --------- From: Arnaldo Carvalho de Melo <acme(a)kernel.org> Date: Tue, 12 Feb 2019 at 11:04 Subject: HEADS UP: disable building with opencsd by default To: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Jiri Olsa <jolsa(a)kernel.org>, Kim Phillips <kim.phillips(a)arm.com>, < linux-arm-kernel(a)lists.infradead.org>, Mike Leach <mike.leach(a)arm.com>, Namhyung Kim <namhyung(a)kernel.org>, Peter Zijlstra <peterz(a)infradead.org>, Suzuki Poulouse <suzuki.poulose(a)arm.com>, Ingo Molnar <mingo(a)kernel.org> Please see the rationale on the cset, this test-all.c thing was done by Ingo long ago to speed up the build of the tools by checking first if the common set of libraries is present, and because this isn't being properly checked I left several cases pass, like opencsd, libaio and libcrypto, that I'm working as well and have fixes in my perf/core branch. - Arnaldo commit b7213083e3f3d69fffb5229034b3ac3ca9d41038 Author: Arnaldo Carvalho de Melo <acme(a)redhat.com> Date: Tue Feb 12 14:37:15 2019 -0300 perf coresight: Do not test for libopencsd by default Since it is not yet that generally available, avoid testing for the presence of libcoresight in the fast path test-all.bin feature test. # dnf search opencsd No matches found. # dnf search OpenCSD No matches found. # cat /etc/fedora-release Fedora release 29 (Twenty Nine) # I.e. right now, in my system test-all.bin is failing all the time since Fedora29 doesn't have libopencsd available: $ cat /tmp/build/perf/feature/test-all.make.output In file included from test-all.c:174: test-libopencsd.c:2:10: fatal error: opencsd/c_api/opencsd_c_api.h: No such file or directory #include <opencsd/c_api/opencsd_c_api.h> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. See: 6ab2b762befd ("perf build: Disable libbabeltrace check by default") For the rationale, as soon as libopencsd becomes more generally packaged and available, we do the same thing we did with babeltrace, enabling it by default, as done in: 24787afbcd01 ("perf tools: Enable LIBBABELTRACE by default") For now, to explicitely ask for opencsd, make sure you have it installed and use: make -C tools/perf CORESIGHT=1 The feature test output will be there as an empty file: $ ls -la /tmp/build/perf/feature/test-libopencsd.make.output Because the binary used for the feature check was successfully built: $ ls -la /tmp/build/perf/feature/test-libopencsd.bin -rwxrwxr-x. 1 acme acme 18336 Feb 12 14:49 /tmp/build/perf/feature/test-libopencsd.bin $ ldd /tmp/build/perf/feature/test-libopencsd.bin linux-vdso.so.1 (0x00007fffe18cc000) libopencsd_c_api.so.0 => /lib64/libopencsd_c_api.so.0 (0x00007fb8e67f6000) libopencsd.so.0 => /lib64/libopencsd.so.0 (0x00007fb8e676f000) libc.so.6 => /lib64/libc.so.6 (0x00007fb8e65a9000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb8e6411000) libm.so.6 => /lib64/libm.so.6 (0x00007fb8e628d000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb8e6272000) /lib64/ld-linux-x86-64.so.2 (0x00007fb8e6828000) $ And the resulting perf binary will be linked with it: -rw-rw-r--. 1 acme acme 0 Feb 12 14:49 /tmp/build/perf/feature/test-libopencsd.make.output $ ldd ~/bin/perf | grep opencsd libopencsd_c_api.so.0 => /lib64/libopencsd_c_api.so.0 (0x00007fd43097f000) libopencsd.so.0 => /lib64/libopencsd.so.0 (0x00007fd4308f8000) $ To make sure this gets built before pushing things upstream I have a ubuntu:19.04-x-arm64 container that has: [root@quaco x-arm64]# grep CORESIGHT Dockerfile ENV EXTRA_MAKE_ARGS=CORESIGHT=1 [root@quaco x-arm64]# So that I always build with libopencsd before pushing things upstream. Cc: Adrian Hunter <adrian.hunter(a)intel.com> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Jiri Olsa <jolsa(a)kernel.org> Cc: Kim Phillips <kim.phillips(a)arm.com> Cc: linux-arm-kernel(a)lists.infradead.org Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Mike Leach <mike.leach(a)arm.com> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Suzuki Poulouse <suzuki.poulose(a)arm.com> Link: https://lkml.kernel.org/n/tip-20vyy39jw9jgrijesi30fgox@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature index 5467c6bf9ceb..bb9dca65eb5f 100644 --- a/tools/build/Makefile.feature +++ b/tools/build/Makefile.feature @@ -70,7 +70,6 @@ FEATURE_TESTS_BASIC := \ sched_getcpu \ sdt \ setns \ - libopencsd \ libaio # FEATURE_TESTS_BASIC + FEATURE_TESTS_EXTRA is the complete list @@ -84,6 +83,7 @@ FEATURE_TESTS_EXTRA := \ libbabeltrace \ libbfd-liberty \ libbfd-liberty-z \ + libopencsd \ libunwind-debug-frame \ libunwind-debug-frame-arm \ libunwind-debug-frame-aarch64 \ diff --git a/tools/build/feature/test-all.c b/tools/build/feature/test-all.c index 20cdaa4fc112..74329957553a 100644 --- a/tools/build/feature/test-all.c +++ b/tools/build/feature/test-all.c @@ -170,10 +170,6 @@ # include "test-setns.c" #undef main -#define main main_test_libopencsd -# include "test-libopencsd.c" -#undef main - #define main main_test_libaio # include "test-libaio.c" #undef main @@ -217,7 +213,6 @@ int main(int argc, char *argv[]) main_test_sched_getcpu(); main_test_sdt(); main_test_setns(); - main_test_libopencsd(); main_test_libaio(); return 0; diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index b441c88cafa1..e3bf29f942a8 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -386,7 +386,8 @@ ifeq ($(feature-setns), 1) $(call detected,CONFIG_SETNS) endif -ifndef NO_CORESIGHT +ifdef CORESIGHT + $(call feature_check,libopencsd) ifeq ($(feature-libopencsd), 1) CFLAGS += -DHAVE_CSTRACE_SUPPORT $(LIBOPENCSD_CFLAGS) LDFLAGS += $(LIBOPENCSD_LDFLAGS) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 09df1c8a4ec9..c2ccc54618d1 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -102,7 +102,7 @@ include ../scripts/utilities.mak # When selected, pass LLVM_CONFIG=/path/to/llvm-config to `make' if # llvm-config is not in $PATH. # -# Define NO_CORESIGHT if you do not want support for CoreSight trace decoding. +# Define CORESIGHT if you DO WANT support for CoreSight trace decoding. # # Define NO_AIO if you do not want support of Posix AIO based trace # streaming for record mode. Currently Posix AIO trace streaming is

6 years, 4 months

[PATCH v5 0/3] Update AMBA driver for enhanced component ID spec.

by Mike Leach

The latest ARM CoreSight specification updates the component identification requirements for all components attached to an AMBA bus. (ARM IHI 0029E) This specification defines bits 15:12 in the ComponentID (CID) value as the device class. Identification requirements now depend on this class. Class 0xF: Traditional components identified by Peripheral ID (PID) only. Class 0x9: CoreSight components may be identified by a Universal Component Identifier (UCI) consisting of the PID plus CoreSight DevType and DevArch values. Current and future ARM CoreSight IP will now use the same PID for components on the same function - e.g. the ETM, CTI, PMU and Debug elements associated with a core. The first core to use this UCI method is the A35, which currently has binding entries in the ETMv4 driver. This patchset prepares for the addition of the upcoming CTI driver, which will need to correctly bind with A35, and reported new devices that share PID for multiple components, while overcoming the limitation of binding by PID alone, which cannot now work. Patch 0001: Adds new UCI data structure and uses it with existing drivers that use private data field in amba_id. This fixes issue from prior set. Patch 0002: Implements the UCI matching code in the AMBA core code. Patch 0003: Update ETMv4 driver to use UCI as appropriate. Thanks Mike Tested on DB410, Juno; kernel 5.0-rc6 Changes since v4: re-based on 5.0-rc6 Added reviewed/tested by tags. Changes since v3: Fix UCI structure to allow CoreSight drivers to set private data. This fixes bug where none-UCI private data would cause a driver binding mismatch. (e.g. STM). Add CS_AMBA macros to simplify building AMBA ID tables, with and without UCI settings. Changes since v2: Simplification of amba_cs_uci_id_match(). Fix CID class bitfield comments. Dropped RFC tag on patchset. Mike Leach (3): drivers: amba: Updates to component identification for driver matching. drivers: amba: Update component matching to use the CoreSight UCI values. coresight: etmv4: Update ID register table to add UCI support drivers/amba/bus.c | 45 +++++++++++++++---- drivers/hwtracing/coresight/coresight-etm3x.c | 44 ++++++------------ drivers/hwtracing/coresight/coresight-etm4x.c | 21 +++++---- drivers/hwtracing/coresight/coresight-priv.h | 40 +++++++++++++++++ drivers/hwtracing/coresight/coresight-stm.c | 14 ++---- drivers/hwtracing/coresight/coresight-tmc.c | 30 ++++--------- include/linux/amba/bus.h | 39 ++++++++++++++++ 7 files changed, 153 insertions(+), 80 deletions(-) -- 2.19.1

6 years, 4 months

[PATCH v7 0/8] perf cs-etm: Add support for sample flags

by Leo Yan

This patch seris adds support for sample flags so can facilitate perf to print sample flags for branch instruction. Patch 0001 is used to save last branch information in packet structure, this includes instruction type, subtype and condition flag to help making decision for which branch instruction it is. It passes related information from decoder layer to cs-etm.c, so we use cs-etm.c as a central place to set sample flags. Patch 0002 is used to set sample flags for instruction range packet. Patch 0003 is used to set sample flags for trace discontinuity packet. Patches 0004/0005/0006 are preparation for exception packet handling: Patch 0004 addes exception number in packet; pacth 0005/0006 is to use traceID/metadata tuple to access metadata pointer based on traceID, this can help decide if the CPU is connected with ETMv3 or ETMv4, ETMv3 and ETMv4 have totally different definition for exception numbers. Patch 0007 sets sample flags for exception packet; patch 0008 support sample flags for exception return packet. This patch set is applied on the acme's perf core branch with the latest commit bdec77cfe58d ("Merge remote-tracking branch 'tip/perf/urgent' into perf/core"). This patch set has been verified for x86 and arm64 perf building and also is verified with below command: Before: # perf script -F,-time,+flags -k vmlinux [...] main 6650 [001] 1 branches: f7b08490 lib_loop_test+0xc (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: f7b084b0 lib_loop_test+0x2c (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: 6b65a8 main+0x1c (/root/coresight_test/main) main 6650 [001] 1 branches: 6b6448 printf@plt+0x8 (/root/coresight_test/main) main 6650 [001] 1 branches: 6b642c _init+0x18 (/root/coresight_test/main) main 6650 [001] 1 branches: f7b2d23c [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2906e [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b255ee [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: f7b25634 [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) [...] After: # perf script -F,-time,+flags -k vmlinux [...] main 6650 [001] 1 branches: jmp f7b08490 lib_loop_test+0xc (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: jcc f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: jcc f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: jcc f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: jcc f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: jcc f7b084a2 lib_loop_test+0x1e (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: return f7b084b0 lib_loop_test+0x2c (/root/coresight_test/libcstest.so) main 6650 [001] 1 branches: call 6b65a8 main+0x1c (/root/coresight_test/main) main 6650 [001] 1 branches: return 6b6448 printf@plt+0x8 (/root/coresight_test/main) main 6650 [001] 1 branches: return 6b642c _init+0x18 (/root/coresight_test/main) main 6650 [001] 1 branches: call f7b2d23c [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: call f7b2906e [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jcc f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jcc f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jcc f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jcc f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jcc f7b2559a [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: jmp f7b255ee [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) main 6650 [001] 1 branches: call f7b25634 [unknown] (/usr/lib/arm-linux-gnueabihf/ld-2.27.so) [...] Changes from v6: * Addressed Mathieu's suggestion for patch 0005, refined its commit log and comment and fixed cs_etm__get_cpu() definitions in header file; also tested with perf for Arm and x86 buildings. * Added Mathieu's review tags. Changes from v5: * Addressed Rob's suggestion to add specification info for exception number encoding; * Added Rob's review tag in patch 0007. Changes from v4: * Fixed typos in comments, and removed redundant info from commit log; * Addressed Mathieu's suggestion to add helper functions for metadata fields (CS_ETM_CPU and CS_ETM_MAGIC) accessing; * Addressed Mathieu's suggestion to include headers with alphabetical order. Changes from v3: * Fixed typos in commit logs; * Rearranged fields in cs_etm_packet by grouping with same variable types; * Fixed ETMv4 exception number which pointed by Mike; * Fixed ETMv4 SVC / SMC / HVC in the same CALL, by checking svc instruction to distinguish them; * Refine ETMv4 return exception packet handling. Changes from v2: * Addressed Mathieu's suggestion to split one big patch to 3 small patches for setting sample flags, one is for instruction range packet, one is for discontinuity packet and one is for exception packet. * Added supporting for ETMv3 exception packet. * Followed Mathieu's suggestion to move all sample flags handling from decoder layer to cs-etm.c, thus it has enough info to set flags based on trace context in single place. Changes from v1: * Moved exception packets handling patches into patch series 'perf cs-etm: Correct packets handling'. * Added sample flags fixing up for TRACE_OFF packet. * Created a new function which is used to maintain flags fixing up. Leo Yan (8): perf cs-etm: Add last instruction information in packet perf cs-etm: Set sample flags for instruction range packet perf cs-etm: Set sample flags for trace discontinuity perf cs-etm: Add exception number in exception packet perf cs-etm: Change tuple from traceID-CPU# to traceID-metadata perf cs-etm: Add traceID in packet perf cs-etm: Set sample flags for exception packet perf cs-etm: Set sample flags for exception return packet .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 41 +- .../perf/util/cs-etm-decoder/cs-etm-decoder.h | 6 + tools/perf/util/cs-etm.c | 394 +++++++++++++++++- tools/perf/util/cs-etm.h | 53 ++- 4 files changed, 476 insertions(+), 18 deletions(-) -- 2.17.1

6 years, 4 months

[PATCH v4 0/3] Update AMBA driver for enhanced component ID spec.

by Mike Leach

The latest ARM CoreSight specification updates the component identification requirements for all components attached to an AMBA bus. (ARM IHI 0029E) This specification defines bits 15:12 in the ComponentID (CID) value as the device class. Identification requirements now depend on this class. Class 0xF: Traditional components identified by Peripheral ID (PID) only. Class 0x9: CoreSight components may be identified by a Universal Component Identifier (UCI) consisting of the PID plus CoreSight DevType and DevArch values. Current and future ARM CoreSight IP will now use the same PID for components on the same function - e.g. the ETM, CTI, PMU and Debug elements associated with a core. The first core to use this UCI method is the A35, which currently has binding entries in the ETMv4 driver. This patchset prepares for the addition of the upcoming CTI driver, which will need to correctly bind with A35, and reported new devices that share PID for multiple components, while overcoming the limitation of binding by PID alone, which cannot now work. Patch 0001: Adds new UCI data structure and uses it with existing drivers that use private data field in amba_id. This fixes issue from prior set. Patch 0002: Implements the UCI matching code in the AMBA core code. Patch 0003: Update ETMv4 driver to use UCI as appropriate. Thanks Mike Tested on DB410, Juno; kernel 5.0-rc4 Changes since v3: Fix UCI structure to allow CoreSight drivers to set private data. This fixes bug where none-UCI private data would cause a driver binding mismatch. (e.g. STM). Add CS_AMBA macros to simplify building AMBA ID tables, with and without UCI settings. Changes since v2: Simplification of amba_cs_uci_id_match(). Fix CID class bitfield comments. Dropped RFC tag on patchset. Mike Leach (3): drivers: amba: Updates to component identification for driver matching. drivers: amba: Update component matching to use the CoreSight UCI values. coresight: etmv4: Update ID register table to add UCI support drivers/amba/bus.c | 45 +++++++++++++++---- drivers/hwtracing/coresight/coresight-etm3x.c | 44 ++++++------------ drivers/hwtracing/coresight/coresight-etm4x.c | 21 +++++---- drivers/hwtracing/coresight/coresight-priv.h | 40 +++++++++++++++++ drivers/hwtracing/coresight/coresight-stm.c | 14 ++---- drivers/hwtracing/coresight/coresight-tmc.c | 30 ++++--------- include/linux/amba/bus.h | 39 ++++++++++++++++ 7 files changed, 153 insertions(+), 80 deletions(-) -- 2.19.1

6 years, 4 months

[PATCH 43/53] perf cs-etm: Set sample flags for exception return packet

by Arnaldo Carvalho de Melo

From: Leo Yan <leo.yan(a)linaro.org> When return from exception, we need to distinguish if it's system call return or for other type exceptions for setting sample flags. Due to the exception return packet doesn't contain exception number, so we cannot decide sample flags based on exception number. On the other hand, the exception return packet is followed by an instruction range packet; this range packet deliveries the start address after exception handling, we can check if it is a SVC instruction just before the start address. If there has one SVC instruction is found ahead the return address, this means it's an exception return for system call; otherwise it is an normal return for other exceptions. This patch is to set sample flags for exception return packet, firstly it simply set sample flags as PERF_IP_FLAG_INTERRUPT for all exception returns since at this point it doesn't know what's exactly the exception type. We will defer to decide if it's an exception return for system call when the next instruction range packet comes, it checks if there has one SVC instruction prior to the start address and if so we will change sample flags to PERF_IP_FLAG_SYSCALLRET for system call return. Signed-off-by: Leo Yan <leo.yan(a)linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Robert Walker <robert.walker(a)arm.com> Cc: Suzuki K Poulouse <suzuki.poulose(a)arm.com> Cc: coresight ml <coresight(a)lists.linaro.org> Cc: linux-arm-kernel(a)lists.infradead.org Link: http://lkml.kernel.org/r/20190129122842.32041-9-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/perf/util/cs-etm.c | 44 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index a714b31656ea..8b3f882d6e2f 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -1372,6 +1372,20 @@ static int cs_etm__set_sample_flags(struct cs_etm_queue *etmq) if (prev_packet->sample_type == CS_ETM_DISCONTINUITY) prev_packet->flags |= PERF_IP_FLAG_BRANCH | PERF_IP_FLAG_TRACE_BEGIN; + + /* + * If the previous packet is an exception return packet + * and the return address just follows SVC instuction, + * it needs to calibrate the previous packet sample flags + * as PERF_IP_FLAG_SYSCALLRET. + */ + if (prev_packet->flags == (PERF_IP_FLAG_BRANCH | + PERF_IP_FLAG_RETURN | + PERF_IP_FLAG_INTERRUPT) && + cs_etm__is_svc_instr(etmq, packet, packet->start_addr)) + prev_packet->flags = PERF_IP_FLAG_BRANCH | + PERF_IP_FLAG_RETURN | + PERF_IP_FLAG_SYSCALLRET; break; case CS_ETM_DISCONTINUITY: /* @@ -1422,6 +1436,36 @@ static int cs_etm__set_sample_flags(struct cs_etm_queue *etmq) prev_packet->flags = packet->flags; break; case CS_ETM_EXCEPTION_RET: + /* + * When the exception return packet is inserted, since + * exception return packet is not used standalone for + * generating samples and it's affiliation to the previous + * instruction range packet; so set previous range packet + * flags to tell perf it is an exception return branch. + * + * The exception return can be for either system call or + * other exception types; unfortunately the packet doesn't + * contain exception type related info so we cannot decide + * the exception type purely based on exception return packet. + * If we record the exception number from exception packet and + * reuse it for excpetion return packet, this is not reliable + * due the trace can be discontinuity or the interrupt can + * be nested, thus the recorded exception number cannot be + * used for exception return packet for these two cases. + * + * For exception return packet, we only need to distinguish the + * packet is for system call or for other types. Thus the + * decision can be deferred when receive the next packet which + * contains the return address, based on the return address we + * can read out the previous instruction and check if it's a + * system call instruction and then calibrate the sample flag + * as needed. + */ + if (prev_packet->sample_type == CS_ETM_RANGE) + prev_packet->flags = PERF_IP_FLAG_BRANCH | + PERF_IP_FLAG_RETURN | + PERF_IP_FLAG_INTERRUPT; + break; case CS_ETM_EMPTY: default: break; -- 2.20.1

6 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight