This series adds initial support for RISC-V trace framework and drivers.
The RISC-V trace v1.0 specification is already ratified and can be found at:
https://github.com/riscv-non-isa/e-trace-encap/releases/tag/v1.0.0-ratified
https://github.com/riscv-non-isa/tg-nexus-trace/releases/tag/1.0_Ratified

The RISC-V trace framework and drivers are designed to be agnostic to the
underlying trace protocol hence both RISC-V E-trace and RISC-V N-trace should
work fine. The discovery of trace protocl parameters are left to user-space
trace decoder.

In ther future, there will be subsequent series adding:
1) Sysfs support
2) ACPI support
3) More trace drivers (such as funnel, ATB, etc)
4) Support for upcoming self-hosted trace specification
5) ... and more ...

These patches can also be found in the riscv_trace_support_v1 branch at:
https://github.com/avpatel/linux.git

To test the patches, we need QEMU virt machine with RISC-V trace support
which can be found in rv-etrace branch at:
https://gitlab.com/danielhb/qemu.git

To capture rvtrace data using perf on QEMU virt machine do the following:
1) Launch QEMU virt machine
   $ qemu-system-riscv64 -nographic -M virt -smp 2 -bios fw_dynamic.bin \
     -kernel Image -append "root=/dev/vda rw console=ttyS0 earlycon=sbi" \
     -drive file=/path/to/rootfs.img,id=disk1,if=none,format=raw \
     -device virtio-blk-device,drive=disk1
2) Run perf record to capture rvtrace data
   $ perf record --all-cpus -e rvtrace/event=0x1/ <command>
3) The step2 would create a perf.data file which has the rvtrace data.
   Now run perf report -D and look for PERF_RECORD_AUXTRACE event
   section(s) which point(s) to the actual rvtrace data offset.

Anup Patel (5):
  dt-bindings: Add RISC-V trace component bindings
  rvtrace: Initial implementation of driver framework
  rvtrace: Add functions to create/destroy a trace component path
  rvtrace: Add function to copy into perf AUX buffer
  MAINTAINERS: Add entry for RISC-V trace framework and drivers

Mayuresh Chitale (6):
  rvtrace: Add functions to start/stop tracing on a component path
  rvtrace: Add trace encoder driver
  rvtrace: Add trace ramsink driver
  rvtrace: Add perf driver for tracing using perf tool
  perf tools: Add RISC-V trace PMU record capabilities
  perf tools: Initial support for RISC-V trace decoder

 .../bindings/riscv/riscv,trace-component.yaml | 110 +++
 MAINTAINERS                                   |  11 +
 drivers/Makefile                              |   1 +
 drivers/hwtracing/Kconfig                     |   2 +
 drivers/hwtracing/rvtrace/Kconfig             |  32 +
 drivers/hwtracing/rvtrace/Makefile            |   6 +
 drivers/hwtracing/rvtrace/rvtrace-core.c      | 781 ++++++++++++++++++
 drivers/hwtracing/rvtrace/rvtrace-encoder.c   | 107 +++
 drivers/hwtracing/rvtrace/rvtrace-perf.c      | 343 ++++++++
 drivers/hwtracing/rvtrace/rvtrace-platform.c  | 174 ++++
 drivers/hwtracing/rvtrace/rvtrace-ramsink.c   | 198 +++++
 include/linux/rvtrace.h                       | 341 ++++++++
 tools/perf/arch/riscv/util/Build              |   1 +
 tools/perf/arch/riscv/util/auxtrace.c         | 218 +++++
 tools/perf/util/Build                         |   1 +
 tools/perf/util/auxtrace.c                    |   4 +
 tools/perf/util/auxtrace.h                    |   1 +
 tools/perf/util/rvtrace-decoder.c             |  91 ++
 tools/perf/util/rvtrace.h                     |  20 +
 19 files changed, 2442 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
 create mode 100644 drivers/hwtracing/rvtrace/Kconfig
 create mode 100644 drivers/hwtracing/rvtrace/Makefile
 create mode 100644 drivers/hwtracing/rvtrace/rvtrace-core.c
 create mode 100644 drivers/hwtracing/rvtrace/rvtrace-encoder.c
 create mode 100644 drivers/hwtracing/rvtrace/rvtrace-perf.c
 create mode 100644 drivers/hwtracing/rvtrace/rvtrace-platform.c
 create mode 100644 drivers/hwtracing/rvtrace/rvtrace-ramsink.c
 create mode 100644 include/linux/rvtrace.h
 create mode 100644 tools/perf/arch/riscv/util/auxtrace.c
 create mode 100644 tools/perf/util/rvtrace-decoder.c
 create mode 100644 tools/perf/util/rvtrace.h

