On 2/22/2023 7:13 AM, Leo Yan wrote:
On Wed, Feb 15, 2023 at 04:05:36PM +0100, Arnd Bergmann wrote:
[...]
To my knowledge the hwtracing framework is an interface for
enabling/disabling traces and then you get a stream of trace data out of
it.
With DCC you essentially write a small "program" to be run at the time
of an exception (or triggered manually). When the "program" is run it
acquire data from mmio interfaces and stores data in sram, which can
then be retrieved - possibly after the fatal reset of the system.
Perhaps I've misunderstood the hwtracing framework, please help me steer
Souradeep towards a subsystem you find suitable for this functionality.
I'm also not too familiar with tracing infrastructure and was hoping
that the coresight maintainers (Mathieu, Suzuki, Mike and Leo)
would have some suggestions here. My initial guess was that in
both cases, you have hardware support that is abstracted by the
kernel in order to have a user interface that can be consumed
by the 'perf' tool.
My understanding is hwtracing provides a common framework for STM so
that different tracing IPs (like Intel_th and Arm CoreSight) can
register STM module into this framework. The framework code is placed
in: linux/drivers/hwtracing/stm.
Now kernel doesn't provide a general framework for all hardware tracing
IPs, e.g. Arm CoreSight has its own framework to manage tracing
components and creating links with sinks.
Simply to say, we can place DCC driver in linux/drivers/hwtracing folder
(like Hisilicon's ptt driver), but we have no common framework for it to
use.
Based on reading DCC's driver, seems to me it's more like a bus tracing
module rather than a uncore PMU. I found the driver does not support
interrupt, I am not sure this is a hardware limitation or just software
doesn't implement the interrupt handling, without interrupt, it would be
difficult for using DCC for profiling.
If we register DCC into perf framework, the good thing is DCC can use
perf framework (e.g. perf's configs) as its user space interface, but
it's still not clear for me how to capture the DCC trace data (no
interrupt and not relevant with process task switching).
[...]
If the possible use is purely for saving some state across
a reboot, as opposed to other events, I wonder if there is
a good way to integrate it into the fs/pstore/ code, which
already has a way to multiplex various kinds of input (log
buffer, ftrace call chain, userspace strings, ...) into
various kinds of persistent buffers (sram, blockdev, mtd,
efivars, ...) with the purpose of helping analyze the
state after a reboot.
Good point!
I understand pstore/ramoops is somehow like a sink which routes the
tracing data (software tracing data but not hadware tracing data) to
persistent memory. This is why we also can route these software
tracing data to STM (hardware sink!).
Seems to me, Arnd suggests to connect two sinks between DCC and
pstore (to persistent memory). But I cannot give an example code in
kernel for doing this way, sorry if I miss something.
Essentially, a good user case is to keep a persistent memory for the
tracing data, then after rebooting cycle we can retrieve the tracing
data via user space interface (like sysfs node).
Hi Leo/Arnd,
Just wanted to let you know that the justification of not using PStore
was already given in the version 1 of this patch series as below
https://lore.kernel.org/linux-arm-msm/ab30490c016f906fd9bc5d789198530b@xxxxxxxxxxxxxx/#r
PStore/Ramoops only persists across warm-reboots which is present for
chrome devices but not for android ones. Also the dcc_sram contents can
also be collected by going for a software trigger after loading the
kernel and the dcc_sram is parsed to get the register values with the
opensource parser as below
https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools/tree/dcc_parser
Pstore on the other hand can only be collected on the next reboot.
Thanks,
Souradeep
Thanks,
Leo
