CoreSight

coresight@lists.linaro.org

8 participants
2394 discussions

Re: [PATCH v1 0/3] Add support to configure Coresight Dummy subunit

by Suzuki K Poulose

On 16/03/2023 03:20, Hao Zhang wrote: > Introduction of Coresight Dummy subunit > The Coresight Dummy subunit is for Coresight Dummy component, there are some > specific Coresight devices that HLOS don't have permission to access. Such as What is HLOS ? > some TPDMs, they would be configured in NON-HLOS side, but it's necessary to What is NON-HLOS ? > build Coresight path for it to debug. So there need driver to register dummy > devices as Coresight devices. Build a path for who to debug ? If this is used by some privileged software, shouldn't that do all of the work ? Suzuki > > Commit link: > https://git.codelinaro.org/clo/linux-kernel/coresight/-/tree/coresight-dummy > > Hao Zhang (3): > Coresight: Add coresight dummy driver > dt-bindings: arm: Add Coresight Dummy Trace YAML schema > Documentation: trace: Add documentation for Coresight Dummy Trace > > .../bindings/arm/qcom,coresight-dummy.yaml | 129 +++++++++++++ > .../trace/coresight/coresight-dummy.rst | 58 ++++++ > drivers/hwtracing/coresight/Kconfig | 11 ++ > drivers/hwtracing/coresight/Makefile | 1 + > drivers/hwtracing/coresight/coresight-dummy.c | 176 ++++++++++++++++++ > 5 files changed, 375 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-dummy.yaml > create mode 100644 Documentation/trace/coresight/coresight-dummy.rst > create mode 100644 drivers/hwtracing/coresight/coresight-dummy.c >

2 years, 3 months

[PATCH 1/2] perf cs-etm: Reduce verbosity of ts_source warning

by James Clark

This is printed as a warning but it is normal behavior that users shouldn't be expected to do anything about. Reduce the warning level to debug3 so it's only seen in verbose mode to avoid confusion. Signed-off-by: James Clark <james.clark(a)arm.com> --- tools/perf/arch/arm/util/cs-etm.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c index 7f71c8a237ff..59b50dd70330 100644 --- a/tools/perf/arch/arm/util/cs-etm.c +++ b/tools/perf/arch/arm/util/cs-etm.c @@ -694,8 +694,8 @@ static void cs_etm_save_etmv4_header(__u64 data[], struct auxtrace_record *itr, data[CS_ETMV4_TS_SOURCE] = (__u64) cs_etm_get_ro_signed(cs_etm_pmu, cpu, metadata_etmv4_ro[CS_ETMV4_TS_SOURCE]); else { - pr_warning("[%03d] pmu file 'ts_source' not found. Fallback to safe value (-1)\n", - cpu); + pr_debug3("[%03d] pmu file 'ts_source' not found. Fallback to safe value (-1)\n", + cpu); data[CS_ETMV4_TS_SOURCE] = (__u64) -1; } } @@ -729,8 +729,8 @@ static void cs_etm_save_ete_header(__u64 data[], struct auxtrace_record *itr, in data[CS_ETE_TS_SOURCE] = (__u64) cs_etm_get_ro_signed(cs_etm_pmu, cpu, metadata_ete_ro[CS_ETE_TS_SOURCE]); else { - pr_warning("[%03d] pmu file 'ts_source' not found. Fallback to safe value (-1)\n", - cpu); + pr_debug3("[%03d] pmu file 'ts_source' not found. Fallback to safe value (-1)\n", + cpu); data[CS_ETE_TS_SOURCE] = (__u64) -1; } } -- 2.34.1

2 years, 4 months

Re: [BUG] perf: No samples found when using kcore + coresight

by Leo Yan

