Hi Al, Mike,
On Thu, Apr 23, 2020 at 03:26:06PM +0100, Mike Leach wrote:
[...]
The patch below does the kernel and userspace side but is not complete. The problem is that userspace perf creates the metadata copy of TRCCONFIGR based on its request (and fills in the other id registers by reading sysfs), but the detection of EL2/E2H happens in the kernel which adjusts TRCCONFIGR, and it's this config which is needed for decode. I see three ways round this:
- have userspace test to see if the kernel is EL2 (somehow) and adjust the
metadata to mirror what the kernel is doing
- have the kernel pass the adjusted TRCCONFIGR back so perf can put it in the
metadata
Not necessarily the entire configr but at least a flag to indicate VMID contexts are in play.
- have the perf decoder get the thread id from whichever of VMID and
CONTEXTID is available in a PE_CONTEXT element
Obviously, the last is simplest, but it's a bodge, and means that OpenCSD will see VMIDs when its TRCCONFIGR says it won't. It's kind of cleanest to get
OpenCSD won't care. VMID/CID are pass through for the decoder - it's up to the client to use them or not. We use the trace CONFIGR value to spot things like return stack. The ETMv4 protocol tells us if VMID / CID is present and just believe that. The decode doesn't validate what it gets in trace from what is set up in the config / id registers in general when the content self describes. (we do use the architecture version and D / I settings to do a broad brush rejection of certain packet types, but that is about it).
the real TRCCONFIGR somehow, but how do we do that?
As I mentioned on the other thread, I think this problem ties in with the sink information issue - both want to get kernel selections into the AUX DATA headers or something similar. A common approach will be of benefit here.
I did a quick check and found OpenCSD's header has defined a field to indicate the exception level; so just curious if we can simply check the exception level in OpenCSD's element, if the exception level is EL2, then perf tool uses VMID rather than CID for the process ID.
If this is feasible, then here don't depend on TRCCONFIGR anymore. Does this make sense? Sorry might introduce noise.
Thanks, Leo