CoreSight February 2021

coresight@lists.linaro.org

29 participants
33 discussions

[PATCH 0/7] Split Coresight decode by aux records

by James Clark

Hi All, Since my previous RFC, I've fixed --per-thread mode and solved most of the open questions. I've also changed --dump-raw-trace to use the same code path so it's also working now. I think the only open questions are: * General approach * If aux records need to be saved, or if they can be pulled from elsewhere. I've also tested perf inject which is now working with troublesome files. Thanks James James Clark (7): perf cs-etm: Split up etm queue setup function perf cs-etm: Only search timestamp in current sample's queue. perf cs-etm: Save aux records in each etm queue perf cs-etm: don't process queues until cs_etm__flush_events perf cs-etm: split decode by aux records. perf cs-etm: Use existing decode code path for --dump-raw-trace perf cs-etm: Suppress printing when resetting decoder .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 10 +- tools/perf/util/cs-etm.c | 300 ++++++++++-------- 2 files changed, 168 insertions(+), 142 deletions(-) -- 2.28.0

3 years, 4 months

[PATCH v4 00/10] CoreSight configuration management; ETM strobing

by Mike Leach

This patchset introduces initial concepts in CoreSight system configuration management support. to allow more detailed and complex programming to be applied to CoreSight systems during trace capture. Configurations consist of 2 elements:- 1) Features - programming combinations for devices, applied to a class of device on the system (all ETMv4), or individual devices. 2) Configurations - a set of programmed features used when the named configuration is selected. Features and configurations are declared as a data table, a set of register, resource and parameter requirements. Features and configurations are loaded into the system by the virtual cs_syscfg device. This then matches features to any registered devices and loads the feature into them. Individual device classes that support feature and configuration register with cs_syscfg. Once loaded a configuration can be enabled for a specific trace run. Configurations are registered with the perf cs_etm event as entries in cs_etm/cs_config. These can be selected on the perf command line as follows:- perf record -e cs_etm/<config_name>/ ... This patch set has one pre-loaded configuration and feature. A named "strobing" feature is provided for ETMv4. A named "autofdo" configuration is provided. This configuration enables strobing on any ETM in used. Thus the command: perf record -e cs_etm/autofdo/ ... will trace the supplied application while enabling the "autofdo" configuation on each ETM as it is enabled by perf. This in turn will enable strobing for the ETM - with default parameters. Parameters can be adjusted using configfs. The sink used in the trace run will be automatically selected. A configuation can supply up to 15 of preset parameter values, which will subsitute in parameter values for any feature used in the configuration. Selection of preset values as follows perf record -e cs_etm/autofdo,preset=1/ ... (valid presets 1-N, where N is the number supplied in the configuration, not exceeding 15. preset=0 is the same as not selecting a preset.) Applies to coresight/next (5.11-rc2 base) Changes since v3: (Primarily based on comments from Matthieu) 1) Locking mechanisms simplified. 2) Removed the possibility to enable features independently from configurations.Only configurations can be enabled now. Simplifies programming logic. 3) Configuration now uses an activate->enable mechanism. This means that perf will activate a selected configuration at the start of a session (during setup_aux), and disable at the end of a session (around free_aux) The active configuration and associated features will be programmed into the CoreSight device instances when they are enabled. This locks the configuration into the system while in use. Parameters cannot be altered while this is in place. This mechanism will be extended in future for dynamic load / unload of configurations to prevent removal while in use. 4) Removed the custom bus / driver as un-necessary. A single device is registered to own perf fs elements and configfs. 5) Various other minor issues addressed. Changes since v2: 1) Added documentation file. 2) Altered cs_syscfg driver to no longer be coresight_device based, and moved to its own custom bus to remove it from the main coresight bus. (Mathieu) 3) Added configfs support to inspect and control loaded configurations and features. Allows listing of preset values (Yabin Cui) 4) Dropped sysfs support for adjusting feature parameters on the per device basis, in favour of a single point adjustment in configfs that is pushed to all device instances. 5) Altered how the config and preset command line options are handled in perf and the drivers. (Mathieu and Suzuki). 6) Fixes for various issues and technical points (Mathieu, Yabin) Changes since v1: 1) Moved preloaded configurations and features out of individual drivers. 2) Added cs_syscfg driver to manage configurations and features. Individual drivers register with cs_syscfg indicating support for config, and provide matching information that the system uses to load features into the drivers. This allows individual drivers to be updated on an as needed basis - and removes the need to consider devices that cannot benefit from configuration - static replicators, funnels, tpiu. 3) Added perf selection of configuarations. 4) Rebased onto the coresight module loading set. To follow in future revisions / sets:- a) load of additional config and features by loadable module. b) load of additional config and features by configfs c) enhanced resource management for ETMv4 and checking features have sufficient resources to be enabled. d) ECT and CTI support for configuration and features. Mike Leach (10): coresight: syscfg: Initial coresight system configuration coresight: syscfg: Add registration and feature loading for cs devices coresight: config: Add configuration and feature generic functions coresight: etm-perf: update to handle configuration selection coresight: syscfg: Add API to activate and enable configurations coresight: etm-perf: Update to activate selected configuration coresight: etm4x: Add complex configuration handlers to etmv4 coresight: config: Add preloaded configurations coresight: syscfg: Add initial configfs support coresight: docs: Add documentation for CoreSight config .../trace/coresight/coresight-config.rst | 244 ++++++ Documentation/trace/coresight/coresight.rst | 16 + drivers/hwtracing/coresight/Makefile | 7 +- .../hwtracing/coresight/coresight-cfg-afdo.c | 154 ++++ .../coresight/coresight-cfg-preload.c | 25 + .../coresight/coresight-cfg-preload.h | 11 + .../hwtracing/coresight/coresight-config.c | 246 ++++++ .../hwtracing/coresight/coresight-config.h | 282 +++++++ drivers/hwtracing/coresight/coresight-core.c | 18 +- .../hwtracing/coresight/coresight-etm-perf.c | 180 ++++- .../hwtracing/coresight/coresight-etm-perf.h | 12 +- .../hwtracing/coresight/coresight-etm4x-cfg.c | 184 +++++ .../hwtracing/coresight/coresight-etm4x-cfg.h | 29 + .../coresight/coresight-etm4x-core.c | 38 +- .../coresight/coresight-etm4x-sysfs.c | 3 + .../coresight/coresight-syscfg-configfs.c | 399 +++++++++ .../coresight/coresight-syscfg-configfs.h | 45 ++ .../hwtracing/coresight/coresight-syscfg.c | 761 ++++++++++++++++++ .../hwtracing/coresight/coresight-syscfg.h | 90 +++ include/linux/coresight.h | 7 + 20 files changed, 2721 insertions(+), 30 deletions(-) create mode 100644 Documentation/trace/coresight/coresight-config.rst create mode 100644 drivers/hwtracing/coresight/coresight-cfg-afdo.c create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.c create mode 100644 drivers/hwtracing/coresight/coresight-cfg-preload.h create mode 100644 drivers/hwtracing/coresight/coresight-config.c create mode 100644 drivers/hwtracing/coresight/coresight-config.h create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.c create mode 100644 drivers/hwtracing/coresight/coresight-etm4x-cfg.h create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.c create mode 100644 drivers/hwtracing/coresight/coresight-syscfg-configfs.h create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.c create mode 100644 drivers/hwtracing/coresight/coresight-syscfg.h -- 2.17.1

