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