On Thu, Mar 09, 2023 at 10:06:41AM -0800, Yang Shi wrote: [...] > > I reviewed your shared dump, the bad and good perf data both contain the > > dummy event with 'text_poke = 1'. Could you confirm the shared dump in > > your previous email is correct or not? > > Oops, sorry. I pasted the wrong log. The good one looks like > (generated by v5.19): > > # captured on : Wed Mar 8 18:02:58 2023 > # header version : 1 > # data offset : 408 > # data size : 22640 > # feat offset : 23048 > # hostname : fedora > # os release : 6.2.0-coresight+ > # perf version : 5.19.g3d7cb6b04c3f > # arch : aarch64 > # nrcpus online : 128 > # nrcpus avail : 128 > # cpuid : 0x00000000c00fac30 > # total memory : 2108862504 kB > # cmdline : /home/yshi/linux/tools/perf/perf record -e > cs_etm/@tmc_etf63/k --kcore --per-thread -- taskset --cpu-list 1 uname > # event : name = cs_etm/@tmc_etf63/k, , id = { 3832 }, type = 9, size > = 128, { sample_period, sample_freq } = 1, sample_type = > IP|TID|IDENTIFIER, read_format = ID, d > isabled = 1, exclude_user = 1, exclude_hv = 1, enable_on_exec = 1, > sample_id_all = 1, { bp_len, config2 } = 0x12792918 > # event : name = dummy:u, , id = { 3833 }, type = 1, size = 128, > 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, exclude_guest = 1, > mmap2 = 1, comm_exec = 1, > context_switch = 1, ksymbol = 1, bpf_event = 1 > # CPU_TOPOLOGY info available, use -I to display > # NUMA_TOPOLOGY info available, use -I to display > # pmu mappings: armv8_pmuv3_0 = 8, software = 1, arm_cmn_0 = 10, > uprobe = 7, cs_etm = 9, breakpoint = 5, tracepoint = 2, arm_cmn_1 = > 11, kprobe = 6 > # contains AUX area data (e.g. instruction trace) > # CACHE info available, use -I to display > # time of first sample : 18446744073.709551 > # time of last sample : 18446744073.709551 > # sample duration : 0.000 ms > # MEM_TOPOLOGY info available, use -I to display > # missing features: TRACING_DATA CPUDESC BRANCH_STACK GROUP_DESC STAT > CLOCKID DIR_FORMAT COMPRESSED CPU_PMU_CAPS CLOCK_DATA HYBRID_TOPOLOGY > HYBRID_CPU_PMU_CAPS Thanks for confirmation. Just a quick summary, here we have two issues: - With command: perf record -e cs_etm/@tmc_etf63/k --kcore --per-thread \ -- taskset --cpu-list 1 uname", perf doesn't enable "text poke" attribution. - With command: perf record -e cs_etm/@tmc_etf63/k --kcore --per-thread \ -- taskset --cpu-list 1 true (in your previous email), or ... perf record --kcore -e cs_etm/@tmc_etf63/k --per-thread \ -- taskset --cpu-list 1 uname (in your shared perf data file), perf enables "text poke" attribution, in this case, perf fails to decode Arm CoreSight trace data. [...] > > Do you mind to share the bad perf.data file with James and me? > > Please check the attachment out. Thanks for looking into this problem. Thank you for sharing the data. We will look into it. Leo

2 years, 4 months

Re: [PATCH 3/3] coresight etm4x: Add 32-bit read/write option to split 64-bit words

by Leo Yan

On Thu, Mar 09, 2023 at 12:46:55PM -0800, Steve Clevenger wrote: [...] > > #include <linux/io-64-nonatomic-hi-lo.h> > > > > static inline u64 etm4x_relaxed_read64(struct csdev_access *csa, unsigned int offset) > > { > > if (csa->io_mem) { > > if (csa->no_quad_mmio) > > return hi_lo_readq_relaxed(csa->base + offset); > > else > > return readq_relaxed(csa->base + offset); > > } else { > > return read_etm4x_sysreg_offset(offset, true); > > } > > } > > > > I'm not saying to play magic on {writeq|readq}_relaxed(), would it be > > fine to directly call hi_lo_readq_relaxed()? > > I can do this, and it would work fine. Without compile protection, one > concern is the silent inclusion of io-64-nonatomic-hi-lo.h definitions > for readq_relaxed/writeq_relaxed if the include hierarchy gets changed. > The only (minor) risk I see is to performance. Yeah, we could include io.h ahead io-64-nonatomic-hi-lo.h: #include <linux/io.h> #include <linux/io-64-nonatomic-lo-hi.h> Thus we can get the definitions for {readq|writeq}_relaxed() from "io.h". > Second, it seems to me the hi_lo and lo_hi macros were intended to deal > with endianness. IMO, the implementation I offered is agnostic without a > hint to endianness or atomicity. Seems to me, kernel functions with explict endianness naming is not bad thing :) > The CoreSight maintainer audience is > limited and already aware of these issues, so I'll make the change for you. Thanks! Suzuki, Mike, I think it's good to get your opinion before Steve can proceed for updating patch. Leo