3 years, 5 months

Re: Secure World Coresight Tracing - HiKey 960

by Mike Leach

Hi Daniel, The CoreSight mailing list is the best place to ask these questions - I've added it to the to: section of this mail. On Fri, 19 Feb 2021 at 13:43, Daniel Su <daniel.sun.su(a)gmail.com> wrote: > > Sorry I made a mistake, I need to switch those bits but those aren't in the ETM mode sysFS parameter. > > > On Feb 19, 2021, at 14:21, Daniel Su <daniel.sun.su(a)gmail.com> wrote: > > > > Thanks, > > > > To just give a bit of background I am doing an internship to improve tracing and debugging for secure world applications in TrustZone. Originally the idea was to come up with a software solution but I thought using the hardware tracing features might be very powerful as the secure world trusted execution environments typically have less debugging and tracing functionalities built into the trusted operating system. > > > > I have been doing further reading and I believe I need to configure the ETM mode sysFS parameter. > > > > To switch these bits: > > > > /* secure state access levels - TRCACATRn */ > > #define ETM_EXLEVEL_S_APP BIT(8) > > #define ETM_EXLEVEL_S_OS BIT(9) > > #define ETM_EXLEVEL_S_HYP BIT(10) > > #define ETM_EXLEVEL_S_MON BIT(11) > > /* non-secure state access levels - TRCACATRn */ > > #define ETM_EXLEVEL_NS_APP BIT(12) > > #define ETM_EXLEVEL_NS_OS BIT(13) > > #define ETM_EXLEVEL_NS_HYP BIT(14) > > #define ETM_EXLEVEL_NS_NA BIT(15) > > ns_exlevel_vinst and s_exlevel_vinst control these bits in the TRCVICTLR. addr_exlevel_s_ns sets both S and NS bits in the TRCACATRn register currently addressed by addr_idx. In the kernel tree - Documentation/trace/coresight/coresight-etm4x-reference.rst - has lots of information on programming these sysfs files. I would advise setting mode first - which will set up some default values for TRCVITLR, then make any further adjustments you want. > > Right now I am able to capture the traces and read them out thanks to Leo Yan's command examples and presentation. > > > > I still need to figure out how to only trace branching instructions, and also how to best decode the traces. Right now even though I can read out /dev/ec036000.etf , I am unsure how to best go about interpreting the raw trace data. > > Hardware trace will trace everything - subject to certain filters - such as address filtering, exception filtering etc. It is not possible to trace only branch instructions. You will need to capture trace, decode then run an analysis on that decode to determine what branches have been taken. ETMv4 is program flow trace - so all branches are marked as taken or not taken. Consider the program:- =============== 0x1000 start: < some code > ... 0x1100 B func1 0x1200 func1: <some code> .... 0x1240 mov r0, &func2 B r0 0x2000 func2: <some code> ================ This will result in trace as follows:- TRACE_ON ADDR(0x1000) ATOM(E) > > I believe ptm2human and OpenCSD are two open source libraries that allow for decoding of the ETMv4 trace data. I understand there are paid solutions as well such as the DS-5 and Trace32 from Lauterbach to decode. > > > > Do you have any recommendations on other decoders or any tips in general as to how to decode the raw trace data into human readable format? > > > > Best, > > Daniel > > > >> On Feb 18, 2021, at 18:38, Suzuki K Poulose <suzuki.poulose(a)arm.com> wrote: > >> > >> Hi Daniel > >> > >> On 2/18/21 4:12 PM, Daniel Su wrote: > >>> Hello, > >>> First of all I want to say thanks for your work on the Coresight support as well as the presentation slides. Currently I am working with the Hikey960 which I see is supported and has been used as a reference platform in your slides. > >>> I believe it should be possible to setup self-hosted Coresight to trace only for branch instructions in the secure world. Currently I am investigating how to set this up on the Hikey960 without access to a hardware debugger. > >>> I am wondering if any of you have done this before, if there is additional documentation, or if there are any good support groups/chats/channels to ask questions. I have some experience with Coresight mainly from reading the ARM reference manuals but it is still a lot to parse. > >> > >> I haven't done anything similar. You should be able to imitate how the > >> CoreSight drivers program the components ( ETM, Funnels, Replicator and ETR). > >> > >> For ETM, you just need to make sure you don't filter out the Secure EL1/EL2/EL0. > >> You would need to read the manuals for the components or user the kernel driver > >> as the reference. > >> > >> Cheers > >> Suzuki > >> > >>> I believe in Linux I should be using `ns_exlevel_vinst` to filter out Non-Secure instructions. Also since the Hikey960 is multicore, I guess I would need to configure the top level Coresight in order to trace all cores? Would this be the ETR then? > >>> Best, > >>> Daniel > >> > > > -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK

3 years, 6 months

[PATCH v3 0/8] coresight: etm-perf: Fix pid tracing with VHE

by Leo Yan

This patch series is to support PID tracing with Virtualization Host Extensions (VHE). To be backward compatibility, and can both support PID tracing for the kernel is running at either EL1 or EL2, the two new PMU formats "contextid1" and "contextid2" are introduced, which works as switches to trace PID for EL1 kernel and EL2 kernel respectively. The existed PMU format "contextid" needs to be backward compatible for users, it's changed as an alias for "contextid1" on EL1 kernel and for "contextid2" on EL2 kernel. Therefore, even without setting "contextid" config, the perf tool can dynamically pick up the config for PID tracing, the user doesn't have to set the "contexid" config manually. This patch series can be cleanly applied on perf/core branch: commit cd07e536b020 ("Merge remote-tracking branch 'torvalds/master' into perf/core") ... and applied on the mainline kernel: commit 1e0d27fce010 ("Merge branch 'akpm' (patches from Andrew)") The patch series has been tested on Arm Juno-r2 board. Verified the kernel with EL1 and didn't find issue; after some hacking in kernel driver and tool to emulate the code paths for kernel on EL2, can see the code path is hit without failure. Changes from v2: * Split into two patches for clarification comment on perf options, one patch is for kernel change and the another one is for tools' change (Suzuki); * Simplified cs_etm__get_pid_fmt() to return ETM_OPT_CTXTID2 OR ETM_OPT_CTXTID, but not both (Suzuki); * Cached "pid_fmt" in cs_etm_decoder__set_tid() (Suzuki); * Refined documentation for more clear description for PMU format usages (Mike); * Added Suzuki's and Mike's Reviewed tags. Changes from v1: * Refactored PMU formats, added formats "contextid1"/"contextid2", and reworked format "contextid" (Suzuki/Mathieu); * Refined the comments for perf configs (Leo/Mike); * Added patch 07/07 for description PID tracing in docs; * Found the issue for bitmap for option, extracted patch 03/07 for the fixing. Changes from RFC: * Added comments to clarify cases requested (Leo); * Explain the change to generic flags for cs_etm_set_option() in the commit description; * Stored PID format in metadata and passed it to decoder (Leo); * Enhanced cs-etm for backward compatibility (Denis Nikitin). Leo Yan (4): coresight: etm-perf: Clarify comment on perf options tools headers UAPI: Update tools' copy of linux/coresight-pmu.h perf cs-etm: Add helper cs_etm__get_pid_fmt() Documentation: coresight: Add PID tracing description Suzuki K Poulose (4): coresight: etm-perf: Support PID tracing for kernel at EL2 perf cs-etm: Fix bitmap for option perf cs-etm: Support PID tracing in config perf cs-etm: Detect pid in VMID for kernel running at EL2 Documentation/trace/coresight/coresight.rst | 32 ++++++++ .../hwtracing/coresight/coresight-etm-perf.c | 32 +++++++- .../coresight/coresight-etm4x-core.c | 13 ++++ include/linux/coresight-pmu.h | 20 +++-- tools/include/linux/coresight-pmu.h | 20 +++-- tools/perf/arch/arm/util/cs-etm.c | 73 +++++++++++++++---- .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 38 +++++++++- tools/perf/util/cs-etm.c | 42 +++++++++++ tools/perf/util/cs-etm.h | 1 + 9 files changed, 239 insertions(+), 32 deletions(-) -- 2.25.1