-- 
2.43.0

On Thu, Oct 02, 2025 at 11:37:21AM +0530, Anup Patel wrote:
> This series adds initial support for RISC-V trace framework and drivers.
> The RISC-V trace v1.0 specification is already ratified and can be found at:
> https://github.com/riscv-non-isa/e-trace-encap/releases/tag/v1.0.0-ratified
> https://github.com/riscv-non-isa/tg-nexus-trace/releases/tag/1.0_Ratified
> 
> The RISC-V trace framework and drivers are designed to be agnostic to the
> underlying trace protocol hence both RISC-V E-trace and RISC-V N-trace should
> work fine. The discovery of trace protocl parameters are left to user-space
> trace decoder.
> 
> In ther future, there will be subsequent series adding:
> 1) Sysfs support

why does "trace" need sysfs support?  No other cpu platform uses that
today, so why is a new user/kernel api needed?

thanks,

greg k-h

On Thu, Oct 2, 2025 at 11:56 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Oct 02, 2025 at 11:37:21AM +0530, Anup Patel wrote:
> > This series adds initial support for RISC-V trace framework and drivers.
> > The RISC-V trace v1.0 specification is already ratified and can be found at:
> > https://github.com/riscv-non-isa/e-trace-encap/releases/tag/v1.0.0-ratified
> > https://github.com/riscv-non-isa/tg-nexus-trace/releases/tag/1.0_Ratified
> >
> > The RISC-V trace framework and drivers are designed to be agnostic to the
> > underlying trace protocol hence both RISC-V E-trace and RISC-V N-trace should
> > work fine. The discovery of trace protocl parameters are left to user-space
> > trace decoder.
> >
> > In ther future, there will be subsequent series adding:
> > 1) Sysfs support
>
> why does "trace" need sysfs support?  No other cpu platform uses that
> today, so why is a new user/kernel api needed?

We saw trace support for other architectures (e.g. ARM coresight) allowing
trace start/stop through sysfs. If this is an obsolete or not preferred approach
then we will deprioritize and possibly never add it.

Regards,
Anup

On Thu, Oct 02, 2025 at 12:09:23PM +0530, Anup Patel wrote:
> On Thu, Oct 2, 2025 at 11:56 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Oct 02, 2025 at 11:37:21AM +0530, Anup Patel wrote:
> > > This series adds initial support for RISC-V trace framework and drivers.
> > > The RISC-V trace v1.0 specification is already ratified and can be found at:
> > > https://github.com/riscv-non-isa/e-trace-encap/releases/tag/v1.0.0-ratified
> > > https://github.com/riscv-non-isa/tg-nexus-trace/releases/tag/1.0_Ratified
> > >
> > > The RISC-V trace framework and drivers are designed to be agnostic to the
> > > underlying trace protocol hence both RISC-V E-trace and RISC-V N-trace should
> > > work fine. The discovery of trace protocl parameters are left to user-space
> > > trace decoder.
> > >
> > > In ther future, there will be subsequent series adding:
> > > 1) Sysfs support
> >
> > why does "trace" need sysfs support?  No other cpu platform uses that
> > today, so why is a new user/kernel api needed?
> 
> We saw trace support for other architectures (e.g. ARM coresight) allowing
> trace start/stop through sysfs. If this is an obsolete or not preferred approach
> then we will deprioritize and possibly never add it.

Why is that needed for coresight and other arches do not need it?
Perhaps it should be deleted from that codebase instead?

thanks,

greg k-h