2 years, 4 months

Re: [PATCH 3/3] coresight etm4x: Add 32-bit read/write option to split 64-bit words

by Leo Yan

Hi Steve, On Wed, Mar 08, 2023 at 11:08:34AM -0800, Steve Clevenger wrote: [...] > I'm familiar with this interface. The reason I chose not to use it is > this solution is configured at compile time. The writeq_relaxed (used by > etm4x_relaxed_write64) and readq_relaxed (used by etm4x_relaxed_read64) > otherwise default to 64-bit access. I was uncertain how a compile time > change would go over with the maintainers. Correct me, but compile time > configurations in the kernel seem to be related to ARM64 erratum, versus > manufacturer specific? > > My take (based on limited knowledge) of the changes necessary to support > a compile time decision seemed to exceed the changes compared with the > implementation I submitted upstream. If this becomes a sticking point, > let me know. I am suggesting something like below: #include <linux/io-64-nonatomic-hi-lo.h> static inline u64 etm4x_relaxed_read64(struct csdev_access *csa, unsigned int offset) { if (csa->io_mem) { if (csa->no_quad_mmio) return hi_lo_readq_relaxed(csa->base + offset); else return readq_relaxed(csa->base + offset); } else { return read_etm4x_sysreg_offset(offset, true); } } I'm not saying to play magic on {writeq|readq}_relaxed(), would it be fine to directly call hi_lo_readq_relaxed()? Thanks, Leo

2 years, 4 months

Re: [BUG] perf: No samples found when using kcore + coresight

by Leo Yan

Hi Yang, On Wed, Mar 08, 2023 at 11:56:38AM -0800, Yang Shi wrote: [...] > > Dumping raw events could show the events from the bad data file. But > > it has zero samples after event collapse. > > > > The only difference is --kcore inserted a new text_poke dummy event. > > It seems coresight also inserted a dummy event with my command but > > your command didn't. So it seems like the two dummy events confused > > event collapse. > > > > The text_poke dummy event is added by commit > > f42c0ce573df79d1b8bd169008c994dcdd43585a ("perf record: Always get > > text_poke events with --kcore option"). If I reverted this commit, > > then it works. But I'm not sure whether this is the right fix or real > > root cause or not. Or coresight shouldn't insert its own dummy event? > > It seems like coresight needs to insert the dummy event if > full_auxtrace is on IIUC. So it sounds like event collapse can't > handle such a case? I am struggling to understand the meaning "event collapse" :) I reviewed your shared dump, the bad and good perf data both contain the dummy event with 'text_poke = 1'. Could you confirm the shared dump in your previous email is correct or not? > I also tried v5.19 (before "perf record: Always > get text_poke events with --kcore option", which was merged in v6.0), > it works. So it seems like a regression. Yeah, we need to fix it. I am not sure the Linux kernel for Arm64 supports text poke or not (kernel needs some specific handling when alter instructions), the kernel change is the prerequisites. On the other hand, in the current code cs-etm misses to handle the event PERF_RECORD_TEXT_POKE in the function cs_etm__process_event(). This might be the cause for the failure. Do you mind to share the bad perf.data file with James and me? Thanks, Leo

2 years, 4 months

[PATCH 0/8] coresight: Fix CTI module refcount leak by making it a helper device

by James Clark