3 years, 6 months

Proposal request for coresight [Urgent] !!

by kimyeng.kossanak

3 years, 6 months

[PATCH] coresight: etm4x: work around clang-12+ build failure

by Arnd Bergmann

From: Arnd Bergmann <arnd(a)arndb.de> clang-12 fails to build the etm4x driver with -fsanitize=array-bounds: <instantiation>:1:7: error: expected constant expression in '.inst' directive .inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8)) ^ drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in macro instantiation etm4x_relaxed_read32(csa, TRCCNTVRn(i)); ^ drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from macro 'etm4x_relaxed_read32' read_etm4x_sysreg_offset((offset), false))) ^ drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded from macro 'read_etm4x_sysreg_offset' __val = read_etm4x_sysreg_const_offset((offset)); \ ^ drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from macro 'read_etm4x_sysreg_const_offset' READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset)) ^ drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from macro 'READ_ETM4x_REG' read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg))) ^ arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro 'read_sysreg_s' asm volatile(__mrs_s("%0", r) : "=r" (__val)); \ ^ arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s' " mrs_s " v ", " __stringify(r) "\n" \ ^ It appears that the __builin_constant_p() check in read_etm4x_sysreg_offset() falsely returns 'true' here because clang decides finds that an out-of-bounds access to config->cntr_val[] cannot happen, and then it unrolls the loop with constant register numbers. Then when actually emitting the output, it fails to figure out the value again. While this is incorrect behavior in clang, it is easy to work around by avoiding the out-of-bounds array access. Do this by limiting the loop counter to the actual dimension of the array. Link: https://github.com/ClangBuiltLinux/linux/issues/1310 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 15016f757828..4cccf874a602 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -691,13 +691,13 @@ static void etm4_disable_hw(void *info) "timeout while waiting for PM stable Trace Status\n"); /* read the status of the single shot comparators */ - for (i = 0; i < drvdata->nr_ss_cmp; i++) { + for (i = 0; i < min_t(u32, drvdata->nr_ss_cmp, ETM_MAX_SS_CMP); i++) { config->ss_status[i] = etm4x_relaxed_read32(csa, TRCSSCSRn(i)); } /* read back the current counter values */ - for (i = 0; i < drvdata->nr_cntr; i++) { + for (i = 0; i < min_t(u32, drvdata->nr_cntr, ETMv4_MAX_CNTR); i++) { config->cntr_val[i] = etm4x_relaxed_read32(csa, TRCCNTVRn(i)); } -- 2.29.2

3 years, 6 months

[PATCH v4 00/19] arm64: coresight: Add support for ETE and TRBE

by Suzuki K Poulose