On 10/1/25 23:44, Greg KH wrote:
> On Thu, Oct 02, 2025 at 12:09:23PM +0530, Anup Patel wrote:
>> On Thu, Oct 2, 2025 at 11:56 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Thu, Oct 02, 2025 at 11:37:21AM +0530, Anup Patel wrote:
>>>> This series adds initial support for RISC-V trace framework and drivers.
>>>> The RISC-V trace v1.0 specification is already ratified and can be found at:
>>>> https://github.com/riscv-non-isa/e-trace-encap/releases/tag/v1.0.0-ratified
>>>> https://github.com/riscv-non-isa/tg-nexus-trace/releases/tag/1.0_Ratified
>>>>
>>>> The RISC-V trace framework and drivers are designed to be agnostic to the
>>>> underlying trace protocol hence both RISC-V E-trace and RISC-V N-trace should
>>>> work fine. The discovery of trace protocl parameters are left to user-space
>>>> trace decoder.
>>>>
>>>> In ther future, there will be subsequent series adding:
>>>> 1) Sysfs support
>>>
>>> why does "trace" need sysfs support?  No other cpu platform uses that
>>> today, so why is a new user/kernel api needed?
>>
>> We saw trace support for other architectures (e.g. ARM coresight) allowing
>> trace start/stop through sysfs. If this is an obsolete or not preferred approach
>> then we will deprioritize and possibly never add it.
> 
> Why is that needed for coresight and other arches do not need it?
> Perhaps it should be deleted from that codebase instead?
> 
> thanks,
> 
> greg k-h

Hi Greg,

sysfs is helpful for controlling the trace if not utilized through perf
framework. It can also be used by userspace to discover the topology of
trace components and their capabilities. @Anup I assume this driver is
designed with other sinks in mind (not just ramsink), so it can be used
to emit trace to external probes, right?

Bo

On Fri, Oct 3, 2025 at 2:13 AM Bo Gan <ganboing@gmail.com> wrote:
>
> On 10/1/25 23:44, Greg KH wrote:
> > On Thu, Oct 02, 2025 at 12:09:23PM +0530, Anup Patel wrote:
> >> On Thu, Oct 2, 2025 at 11:56 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >>>
> >>> On Thu, Oct 02, 2025 at 11:37:21AM +0530, Anup Patel wrote:
> >>>> This series adds initial support for RISC-V trace framework and drivers.
> >>>> The RISC-V trace v1.0 specification is already ratified and can be found at:
> >>>> https://github.com/riscv-non-isa/e-trace-encap/releases/tag/v1.0.0-ratified
> >>>> https://github.com/riscv-non-isa/tg-nexus-trace/releases/tag/1.0_Ratified
> >>>>
> >>>> The RISC-V trace framework and drivers are designed to be agnostic to the
> >>>> underlying trace protocol hence both RISC-V E-trace and RISC-V N-trace should
> >>>> work fine. The discovery of trace protocl parameters are left to user-space
> >>>> trace decoder.
> >>>>
> >>>> In ther future, there will be subsequent series adding:
> >>>> 1) Sysfs support
> >>>
> >>> why does "trace" need sysfs support?  No other cpu platform uses that
> >>> today, so why is a new user/kernel api needed?
> >>
> >> We saw trace support for other architectures (e.g. ARM coresight) allowing
> >> trace start/stop through sysfs. If this is an obsolete or not preferred approach
> >> then we will deprioritize and possibly never add it.
> >
> > Why is that needed for coresight and other arches do not need it?
> > Perhaps it should be deleted from that codebase instead?
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> sysfs is helpful for controlling the trace if not utilized through perf
> framework. It can also be used by userspace to discover the topology of
> trace components and their capabilities. @Anup I assume this driver is
> designed with other sinks in mind (not just ramsink), so it can be used
> to emit trace to external probes, right?
>

The rvtrace driver framework is intended to support all types of trace
components and any topology between these components. The current
patchset only adds encoder and ramsink trace component drivers since
that is what we emulate in QEMU right now.

Regarding sysfs based tracing, the main use-case (like you mentioned)
is the enabling tracing when the sinks are external devices which capture
and store trace data somewhere outside. The perf based tracing is used
for hosted tracing where the ramsink stores trace data in ram and perf
tool captures it in the form of perf data.

Regards,
Anup