Message-ID: <58439862-945d-4b7d-bf6a-6d398e6dd744@gmail.com>
Date: Wed, 17 Sep 2025 00:27:43 -0700
From: Bo Gan <ganboing@...il.com>
To: cp0613@...ux.alibaba.com, paul.walmsley@...ive.com, palmer@...belt.com,
 aou@...s.berkeley.edu, alex@...ti.fr, guoren@...nel.org
Cc: linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/4] riscv: tarce: Implement riscv trace pmu driver
 and perf support

On 9/11/25 05:44, cp0613@...ux.alibaba.com wrote:
> From: Chen Pei <cp0613@...ux.alibaba.com>
> 
> The RISC-V Trace Specification defines a standardized framework for
> capturing and analyzing the execution of RISC-V processors. Its main
> uses include: instruction and data tracing, real-time debugging, etc.
> Similar to Intel-PT and ARM-CoreSight.
> 
> According to the RISC-V Trace Control Interface specification [1].
> There are two standard RISC-V trace protocols which will utilize
> this RISC-V Trace Control Interface:
> - RISC-V N-Trace (Nexus-based Trace) Specification
> - Efficient Trace for RISC-V Specification
> So, this is a complete guideline for any standard RISC-V trace
> implementation.
> 
> This series of patches is mainly used to start related work and
> communication. It completes the following tasks:
> 1. dt-bindings completes the basic definition of riscv trace
>     component properties, but is still incomplete.
> 2. Implemented the basic RISC-V Trace PMU driver, including
>     support for the aux buffer.
> 3. Implemented basic support for AUXTRACE integration with perf
>     tools.
> 
> There's still more work to be done, such as:
> 1. Complete RISC-V Trace PMU implementation.
> 2. The perf.data generation and parsing including AUXTRACE events.
> 3. Taking RISC-V N-Trace as an example, implement the parsing of
>     Nexus Trace data format, including support for perf report and
>     perf script commands.
> We are still sorting out.
> 
> Any comments or suggestions are welcome.
> 
> [1] https://github.com/riscv-non-isa/tg-nexus-trace.git
> 

Hi Chen, thanks for starting this series. I have done a N-trace driver
in user space: https://github.com/ganboing/riscv-trace-umd, and I'd love
to see someone finally taking the effort to try a proper kernel driver.

My overall suggestions:

1. We need a way to expose proper topology to user-space like coresight.
    Thus, I'm thinking of using similar logic in coresight to export the
    topology through sysfs. Potentially we can abstract some logic out of
    coresight and make it a common core path that can be reused by riscv
    trace driver. Thus, we don't reinvent the wheel. This also helps
    debugging trace driver issues if anything goes wrong.

2. IMO, The driver should be moved to drivers/hwtracing/. It's not tightly
    coupled with arch, and there are many platform related logic where it
    doesn't belong to arch/riscv/. Having said that, I do believe we'll need
    something in arch/riscv/ eventually for trace once the self-hosted trace
    spec is finalized. Self-hosted trace behaves more like Intel PT, where
    the control will be done through some CSR(s), and it doesn't need those
    funnel/sink topology, and can emit trace stream to virtual memory directly.
    It's a per-hart thing with LAMBI and all that. I'd imagine that eventually
    riscv trace will be two parts. One is more coresight-alike, where you have
    encoders/funnel/sink/bridge that are described through DT and controlled by
    MMIO. The other part is more PT-alike, where the feature is described by
    ISA-string (I guess?), and it's much easier to program. For the time being,
    IMO, a coresight-alike driver, e.g., drivers/hwtracing/rvtrace, is more
    suited for existing platforms implementing N-trace or E-trace. Also, don't
    assume the memory sink is available. People using this "coresight-alike"
    driver can very-well be HW engineers who's collecting traces using external
    probes, so again I think we may want to abstract out part of coresight's
    logic and reuse then in riscv.