This series enables future IP trace features Embedded Trace Extension (ETE) and Trace Buffer Extension (TRBE). This series applies on linux-next/master (from tag next-20210222), and is also available here [0]. Patches 1 & 2: UABI updates for perf AUX flag format. We reserve a byte for advertising the format of the buffer when the PMU could support different formats. The CoreSight PMUs could use Frame formatted data and Raw format of the trace source. Patches 3 - 5: Fixes for arm64 KVM hypervisor to align with the architecture. Patches 6 - 7: Adds the arrchitecture defintions for trace and TRBE Patch 8 : Adds the necessary changes for enabling TRBE access to host from the early initialisation (VHE and nVHE). Also support for nVHE hyp to save/restore the TRBE context of the host during a trip to the guest. Patches 9 - 19: CoreSight driver specific changes and DT bindings for ETE and TRBE support ETE is the PE (CPU) trace unit for CPUs, implementing future architecture extensions. ETE overlaps with the ETMv4 architecture, with additions to support the newer architecture features and some restrictions on the supported features w.r.t ETMv4. The ETE support is added by extending the ETMv4 driver to recognise the ETE and handle the features as exposed by the TRCIDRx registers. ETE only supports system instructions access from the host CPU. The ETE could be integrated with a TRBE (see below), or with the legacy CoreSight trace bus (e.g, ETRs). Thus the ETE follows same firmware description as the ETMs and requires a node per instance. Trace Buffer Extensions (TRBE) implements a per CPU trace buffer, which is accessible via the system registers and can be combined with the ETE to provide a 1x1 configuration of source & sink. TRBE is being represented here as a CoreSight sink. Primary reason is that the ETE source could work with other traditional CoreSight sink devices. As TRBE captures the trace data which is produced by ETE, it cannot work alone. TRBE representation here have some distinct deviations from a traditional CoreSight sink device. Coresight path between ETE and TRBE are not built during boot looking at respective DT or ACPI entries. Unlike traditional sinks, TRBE can generate interrupts to signal including many other things, buffer got filled. The interrupt is a PPI and should be communicated from the platform. DT or ACPI entry representing TRBE should have the PPI number for a given platform. During perf session, the TRBE IRQ handler should capture trace for perf auxiliary buffer before restarting it back. System registers being used here to configure ETE and TRBE could be referred in the link below. https://developer.arm.com/docs/ddi0601/g/aarch64-system-registers. [0] https://gitlab.arm.com/linux-arm/linux-skp/-/tree/coresight/ete/v4/next Changes in V4: - ETE and TRBE changes have been captured in the respective patches - Better support for nVHE - Re-ordered and splitted the patches to keep the changes separate for the generic/arm64 tree from CoreSight driver specific changes. - Fixes for KVM handling of Trace/SPE Changes in V3: https://lore.kernel.org/linux-arm-kernel/1611737738-1493-1-git-send-email-a… - Rebased on coresight/next - Changed DT bindings for ETE - Included additional patches for arm64 nvhe, perf aux buffer flags etc - TRBE changes have been captured in the respective patches Changes in V2: https://lore.kernel.org/linux-arm-kernel/1610511498-4058-1-git-send-email-a… - Converted both ETE and TRBE DT bindings into Yaml - TRBE changes have been captured in the respective patches Changes in V1: https://lore.kernel.org/linux-arm-kernel/1608717823-18387-1-git-send-email-… - There are not much ETE changes from Suzuki apart from splitting of the ETE DTS patch - TRBE changes have been captured in the respective patches Changes in RFC: https://lore.kernel.org/linux-arm-kernel/1605012309-24812-1-git-send-email-… Cc: Will Deacon <will(a)kernel.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Peter Zilstra <peterz(a)infradead.org> Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Linu Cherian <lcherian(a)marvell.com> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Anshuman Khandual (3): arm64: Add TRBE definitions coresight: core: Add support for dedicated percpu sinks coresight: sink: Add TRBE driver Suzuki K Poulose (16): perf: aux: Add flags for the buffer format perf: aux: Add CoreSight PMU buffer formats kvm: arm64: Hide system instruction access to Trace registers kvm: arm64: nvhe: Save the SPE context early kvm: arm64: Disable guest access to trace filter controls arm64: Add support for trace synchronization barrier arm64: kvm: Enable access to TRBE support for host coresight: etm4x: Move ETM to prohibited region for disable coresight: etm-perf: Allow an event to use different sinks coresight: Do not scan for graph if none is present coresight: etm4x: Add support for PE OS lock coresight: ete: Add support for ETE sysreg access coresight: ete: Add support for ETE tracing dts: bindings: Document device tree bindings for ETE coresight: etm-perf: Handle stale output handles dts: bindings: Document device tree bindings for Arm TRBE .../testing/sysfs-bus-coresight-devices-trbe | 14 + .../devicetree/bindings/arm/ete.yaml | 71 + .../devicetree/bindings/arm/trbe.yaml | 49 + .../trace/coresight/coresight-trbe.rst | 38 + arch/arm64/include/asm/barrier.h | 1 + arch/arm64/include/asm/el2_setup.h | 13 + arch/arm64/include/asm/kvm_arm.h | 3 + arch/arm64/include/asm/kvm_host.h | 2 + arch/arm64/include/asm/kvm_hyp.h | 5 + arch/arm64/include/asm/sysreg.h | 50 + arch/arm64/kernel/cpufeature.c | 1 - arch/arm64/kernel/hyp-stub.S | 3 +- arch/arm64/kvm/debug.c | 6 +- arch/arm64/kvm/hyp/nvhe/debug-sr.c | 54 +- arch/arm64/kvm/hyp/nvhe/switch.c | 13 +- drivers/hwtracing/coresight/Kconfig | 24 +- drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-core.c | 29 +- .../hwtracing/coresight/coresight-etm-perf.c | 119 +- .../coresight/coresight-etm4x-core.c | 161 ++- .../coresight/coresight-etm4x-sysfs.c | 19 +- drivers/hwtracing/coresight/coresight-etm4x.h | 83 +- .../hwtracing/coresight/coresight-platform.c | 6 + drivers/hwtracing/coresight/coresight-priv.h | 3 + drivers/hwtracing/coresight/coresight-trbe.c | 1149 +++++++++++++++++ drivers/hwtracing/coresight/coresight-trbe.h | 153 +++ include/linux/coresight.h | 12 + include/uapi/linux/perf_event.h | 13 +- 28 files changed, 2028 insertions(+), 67 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-trbe create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml create mode 100644 Documentation/trace/coresight/coresight-trbe.rst create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h -- 2.24.1