Currently there is a refcount leak in CTI when using system wide mode or tracing multithreaded applications. See the last commit for a reproducer. This prevents the module from being unloaded. Historically there have been a few issues and fixes attempted around here which have resulted in some extra logic and a member to keep track of CTI being enabled 'struct coresight_device->ect_enabled'. The fix in commit 665c157e0204 ("coresight: cti: Fix hang in cti_disable_hw()") was also related to CTI having its own enable/disable path which came later than other devices. If we make CTI a helper device and enable helper devices adjacent to the path we get very similar enable/disable behavior to now, but with more reuse of the existing reference counting logic in the coresight core code. This also affects CATU which can have a little bit of its hard coded enable/disable code removed. Enabling CATU on the generic path does require that input connections are tracked so that it can get its associated ETR buffer. Applies to coresight/next (669c4614236a7) but also requires the realloc_array patch here [1]. Also available in full here [2]. [1]: https://lore.kernel.org/linux-arm-kernel/20230306152723.3090195-1-james.cla… [2]: https://gitlab.arm.com/linux-arm/linux-jc/-/tree/james-cs-cti-module-refcou… James Clark (8): coresight: Use enum type for cs_mode wherever possible coresight: Change name of pdata->conns coresight: Rename nr_outports to nr_outconns coresight: Dynamically add connections coresight: Store in-connections as well as out-connections coresight: Refactor out buffer allocation function for ETR coresight: Enable and disable helper devices adjacent to the path coresight: Fix CTI module refcount leak by making it a helper device drivers/hwtracing/coresight/coresight-catu.c | 34 ++- drivers/hwtracing/coresight/coresight-core.c | 258 +++++++++++------- .../hwtracing/coresight/coresight-cti-core.c | 56 ++-- .../hwtracing/coresight/coresight-cti-sysfs.c | 4 +- drivers/hwtracing/coresight/coresight-cti.h | 4 +- drivers/hwtracing/coresight/coresight-etb10.c | 3 +- .../coresight/coresight-etm3x-core.c | 6 +- .../coresight/coresight-etm4x-core.c | 6 +- .../hwtracing/coresight/coresight-platform.c | 168 +++++++++--- drivers/hwtracing/coresight/coresight-priv.h | 9 +- drivers/hwtracing/coresight/coresight-stm.c | 6 +- drivers/hwtracing/coresight/coresight-sysfs.c | 1 - .../hwtracing/coresight/coresight-tmc-etf.c | 2 +- .../hwtracing/coresight/coresight-tmc-etr.c | 88 +++--- drivers/hwtracing/coresight/coresight-tmc.h | 2 + drivers/hwtracing/coresight/coresight-tpdm.c | 4 +- drivers/hwtracing/coresight/coresight-tpiu.c | 3 +- drivers/hwtracing/coresight/coresight-trbe.c | 3 +- drivers/hwtracing/coresight/ultrasoc-smb.c | 3 +- drivers/hwtracing/coresight/ultrasoc-smb.h | 2 +- include/linux/coresight.h | 92 ++++--- 21 files changed, 483 insertions(+), 271 deletions(-) -- 2.34.1

2 years, 4 months

Re: [PATCH 3/3] coresight etm4x: Add 32-bit read/write option to split 64-bit words

by Leo Yan