3. I've already implemented a N-trace decoder:
    https://github.com/ganboing/libnexus-rv
    It can decode N-trace on real HW (ESWIN EIC7700/Sifive P550). I'll try to
    see if I have the time to code up N-trace decoding in perf tool, once the
    driver and the perf trace collection part is stabilized. If not, I will be
    happy to review yours. Please include me in future series.

BTW, perhaps you want to also CC riscv Task Groups such as
   - Sig-Debug-Trace-Perf-Mon (DTPM)
   - Tech-Self-Hosted-Trace

to keep people like Beeman/Robert/Bruce/Iain/Greg posted. Robert mentioned
they tried to contact Sifive to see if they had similar driver upstreaming
effort just like yours, but there were no reply. Keep them posted anyway to
avoid duplicate work. We should also discuss this during riscv NA summit if
you or Guo's attending.

> Chen Pei (4):
>    dt-bindings: riscv: Add trace components description
>    riscv: event: Initial riscv trace driver support
>    tools: perf: Support perf record with aux buffer for riscv trace
>    riscv: trace: Support sink using dma buffer
> 
>   .../riscv/trace/riscv,trace,encoder.yaml      |  41 +++
>   .../riscv/trace/riscv,trace,funnel.yaml       |  46 ++++
>   .../riscv/trace/riscv,trace,sink.yaml         |  37 +++
>   arch/riscv/Kbuild                             |   1 +
>   arch/riscv/Kconfig                            |   2 +
>   arch/riscv/events/Kconfig                     |  11 +
>   arch/riscv/events/Makefile                    |   3 +
>   arch/riscv/events/riscv_trace.c               | 253 ++++++++++++++++++
>   arch/riscv/events/riscv_trace.h               | 133 +++++++++
>   arch/riscv/events/riscv_trace_encoder.c       | 109 ++++++++
>   arch/riscv/events/riscv_trace_funnel.c        | 160 +++++++++++
>   arch/riscv/events/riscv_trace_sink.c          | 100 +++++++
>   tools/perf/arch/riscv/util/Build              |   3 +
>   tools/perf/arch/riscv/util/auxtrace.c         |  33 +++
>   tools/perf/arch/riscv/util/pmu.c              |  18 ++
>   tools/perf/arch/riscv/util/riscv-trace.c      | 183 +++++++++++++
>   tools/perf/arch/riscv/util/tsc.c              |  15 ++
>   tools/perf/util/Build                         |   1 +
>   tools/perf/util/auxtrace.c                    |   4 +
>   tools/perf/util/auxtrace.h                    |   1 +
>   tools/perf/util/riscv-trace.c                 | 162 +++++++++++
>   tools/perf/util/riscv-trace.h                 |  18 ++
>   22 files changed, 1334 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/riscv/trace/riscv,trace,encoder.yaml
>   create mode 100644 Documentation/devicetree/bindings/riscv/trace/riscv,trace,funnel.yaml
>   create mode 100644 Documentation/devicetree/bindings/riscv/trace/riscv,trace,sink.yaml
>   create mode 100644 arch/riscv/events/Kconfig
>   create mode 100644 arch/riscv/events/Makefile
>   create mode 100644 arch/riscv/events/riscv_trace.c
>   create mode 100644 arch/riscv/events/riscv_trace.h
>   create mode 100644 arch/riscv/events/riscv_trace_encoder.c
>   create mode 100644 arch/riscv/events/riscv_trace_funnel.c
>   create mode 100644 arch/riscv/events/riscv_trace_sink.c
>   create mode 100644 tools/perf/arch/riscv/util/auxtrace.c
>   create mode 100644 tools/perf/arch/riscv/util/pmu.c
>   create mode 100644 tools/perf/arch/riscv/util/riscv-trace.c
>   create mode 100644 tools/perf/arch/riscv/util/tsc.c
>   create mode 100644 tools/perf/util/riscv-trace.c
>   create mode 100644 tools/perf/util/riscv-trace.h
> 
Bo

Powered by blists - more mailing lists