3 years, 6 months

[PATCH 0/4] Add support to exclude kernel mode hardware assisted instruction tracing

by Sai Prakash Ranjan

Hardware assisted tracing families such as ARM Coresight, Intel PT provides rich tracing capabilities including instruction level tracing and accurate timestamps which are very useful for profiling and also pose a significant security risk. One such example of security risk is when kernel mode tracing is not excluded and these hardware assisted tracing can be used to analyze cryptographic code execution. In this case, even the root user must not be able to infer anything. To explain it more clearly, here is the quote from a member of the security team (credits: Mattias Nissler), "Consider a system where disk contents are encrypted and the encryption key is set up by the user when mounting the file system. From that point on the encryption key resides in the kernel. It seems reasonable to expect that the disk encryption key be protected from exfiltration even if the system later suffers a root compromise (or even against insiders that have root access), at least as long as the attacker doesn't manage to compromise the kernel." Here the idea is to protect such important information from all users including root users since root privileges does not have to mean full control over the kernel [1] and root compromise does not have to be the end of the world. Currently we can exclude kernel mode tracing via perf_event_paranoid sysctl but it has following limitations, * It is applicable to all PMUs and not just the ones supporting instruction tracing. * No option to restrict kernel mode instruction tracing by the root user. * Not possible to restrict kernel mode instruction tracing when the hardware assisted tracing IPs like ARM Coresight ETMs use an additional interface via sysfs for tracing in addition to perf interface. So introduce a new config CONFIG_EXCLUDE_KERNEL_HW_ITRACE to exclude kernel mode instruction tracing which will be generic and applicable to all hardware tracing families and which can also be used with other interfaces like sysfs in case of ETMs. Patch 1 adds this new config and the support in perf core to exclude kernel mode tracing for PMUs which support instruction mode tracing. Patch 2 adds the perf evsel warning message when the perf tool users attempt to perform a kernel mode instruction trace with the config enabled to exclude the kernel mode tracing. Patch 3 and Patch 4 adds the support for excluding kernel mode for ARM Coresight ETM{4,3}XX sysfs mode using the newly introduced generic config. [1] https://lwn.net/Articles/796866/ Sai Prakash Ranjan (4): perf/core: Add support to exclude kernel mode instruction tracing perf evsel: Print warning for excluding kernel mode instruction tracing coresight: etm4x: Add support to exclude kernel mode tracing coresight: etm3x: Add support to exclude kernel mode tracing drivers/hwtracing/coresight/coresight-etm3x-core.c | 11 +++++++++++ .../hwtracing/coresight/coresight-etm3x-sysfs.c | 3 ++- drivers/hwtracing/coresight/coresight-etm4x-core.c | 14 +++++++++++++- .../hwtracing/coresight/coresight-etm4x-sysfs.c | 3 ++- init/Kconfig | 12 ++++++++++++ kernel/events/core.c | 6 ++++++ tools/perf/util/evsel.c | 3 ++- 7 files changed, 48 insertions(+), 4 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

3 years, 6 months

[PATCH V2 00/11] arm64: coresight: Enable ETE and TRBE

by Anshuman Khandual

