HI Al,
On Tue, 26 May 2020 at 19:53, Al Grant Al.Grant@arm.com wrote:
-----Original Message----- From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of Mike Leach Sent: 26 May 2020 17:33 To: Suzuki Poulose Suzuki.Poulose@arm.com Cc: Coresight ML coresight@lists.linaro.org Subject: Re: Context id tracing with kernel at EL2
Hi,
On Tue, 26 May 2020 at 17:21, Suzuki K Poulose suzuki.poulose@arm.com wrote:
On 05/25/2020 04:56 PM, Mathieu Poirier wrote:
On Fri, 22 May 2020 at 09:30, Suzuki K Poulose suzuki.poulose@arm.com
wrote:
On 05/08/2020 04:43 PM, Mathieu Poirier wrote:
On Fri, 8 May 2020 at 00:11, Leo Yan <leo.yan@linaro.org mailto:leo.yan@linaro.org> wrote:
Hi Al, Suzuki, On Wed, May 06, 2020 at 10:17:15AM +0100, Suzuki Kuruppassery Poulose wrote: > On 05/05/2020 05:00 PM, Al Grant wrote: > > > > The patch below does the kernel and userspace side but is not complete. > > > > The problem is that userspace perf creates the metadata copyof
> > > > 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 > > > > > > > > - 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 the real TRCCONFIGR somehow, but how do we do that? > > > > > > We do get TRCCONFIGR in the perf records. We should simply make sure we get > > > the uptodate value (wherever we are getting it from). > > > > The copy in PERF_RECORD_AUXINFO (which is a synthetic record created > > by userspace perf) is, I believe, as I said: > > > > "userspace perf creates the metadata copy of TRCCONFIGR basedon
> > its request". > > > > So if the kernel modifies it based on information only the kernel knows, > > there's no current way to get the actual value. That was what I was trying > > to address with my suggestions. > > > > Have I missed some place the actual TRCCONFIGR is already being returned > > in other perf records? > > The sysfs is one place where we could expose this and this could be then > consumed by the perf tool while creating the TRCCONFIGR. Since theEL
> can't change, this could be a onetime probe activity.I'm joining this thread on the late and as such don't have all the context. But sysfs is never a good place to export run-time configuration registers as there could be multiple perf sessions active at the same time. This isn't a big issue for N:1 topologies but very real for 1:1.
I don't see how this affected by the sink topology, as this is an ETM configuration.
By sysfs, I mean, not necessarily under /sys/bus/coreight/.../etmN/
but, under :
/sys/bus/event_source/.../cs_etm/
We already expose various different information there. e.g, nr_addr_filters, sinks/
So we could expose something like :
trcconfigr/
and could describe how each of the individual event configs affect the TRCCONFIGR register. So that the perf tool can construct the TRCCONFIGR register from scratch just by looking at the trcconfigr directory.
e.g,
# cd /sys/bus/event_source/devices/cs_etm/ # for f in $(find format -type f); do echo $(basename $f) - $(cat $f); done cycacc - config:12 sinkid - config2:0-31 contextid - config:14 retstack - config:29 timestamp - config:28
$ for f in $(find trcconfigr -type f); do echo $(basename $f) - $(cat $f); done cycacc - 0x10 // Bit 4 timestamp - 0x800 // Bit 11 contextid - 0x8080 // Bit15 | Bit 7 On EL2 kernels - 0x40 // Bit 6 on EL1 kernels retstack - 0x1000 // Bit12
So those are configurations that apply to specific trace sessions. When dealing with concurrent trace sessions there is no way to guarantee the information exported to sysfs applies to the trace session that would read the information.
I think there is a bit of confusion here; The idea is the perf tool will construct the value of the traceconfigr based on the "options" selected by the user, just like it does now for "config1"/"config2"
i.e,
perf record -e cs_etm/cycacc,timestamp/ blah-blah
perf tool will :
map cycacc -> config1 |= BIT(12) and trcconfigr |= BIT($cat /sys/.../trcconfigr/cycacc)
and similarly for all the options. The values under the "trcconfigr" are static and only maps a given attribute to the traceconfig register bit.
Thus, any session can create the TRCCONFIGR accurately based on the events now, by dynamically looking up under the sysfs, rather than "compile time" static assumption of the the ETM model.
So how does this work when I copy the captured data off my target and try to decode offline?
Same as it did before, but this time TRCCONFIGR in the perf.data's PERF_RECORD_AUXTRACE_INFO will correctly indicate that the thread id is in vmid.
Yeah - that makes sense - I skimmed Suzukis code and somehow assumed it was grabbing the data live on decode rather than the thing that makes most sense - putting it in the INFO structures after the record has finished.
The problem we have now is that when "perf record" is constructing PERF_RECORD_AUXTRACE_INFO, which is a synthetic record that the kernel has nothing to do with, the session-specific value of TRCCONFIGR perf uses is one that it synthesizes based on the options it is passing into the kernel, and this doesn't take account of any adjustments made by the kernel, e.g. to track CONTEXTIDR_EL2 in the vmid field. The idea is to have sysfs provide enough (non-session-specific) info about the kernel, so that "perf record" can synthesize a TRCCONFIGR that is both session-specific and adjusted to take account of what the kernel is doing. In effect "perf record" is mirroring the kernel's own logic.
The alternative is to have the kernel pass something back in a record (e.g. a flag in PERF_RECORD_AUX), again to help "perf record" construct a correct TRCCONFIGR.
It would be much cleaner if the kernel generated all metadata needed to decode the AUX buffer, but that’s not how perf is designed.
I did think that perf was designed for exactly the task of extracting data from the kernel to allow user side analysis!
However I would agree there doesn't appear to be an obvious route out for the specifics we need other than embed it in the data we are outputting - i.e. the raw trace buffer. sysfs is simpler as long as it is read at the end of the record session.
Regards
Mike
Al
Regards
Mike
Cheers Suzuki _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.