On 14 January 2016 at 13:27, Chunyan Zhang <zhang.chunyan@linaro.org> wrote:

On Thu, Jan 14, 2016 at 9:20 PM, Mike Leach <Mike.Leach@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 :)

I guess it's worth explicitly separating the application visible model from the hardware model, saying that we may do things like simplify the view the application has of the system in order to handle hardware requirements like this?