This series enables future IP trace features Embedded Trace Extension (ETE) and Trace Buffer Extension (TRBE). This series depends on the ETM system register instruction support series [0] which is available here [1]. This series which applies on [1] is avaialble here [2] for quick access. ETE is the PE (CPU) trace unit for CPUs, implementing future architecture extensions. ETE overlaps with the ETMv4 architecture, with additions to support the newer architecture features and some restrictions on the supported features w.r.t ETMv4. The ETE support is added by extending the ETMv4 driver to recognise the ETE and handle the features as exposed by the TRCIDRx registers. ETE only supports system instructions access from the host CPU. The ETE could be integrated with a TRBE (see below), or with the legacy CoreSight trace bus (e.g, ETRs). Thus the ETE follows same firmware description as the ETMs and requires a node per instance. Trace Buffer Extensions (TRBE) implements a per CPU trace buffer, which is accessible via the system registers and can be combined with the ETE to provide a 1x1 configuration of source & sink. TRBE is being represented here as a CoreSight sink. Primary reason is that the ETE source could work with other traditional CoreSight sink devices. As TRBE captures the trace data which is produced by ETE, it cannot work alone. TRBE representation here have some distinct deviations from a traditional CoreSight sink device. Coresight path between ETE and TRBE are not built during boot looking at respective DT or ACPI entries. Unlike traditional sinks, TRBE can generate interrupts to signal including many other things, buffer got filled. The interrupt is a PPI and should be communicated from the platform. DT or ACPI entry representing TRBE should have the PPI number for a given platform. During perf session, the TRBE IRQ handler should capture trace for perf auxiliary buffer before restarting it back. System registers being used here to configure ETE and TRBE could be referred in the link below. https://developer.arm.com/docs/ddi0601/g/aarch64-system-registers. Question: - Should we implement sysfs based trace sessions for TRBE ? [0] https://lore.kernel.org/linux-arm-kernel/20210110224850.1880240-1-suzuki.po… [1] https://gitlab.arm.com/linux-arm/linux-skp/-/tree/coresight/etm/sysreg-v7 [2] https://gitlab.arm.com/linux-arm/linux-anshuman/-/tree/coresight/ete_trbe_v2 Changes in V2: - Converted both ETE and TRBE DT bindings into Yaml - TRBE changes have been captured in the respective patches Changes in V1: https://lore.kernel.org/linux-arm-kernel/1608717823-18387-1-git-send-email-… - There are not much ETE changes from Suzuki apart from splitting of the ETE DTS patch - TRBE changes have been captured in the respective patches Changes in RFC: https://lore.kernel.org/linux-arm-kernel/1605012309-24812-1-git-send-email-… Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Linu Cherian <lcherian(a)marvell.com> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Anshuman Khandual (4): arm64: Add TRBE definitions coresight: core: Add support for dedicated percpu sinks coresight: etm-perf: Truncate the perf record if handle has no space coresight: sink: Add TRBE driver Suzuki K Poulose (7): coresight: etm-perf: Allow an event to use different sinks coresight: Do not scan for graph if none is present coresight: etm4x: Add support for PE OS lock coresight: ete: Add support for ETE sysreg access coresight: ete: Add support for ETE tracing dts: bindings: Document device tree bindings for ETE dts: bindings: Document device tree bindings for Arm TRBE Documentation/devicetree/bindings/arm/ete.yaml | 71 ++ Documentation/devicetree/bindings/arm/trbe.yaml | 46 + Documentation/trace/coresight/coresight-trbe.rst | 39 + arch/arm64/include/asm/sysreg.h | 51 ++ drivers/hwtracing/coresight/Kconfig | 21 +- drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-core.c | 14 + drivers/hwtracing/coresight/coresight-etm-perf.c | 51 +- drivers/hwtracing/coresight/coresight-etm4x-core.c | 138 ++- .../hwtracing/coresight/coresight-etm4x-sysfs.c | 19 +- drivers/hwtracing/coresight/coresight-etm4x.h | 81 +- drivers/hwtracing/coresight/coresight-platform.c | 6 + drivers/hwtracing/coresight/coresight-trbe.c | 966 +++++++++++++++++++++ drivers/hwtracing/coresight/coresight-trbe.h | 216 +++++ include/linux/coresight.h | 12 + 15 files changed, 1683 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml create mode 100644 Documentation/trace/coresight/coresight-trbe.rst create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h -- 2.7.4

3 years, 6 months

[PATCH V3 00/14] arm64: coresight: Enable ETE and TRBE

by Anshuman Khandual

