[PATCH 1/1] firmware: smccc: Add tracepoints when SMCCC calls are made

[Bjorn Andersson]

On Thu 23 Sep 06:21 CDT 2021, Mark Rutland wrote:

> On Wed, Sep 22, 2021 at 03:37:00PM -0700, Elliot Berman wrote:
> > Add trace events for SMCCC calls. These traces allow for convenient
> > mechanism for kernel to log SMC/HVC instructions without requiring
> > extracting traces from firmware. SMCCC spec currently [1] allows for 7
> > argument registers and 4 result registers.
> 
> I think you've missed additions in recent versions of the spec. Since
> SMCCCv1.2 (which is described in version of the document you've linked),
> SMC64 calls may pass up to 17 argument registers (x1-x17) and receive up
> to 18 result registers (x0-x17). SMC32 calls have up to 7 argument
> registers (r1-r7) and up to 8 return registers (r0-r7).
> 
> What do you want to use this for? What specifically do you want to
> trace.
> 
> I'm worried that this is a very low level transport, and hooking this
> means tracing a bunch of unrelated users (e.g. PSCI, ARCH_WORKAROUND*
> calls, vendor-specific SMC interfaces), and potentially gets in the way
> of some of those use-cases (e.g. tracng this means it cannot be used
> from noinstr code, which we likely need to be able to do in future).
> 
> Generally I'd prefer to have tracepoints in specific drivers rather than
> in the SMCCC transport.
> 

I agree, putting the tracepoint at this low level will essentially
provide us with a hexdump of all SMC operations and one would more or
less need to so some post processing to get something useful out of it.
And in the few cases where the arguments are references to data buffers
there's no way to trace that content (e.g. qcom_scm_assign_mem()).

If we move it one step up we can provide trace data that's directly
useful to a human, provide insights in the data, allow for proper
filtering etc.

Regards,
Bjorn