On Fri, Jan 15, 2016 at 8:40 PM, Al Grant Al.Grant@arm.com wrote:
If I have understood this correctly then there is a significant issue here - for
the ARM STM hardware in the recommended configuration (i.e. on something like Juno) the masters are hardware allocated to sources -that is cores + S/NS security state. Therefore there is no concept of software applications being able to poll available masters - there is only one master and the number is fixed for a source core+S/NS state. If the application is later scheduled on a different core, then the hardware master number will change - and the high level decoder is likely to lose track of the application.
Right, right, if we only consider ARM STM. But this documentation is describing Intel STM as well :)
But you need to support the common subset. Configurable masters aren't going to work on ARM (as Mike says) so the framework needs to not assume they are. The rules can just map trace sources to channels and not masters.
Agree, that's just what I mentioned in another email. I'm planning to hide "masters" from users for this kind of hardware configuration via revising generic STM framework code.
On Intel how is the source CPU indicated in the trace? On ARM you can
I have no idea on this either so far.
have, for example, kernel trace from all the cores simultaneously outputting independent trace messages to STM, using the same channel range, and the CPU can be identified by master id, allowing the high-level decoder to reconstruct the trace messages output from each CPU. Does that work on
Yes, understand.
Intel too or is it required that when a trace source is outputting on several CPUs concurrently, each CPU has a separate channel range (this also assumes that the trace source is pinned to CPUs)?
I have to learn more about this further, and then may be able to answer this, thanks for your questions which would push me to think/learn more.
Thanks, Chunyan
Al
Thanks, Chunyan
This really means that the policy for masters should show only a single
master available, with lots of channels, or you can provide virtual masters using the top few bits of the channel ID and a reduced number of channels per master.
This can then be unpicked by the linux high level STM decoder layer (i.e. not
the OpenCSD STM decoder which will only provide output data in terms of hardware masters and channels).
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-----Original Message----- From: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Chunyan Zhang Sent: 14 January 2016 10:58 To: Mathieu Poirier Cc: coresight@lists.linaro.org; Mark Brown Subject: Fwd: My learning summary - STM policy management
Good day Mathieu and All,
I revised this documentation a little, and re-sending this to you (cc'ed maillist and Mark this time) simply because I want to explain how generic STM deals with master IDs you mentioned in another mail yesterday. To find the answer, you can directly go to 4. - "Allocate one master and a range of channels for stm_source class device:"
There are a few concepts / glossaries I need to explain here: i) 'stm_source class device' - is used to write trace data to an stm device once linked, like 'stm_ftrace' you wrote for testing integration of Ftrace with STM before. ii) STM device - means the real hardware device of STM which can be found under /dev/ directory on the target.
- STM policy management of master/channel:
- Policy management source code:
driver/hwtrace/stm/policy.c
- Policy management introduce: (excerpts from
Documentation/trace/stm.txt)
- On the receiving end of this STP stream (the decoder side), trace
sources can only be identified by master/channel combination, so in order for the decoder to be able to make sense of the trace that involves multiple trace sources, it needs to be able to map those master/channel pairs to the trace sources that it understands.
- To solve this mapping problem, stm class provides a policy
management mechanism via configfs, that allows defining rules that map string identifiers to ranges of masters and channels. If these rules (policy) are consistent with what decoder expects, it will be able to properly process the trace data.
- Create policy rules on target:
- mount -t configfs none /config (the directory 'stp-policy/' will
appear under 'config/')
- Create policy rule for given STM device：
mkdir /config/stp-policy/10006000.stm.xxx (‘10006000.stm’ is a STM device name to which this policy applies, this is just an example. ‘xxx’ is an arbitrary string which is separated with device by a dot; but "10006000.stm" must be same with the one which can be found under /dev directory)
- Create policy rules for a given stm_source class device:
mkdir /config/stp-policy/10006000.stm.my_policy/stm_ftrace (‘stm_ftrace’ is a registered device of stm_source class which can be linked with an STM device, and then use this 'stm_ftrace' to write trace data into STM and finally output to the sink buffer. Note that the rule's name must be same with the name of stm_source class device)
- After created policy rule, there will be two files 'master' and
'channel' under rule's directory, for example: # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/masters 0 127 # cat /config/stp-policy/10006000.stm.my_policy/stm_ftrace/channels 0 65535
These values mean the range of master/channels which can be used on the stm_source device whose name is the same with the rule's name (stm_ftrace in this case), the default values come from the configuration [1] of STM device (i.e. 10006000.stm in this case)
These master/channel files are configurable and this rule would be applied on the stm_source class device (stm_ftrace) when linking this stm_source class device with any STM device (10006000.stm in this case), for example, if you want to link 'stm_ftrace' with '10006000.stm', you can create the directories '10006000.stm.xxx/stm_ftrace/', and when linking happens, the rule under this directory will be applied on 'stm_ftrace'.
- Allocate one master and a range of channels for stm_source class device:
1 ) Like mentioned in 3. above, the policy rule which has the same name with the stm_source class device will be applied on this stm_source class device, and then this device can choose its one master and required number of channels from the range which this policy rule defined in "masters" and "channels" files (if there isn't policy rule with the same name, the default configuration of STM device will be applied.) for outputting traces. The number of required channels is configured in the stm_source class device driver.
- When linking stm_source with STM device happens, the program will
poll all masters from either the start master configured in the "masters" file under the policy rule directory if one policy rule was built for this stm_source class device or otherwise struct stm_data::sw_start which is configured in this STM device driver, to see if there are free channels on the current master, and the number of freed continuous channels must be larger than or equal to the quantity of required channels. The first eligible master and channel range will be configured as the output path of this stm_source class device.
- Allocate master/channels for applictions:
- Set policy rule which should include 'assigned master', 'first
assigned channel', 'the number of required channels' by means of stm_file ioctl interface. 2) If an application program doesn't set policy rule for itself, when this application writing data into STM device, a rule whose name is 'default' will be applied, if the 'default' policy cannot be discovered either, like what I wrote above, the default configuration of STM device will be applied.
Regards, Chunyan
[1] https://git.linaro.org/people/zhang.chunyan/linux.git/blob/5234c83d13 a4eb12f b34f773ffac54f653407fd4:/drivers/hwtracing/coresight/coresight-stm.c# l745 _______________________________________________ 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. _______________________________________________ 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.