RE: Context id tracing with kernel at EL2

-----Original Message----- From: Leo Yan leo.yan@linaro.org Sent: 18 September 2020 11:52 To: Al Grant Al.Grant@arm.com; Mathieu Poirier mathieu.poirier@linaro.org Cc: Suzuki Poulose Suzuki.Poulose@arm.com; mike.leach@linaro.org; coresight@lists.linaro.org Subject: Re: Context id tracing with kernel at EL2

On Wed, Sep 16, 2020 at 09:58:52AM +0000, Al Grant wrote:

[...]

...

...

Thoughts ?

Another solution would be a specific immutable sysfs entry for the ETM, for the sole purpose of saying "I'm running at EL2 and will put the

process id in VMID".

...

Then "perf record" can read that. The question is then how it should put that in perf.data. It could either use TRCCONFIGR (which it's already faking) or TRCIDR2 as you suggest, but a more direct solution would be to use one of the spare header flags in PERF_RECORD_AUXDATA.

How about add a new node (e.g. "kern_el") under the sysfs?

/sys/bus/coresight/devices/etmX/mgmt/kern_el

perf tool can add a new entry in its metadata for "kern_el" when record, and when decode the CoreSight trace data, we can firstly get to know the kernel exception level from the metadata, and then based on this info to decide PID value from "context.context_id" or "context.vmid".

This approach seems to me is more directive than other options.

...

Would it be possible to reserve a few flags in the capabilities area of the main mmap buffer, to indicate "flags that tell you about the AUX data"? That would be another way for the kernel to tell userspace what

it's doing.

I think Al suggests to change the data structure perf_event_mmap_page like below:

struct perf_event_mmap_page {

union {
    __u64   capabilities;
    struct {
            __u64   cap_bit0                : 1, /* Always 0, deprecated, see commit

860f085b74e9 */ cap_bit0_is_deprecated : 1, /* Always 1, signals that bit 0 is zero */

                    cap_user_rdpmc          : 1, /* The RDPMC instruction can be used to

read counts */ cap_user_time : 1, /* The time_{shift,mult,offset} fields are used */ cap_user_time_zero : 1, /* The time_zero field is used */ cap_user_time_short : 1, /* the time_{cycle,mask} fields are used */

                    cap_vhe                 : 1, /* System supports VHE or not */
                    cap_____res             : 57;
    };
};

IMHO, I have concern for this since the capability 'cap_vhe' is specific for Arm64 arch and it cannot be commonly applied on other archs.

I was thinking more that the mmap header would have something like

cap_eventflag1:1 cap_eventflag2:1

allocated for event-specific flags. Then those flags can be used for meanings specific to event. The same goes for flags in the perf record headers - if a handful of flags are reserved for event-specific use, their meanings can be different for different event types.

Al

Thanks, Leo