Hi Steve, On Sun, Mar 05, 2023 at 10:54:08PM -0700, Steve Clevenger wrote: > An Ampere Computing design decision to not support 64-bit read/write > access in the ETMv4.6 implementation. > > The Ampere work around is to split ETMv4.6 64-bit register access > into 2 ea. 32-bit read/write accesses. > AC03_DEBUG_10 is described in the AmpereOne Developer Errata document: > > https://solutions.amperecomputing.com/customer-connect/products/AmpereOne-d… > > Signed-off-by: Steve Clevenger <scclevenger(a)os.amperecomputing.com> > --- > drivers/hwtracing/coresight/coresight-etm4x.h | 58 ++++++++++++++----- > 1 file changed, 44 insertions(+), 14 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h > index 434f4e95ee17..17457ec71876 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x.h > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h > @@ -539,11 +539,6 @@ > readl_relaxed((csa)->base + (offset)) : \ > read_etm4x_sysreg_offset((offset), false))) > > -#define etm4x_relaxed_read64(csa, offset) \ > - ((u64)((csa)->io_mem ? \ > - readq_relaxed((csa)->base + (offset)) : \ > - read_etm4x_sysreg_offset((offset), true))) > - > #define etm4x_read32(csa, offset) \ > ({ \ > u32 __val = etm4x_relaxed_read32((csa), (offset)); \ > @@ -567,15 +562,6 @@ > false); \ > } while (0) > > -#define etm4x_relaxed_write64(csa, val, offset) \ > - do { \ > - if ((csa)->io_mem) \ > - writeq_relaxed((val), (csa)->base + (offset)); \ > - else \ > - write_etm4x_sysreg_offset((val), (offset), \ > - true); \ > - } while (0) > - > #define etm4x_write32(csa, val, offset) \ > do { \ > __io_bw(); \ > @@ -1091,6 +1077,50 @@ void etm4_config_trace_mode(struct etmv4_config *config); > u64 etm4x_sysreg_read(u32 offset, bool _relaxed, bool _64bit); > void etm4x_sysreg_write(u64 val, u32 offset, bool _relaxed, bool _64bit); > > +/* 64-bit aligned to convert 64-bit access to 2 ea. 32-bit access */ > +#pragma pack(push, 8) > + > +struct etm_quad_split { > + u32 lsw; > + u32 msw; > +}; > + > +#pragma pack(pop) > + > +static inline u64 etm4x_relaxed_read64(struct csdev_access *csa, unsigned int offset) > +{ > + if (csa->io_mem) { > + if (csa->no_quad_mmio) { > + /* split 64-bit reads into 2 consecutive 32-bit reads */ > + struct etm_quad_split container; > + > + container.lsw = etm4x_read32(csa, offset); > + container.msw = etm4x_read32(csa, offset + sizeof(u32)); > + > + return *(u64 *) &container; To be honest, I am not familiar with this part, just want to remind two things. Firstly, here you could use hi_lo_readq_relaxed(), seems to me, hi_lo_readq_relaxed() does the same thing with above section and you don't need to define the structure etm_quad_split(). Secondly, IIUC, a main problem with splitting 64-bit access into two 32-bit accesses is breaking atomicity. If here have race condition between reading and writing 64-bit registers, we need to consider to use spinlock for register accessing. I'd like to leave the second issue to Suzuki/Mike/James for comfirmation in case I introduced complexity. > + } else > + return readq_relaxed(csa->base + offset); > + } else > + return read_etm4x_sysreg_offset(offset, true); Here need to add brackets: } else { return read_etm4x_sysreg_offset(offset, true); } > +} > + > +static inline void etm4x_relaxed_write64(struct csdev_access *csa, u64 quad, unsigned int offset) > +{ > + if (csa->io_mem) { > + /* split 64-bit writes into 2 consecutive 32-bit writes */ > + if (csa->no_quad_mmio) { > + struct etm_quad_split container; > + > + *(u64 *) &container = quad; > + > + etm4x_relaxed_write32(csa, container.lsw, offset); > + etm4x_relaxed_write32(csa, container.msw, offset + sizeof(u32)); > + } else > + writeq_relaxed(quad, csa->base + offset); > + } else > + write_etm4x_sysreg_offset(quad, offset, true); \ Ditto. Please drop the character '\' at the end of the line. Thanks, Leo P.s. I have a ADLink AVA platform (Ampere Altra SoC with 32 CPUs), I am glad to give a test if you can confirm this patch set can apply on it (and please clarify if there have any prerequisite for firmwares). > +} > + > static inline bool etm4x_is_ete(struct etmv4_drvdata *drvdata) > { > return drvdata->arch >= ETM_ARCH_ETE; > -- > 2.25.1 >

2 years, 4 months

Re: [BUG] perf: No samples found when using kcore + coresight