This series enables future IP trace features Embedded Trace Extension (ETE) and Trace Buffer Extension (TRBE). This series depends on the ETM system register instruction support series [0] which is available here [1]. This series which applies on [1] is avaialble here [2] for quick access. ETE is the PE (CPU) trace unit for CPUs, implementing future architecture extensions. ETE overlaps with the ETMv4 architecture, with additions to support the newer architecture features and some restrictions on the supported features w.r.t ETMv4. The ETE support is added by extending the ETMv4 driver to recognise the ETE and handle the features as exposed by the TRCIDRx registers. ETE only supports system instructions access from the host CPU. The ETE could be integrated with a TRBE (see below), or with the legacy CoreSight trace bus (e.g, ETRs). Thus the ETE follows same firmware description as the ETMs and requires a node per instance. Trace Buffer Extensions (TRBE) implements a per CPU trace buffer, which is accessible via the system registers and can be combined with the ETE to provide a 1x1 configuration of source & sink. TRBE is being represented here as a CoreSight sink. Primary reason is that the ETE source could work with other traditional CoreSight sink devices. As TRBE captures the trace data which is produced by ETE, it cannot work alone. TRBE representation here have some distinct deviations from a traditional CoreSight sink device. Coresight path between ETE and TRBE are not built during boot looking at respective DT or ACPI entries. Unlike traditional sinks, TRBE can generate interrupts to signal including many other things, buffer got filled. The interrupt is a PPI and should be communicated from the platform. DT or ACPI entry representing TRBE should have the PPI number for a given platform. During perf session, the TRBE IRQ handler should capture trace for perf auxiliary buffer before restarting it back. System registers being used here to configure ETE and TRBE could be referred in the link below. https://developer.arm.com/docs/ddi0601/g/aarch64-system-registers. Question: - Should we implement sysfs based trace sessions for TRBE ? [0] https://lore.kernel.org/linux-arm-kernel/20210110224850.1880240-1-suzuki.po… [1] https://gitlab.arm.com/linux-arm/linux-skp/-/tree/coresight/etm/sysreg-v7 [2] https://gitlab.arm.com/linux-arm/linux-anshuman/-/tree/coresight/ete_trbe_v3 Changes in V3: - Rebased on coresight/next - Changed DT bindings for ETE - Included additional patches for arm64 nvhe, perf aux buffer flags etc - TRBE changes have been captured in the respective patches Changes in V2: https://lore.kernel.org/linux-arm-kernel/1610511498-4058-1-git-send-email-a… - Converted both ETE and TRBE DT bindings into Yaml - TRBE changes have been captured in the respective patches Changes in V1: https://lore.kernel.org/linux-arm-kernel/1608717823-18387-1-git-send-email-… - There are not much ETE changes from Suzuki apart from splitting of the ETE DTS patch - TRBE changes have been captured in the respective patches Changes in RFC: https://lore.kernel.org/linux-arm-kernel/1605012309-24812-1-git-send-email-… Cc: Mathieu Poirier <mathieu.poirier(a)linaro.org> Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com> Cc: Mike Leach <mike.leach(a)linaro.org> Cc: Linu Cherian <lcherian(a)marvell.com> Cc: coresight(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-kernel(a)vger.kernel.org Anshuman Khandual (3): coresight: core: Add support for dedicated percpu sinks arm64: Add TRBE definitions coresight: sink: Add TRBE driver Suzuki K Poulose (11): coresight: etm-perf: Allow an event to use different sinks coresight: Do not scan for graph if none is present coresight: etm4x: Add support for PE OS lock coresight: ete: Add support for ETE sysreg access coresight: ete: Add support for ETE tracing dts: bindings: Document device tree bindings for ETE coresight: etm-perf: Handle stale output handles arm64: nvhe: Allow TRBE access at EL1 dts: bindings: Document device tree bindings for Arm TRBE perf: aux: Add flags for the buffer format coresight: etm-perf: Add support for trace buffer format Documentation/devicetree/bindings/arm/ete.yaml | 74 ++ Documentation/devicetree/bindings/arm/trbe.yaml | 49 + Documentation/trace/coresight/coresight-trbe.rst | 39 + arch/arm64/include/asm/el2_setup.h | 19 + arch/arm64/include/asm/kvm_arm.h | 2 + arch/arm64/include/asm/sysreg.h | 51 + drivers/hwtracing/coresight/Kconfig | 21 +- drivers/hwtracing/coresight/Makefile | 1 + drivers/hwtracing/coresight/coresight-core.c | 16 +- drivers/hwtracing/coresight/coresight-etm-perf.c | 93 +- drivers/hwtracing/coresight/coresight-etm4x-core.c | 138 ++- .../hwtracing/coresight/coresight-etm4x-sysfs.c | 19 +- drivers/hwtracing/coresight/coresight-etm4x.h | 81 +- drivers/hwtracing/coresight/coresight-platform.c | 6 + drivers/hwtracing/coresight/coresight-trbe.c | 1025 ++++++++++++++++++++ drivers/hwtracing/coresight/coresight-trbe.h | 160 +++ include/linux/coresight.h | 12 + include/uapi/linux/perf_event.h | 13 +- 18 files changed, 1759 insertions(+), 60 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml create mode 100644 Documentation/devicetree/bindings/arm/trbe.yaml create mode 100644 Documentation/trace/coresight/coresight-trbe.rst create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h -- 2.7.4

3 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight February 2021