linux-kernel - Re: [RFC PATCH 0/4] riscv: tarce: Implement riscv trace pmu driver and perf support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250918061921.52513-1-cp0613@linux.alibaba.com>
Date: Thu, 18 Sep 2025 14:19:21 +0800
From: cp0613@...ux.alibaba.com
To: ganboing@...il.com
Cc: alex@...ti.fr,
	aou@...s.berkeley.edu,
	cp0613@...ux.alibaba.com,
	guoren@...nel.org,
	linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org,
	palmer@...belt.com,
	paul.walmsley@...ive.com
Subject: Re: [RFC PATCH 0/4] riscv: tarce: Implement riscv trace pmu driver and perf support

On Wed, 17 Sep 2025 00:27:43 -0700, ganboing@...il.com:

> > 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

Thank you very much for your review. Every suggestion and existing work is
valuable, and I will carefully evaluate it.

1. I will further investigate the technical details you mentioned in
   CoreSight, reusing existing design and code as much as possible.

2. Moving the driver to drivers/hwtracing/ is a good suggestion, and I've
   considered it before.

3. We've noticed that there are many types of sinks, such as the Lauterbach's
   Debug Probe, as you mentioned. The current code does not reflect this, I
   will consider compatibility later.

4. Your implementation of the N-trace decoder is very useful as a reference.
   I will study it carefully. We also have an internal implementation, which
   I will compare and provide feedback to you later.

5. The RISC-V Task Groups should indeed be cc'd. Thanks for the reminder.

Thank you,
Pei