by James Clark

On 06/03/2023 21:13, Yang Shi wrote: > Hi, > > I'm seeking some help regarding perf record --kcore + coresight. When > I tracing with perf record --kcore -e cs_etm ... , perf report shows > "The perf.data/data data has no samples!". > > I tried other combinations: > 1. perf record --kcore (w/o using coresight): works > 2. perf record -e cs_etm ... : works > 3. Manually copy kcore with perf buildid-cache, then run perf record > -e cs_etm... : works > > So just "perf record --kcore -e cs_etm ..." doesn't work. > > I'm using v6.2 kernel and the perf is built from the same kernel > source with OpenCSD 1.4. Also attached the sample file generated by > perf. > > Any suggestion is appreciated. > > Thanks, > Yang Hi Yang, I don't see any issue with this command and I still get samples: perf record -e cs_etm// --kcore -- true You might want to try running both record and report in verbose and stdio mode (-vvv --stdio) to see if you see any warnings. I can't think of any way --kcore would cause an issue because all it does is save kcore into the .debug cache rather than affecting the actual perf.data file. Are you running perf report in the same place the recording was made? Or on another system? James

2 years, 4 months

Re: [PATCH 0/3] Ampere Computing ETMv4.x Support

by Suzuki K Poulose

Hi Steve On 07/03/2023 01:23, Steve Clevenger wrote: > > Hi Suzuki, > > To answer your question, Ampere plans to use the existing MMIO > implementation to introduce CoreSight HW Assisted Trace since we're > preparing for release. As a minimum, we know this would require a respin Please note that MMIO interface is for "external debug" not for self-hosted usecase, with system instruction support. This is why you need to work around the driver "as an errata". > of our CoreSight DSDT. Also, if I didn't misunderstand, it sounded like > you planned supporting work (e.g. ETMv4 not handled as an AMBA > device). Since our ETMv4 sink components (ETF, ETR, +CATU) remain memory > mapped, do these remain AMBA? Just to be clear, all of these components will be MMIO. We are simply moving the "Linux" driver framework from AMBA driver to platform device. This will be done in stages. ETMv4x would be moved in the first pass to allow us to support system instruction based devices seemlessly with ACPI. > > We understand ETMv4/ETE MMIO is going away. As a sysreg quick test, I As mentioned above it is not going away. MMIO is the way to access if that is *the only* access mode. For ETMv4.4+ and ETE MMIO system instructions is *the mode* of access for self-hosted. Please be aware that, going down this route may prevent them being virtualised (when we add the support in the near future). > bypassed the code which checks for an ETMv4 base address in order to > default to sysreg access. Trace collection failed with an error. I don't > have the time to chase after this right now, but I intend to budget the > time in the near future. If we can get to the bottom of this, we should be able to support the platform in a future proof way than adding this ugly work around of accessing via the *external MMIO* interface. Suzuki > > Thanks and regards, > Steve > > On 3/6/2023 2:29 AM, Suzuki K Poulose wrote: >> Hi Steve, >> >> On 06/03/2023 05:54, Steve Clevenger wrote: >>> Ampere ETMv4.x support. Added Ampere ETM ID, and changes required by >>> the Ampere ETMv4.x hardware implementation. >>> >> >> I don't see any mention of the access via system instructions. Where did >> that end up ? What is the conclusion on that front ? >> >> Kind regards >> Suzuki >> >> >>> Steve Clevenger (3): >>> Add known list of Ampere ETMv4 errata >>> coresight etm4x: Early clear TRCOSLAR.OSLK prior to TRCIDR1 read >>> coresight etm4x: Add 32-bit read/write option to split 64-bit words >>> >>> Documentation/arm64/silicon-errata.rst | 6 +- >>> .../coresight/coresight-etm4x-core.c | 50 +++++++++++----- >>> drivers/hwtracing/coresight/coresight-etm4x.h | 58 ++++++++++++++----- >>> include/linux/coresight.h | 3 + >>> 4 files changed, 89 insertions(+), 28 deletions(-) >>> >>

2 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight