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). Thanks, Leo
