linux-kernel - Re: [PATCH 00/11] Linux RISC-V trace framework and drivers

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: <CAK9=C2UPHf29DeLh6DikyLPAw-cQ+-FW8-uqzbjJWYaraJYO8w@mail.gmail.com>
Date: Fri, 3 Oct 2025 09:45:15 +0530
From: Anup Patel <apatel@...tanamicro.com>
To: Bo Gan <ganboing@...il.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Ian Rogers <irogers@...gle.com>, 
	Alexandre Ghiti <alex@...ti.fr>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>, Jiri Olsa <jolsa@...nel.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, Liang Kan <kan.liang@...ux.intel.com>, 
	Mayuresh Chitale <mchitale@...il.com>, Anup Patel <anup@...infault.org>, 
	Atish Patra <atish.patra@...ux.dev>, Andrew Jones <ajones@...tanamicro.com>, 
	Sunil V L <sunilvl@...tanamicro.com>, linux-riscv@...ts.infradead.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/11] Linux RISC-V trace framework and drivers

On Fri, Oct 3, 2025 at 2:13 AM Bo Gan <ganboing@...il.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@...uxfoundation.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