Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 12 February 2016 at 13:33, Mathieu Poirier
 wrote:
> On 12 February 2016 at 09:27, Alexander Shishkin
>  wrote:
>> Mathieu Poirier  writes:
>>
>>> On 8 February 2016 at 06:26, Alexander Shishkin
>>>  wrote:
 This $end==$start situation itself may be ambiguous and can be
 interpreted either as having just one *static* master ID fixed for all
 SW writers (what I assumed from your commit message) or as having a
 floating master ID, which changes of its own accord and is not
 controllable by software.
>>>
>>> Some clarification here.
>>>
>>> On ARM from a SW point of view $end == $start and that doesn't change
>>> (with regards to masterIDs) .  The ambiguity comes from the fact that
>>> on other platforms where masterID configuration does change and is
>>> important, the condition $end == $start could also be valid.
>>
>> Yes, that's what I was saying. The thing is, on the system-under-tracing
>> side these two situations are not very different from one
>> another. Master IDs are really just numbers without any semantics
>> attached to them in the sense that they are not covered by the mipi spec
>> or any other standard (to my knowledge).
>
> We are definitely on the same page here, just using slightly different terms.
>
>>
>> The difference is in the way we map channels to masters. One way is to
>> allocate a distinct set of channels for each master (the way Intel Trace
>> Hub does it); another way is to share the same set of channels between
>> multiple masters.
>
> We are in total agreement.
>
>> So we can describe this as "hardware implements the
>> same set of channels across multiple masters" or something along those
>> lines.
>
> I suggest "Shared channels"?  In the end, that's really what it is...
>
> The outstanding issue is still how to represent these to different way
> of mapping things in the STM core.  I suggested a flag, called
> "mstatic" (but that can be changed), and a representation of '-1' in
> for masterIDs sysFS.  Whether we stick with that or not is irrelevant,
> I'd be fine with another mechanism.  What I am keen on is that from
> sysFS users can quickly tell which heuristic is enacted on that
> specific architecture.

Alex,

How do you want to proceed with the above?  Do you agree with my
current proposal or can you think of a better way?

Thanks,
Mathieu


>
>>
>> Actually, in the latter scheme of things you can also have multiple
>> masters, at least theoretically. Say, you have masters [0..15], each
>> with distinct set of channels, but depending on hardware state these
>> masters actually end up as $state*16+$masterID in the STP stream.
>>
>> So we might also think about differentiating between the hardware
>> masters (0 though 15 in the above example) and STP masters.
>
> I'm not sure I get what you mean here.  On ARM the masterIDs assigned
> in HW, which will depend on the state, will show up in the STP stream.
> But again, I might be missing your point.
>
> Thanks,
> Mathieu
>
>>
>> Regards,
>> --
>> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 12 February 2016 at 09:27, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> On 8 February 2016 at 06:26, Alexander Shishkin
>>  wrote:
>>> This $end==$start situation itself may be ambiguous and can be
>>> interpreted either as having just one *static* master ID fixed for all
>>> SW writers (what I assumed from your commit message) or as having a
>>> floating master ID, which changes of its own accord and is not
>>> controllable by software.
>>
>> Some clarification here.
>>
>> On ARM from a SW point of view $end == $start and that doesn't change
>> (with regards to masterIDs) .  The ambiguity comes from the fact that
>> on other platforms where masterID configuration does change and is
>> important, the condition $end == $start could also be valid.
>
> Yes, that's what I was saying. The thing is, on the system-under-tracing
> side these two situations are not very different from one
> another. Master IDs are really just numbers without any semantics
> attached to them in the sense that they are not covered by the mipi spec
> or any other standard (to my knowledge).

We are definitely on the same page here, just using slightly different terms.

>
> The difference is in the way we map channels to masters. One way is to
> allocate a distinct set of channels for each master (the way Intel Trace
> Hub does it); another way is to share the same set of channels between
> multiple masters.

We are in total agreement.

> So we can describe this as "hardware implements the
> same set of channels across multiple masters" or something along those
> lines.

I suggest "Shared channels"?  In the end, that's really what it is...

The outstanding issue is still how to represent these to different way
of mapping things in the STM core.  I suggested a flag, called
"mstatic" (but that can be changed), and a representation of '-1' in
for masterIDs sysFS.  Whether we stick with that or not is irrelevant,
I'd be fine with another mechanism.  What I am keen on is that from
sysFS users can quickly tell which heuristic is enacted on that
specific architecture.

>
> Actually, in the latter scheme of things you can also have multiple
> masters, at least theoretically. Say, you have masters [0..15], each
> with distinct set of channels, but depending on hardware state these
> masters actually end up as $state*16+$masterID in the STP stream.
>
> So we might also think about differentiating between the hardware
> masters (0 though 15 in the above example) and STP masters.

I'm not sure I get what you mean here.  On ARM the masterIDs assigned
in HW, which will depend on the state, will show up in the STP stream.
But again, I might be missing your point.

Thanks,
Mathieu

>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 8 February 2016 at 10:44, Al Grant  wrote:
>> Mike did write "master IDs are hardwired to individual cores and core 
>> security
>> states", which make assignment for one platform very static.
>> On the flip side those will change from one system to another.
>
> It depends on your perspective.  From the perspective of a userspace
> process not pinned to a core, the master id will appear to vary
> dynamically and unpredictably as the thread migrates from one
> core to another.  (That's actually useful if the decoder wants to know
> where the thread is running at any given point, as it can find that out
> for free, without the need to track migration events.)

Right, that's the expected (and desired) behaviour.

>
> On the other hand if you are pinned (e.g. you're the kernel on a
> particular core, or you're a per-core worker thread in some thread
> pooling system) then you have a fixed master id, and then you can
> have one instance per core all using the same range of channel
> numbers, with the master id indicating the core - this saves on
> channel space compared to having to give each core its own
> range of channel space.

>From an STM core and driver point of view channel mapping works the
same way - pinning of tasks is  a kernel artefact.  The problem of
representing masterIDs in the STM core for an architecture with HW
assigned masterIDs is still unresolved.

>
> Al
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Alexander Shishkin]

Mike Leach  writes:

> Hi,
>
> I think a quick clarification of the ARM hardware STM architecture may be of 
> value here.
>
> The ARM hardware STM, when implemented as recommend in a hardware design, the 
> master IDs are not under driver control, but have a hardwire association with 
> source devices in the system. The master IDs are hardwired to individual 
> cores and core security states, and there could be other IDs associated with 
> hardware trace sources requiring output via the hardware STM. (an example of 
> this is the ARM Juno development board).
>
> Therefore in multi-core systems many masters may be associated with a single 
> software STM stream. A user-space application running on Core 1, may have a 
> master ID of 0x11 in the STPv2 trace stream, but if this application is 
> context switched and later continues running on Core 2, then master ID could 
> change to 0x21.  Masters identify a hardware source in this scheme, the 
> precise values used will be implementation dependent.
>
> So the number of masters "available to the software" depends on your 
> interpretation of the phrase.
> If you mean "master IDs on which software trace will appear" then that will 
> be many - it depends on which core is running the application. However as 
> described above, this is not predictable by any decoder, and the master set 
> used may not be contiguous.
> If you mean "master IDs selectable/allocated by the driver" then that will be 
> 0 - the driver has no control, and possibly no knowledge of which master is 
> associated with the current execution context. (this is of course system 
> dependent - it may well be possible to have some configuration database 
> associating cores with hardware IDs, but this will be implementation and 
> board support dependant).
>
> Therefore, there is a requirement to tell both the user-space STM client and 
> decoder that not only is master ID management not needed - it is in fact not 
> possible and the key to identify the software source for a given STM packet 
> is the channel alone. In addition we have a nominal single Master ID 
> "available to the software", to satisfy the requirements of the generic ST 
> module API.
>
> So on Juno for example, while we do have 128 masters, each with 65536 
> channels, the master allocation is not visible to system software - each core 
> sees a single master with 65536 channels. Therefore differentiation between 
> software sources in the STM trace is by channel number allocations only.

Ok, thanks a lot for the detailed explanation. I was confused by the
"static" bit in the patch description. It looks like something along the
lines of this patch might indeed be in order.

Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mike Leach]

Hi,

I think a quick clarification of the ARM hardware STM architecture may be of 
value here.

The ARM hardware STM, when implemented as recommend in a hardware design, the 
master IDs are not under driver control, but have a hardwire association with 
source devices in the system. The master IDs are hardwired to individual cores 
and core security states, and there could be other IDs associated with hardware 
trace sources requiring output via the hardware STM. (an example of this is the 
ARM Juno development board).

Therefore in multi-core systems many masters may be associated with a single 
software STM stream. A user-space application running on Core 1, may have a 
master ID of 0x11 in the STPv2 trace stream, but if this application is context 
switched and later continues running on Core 2, then master ID could change to 
0x21.  Masters identify a hardware source in this scheme, the precise values 
used will be implementation dependent.

So the number of masters "available to the software" depends on your 
interpretation of the phrase.
If you mean "master IDs on which software trace will appear" then that will be 
many - it depends on which core is running the application. However as 
described above, this is not predictable by any decoder, and the master set 
used may not be contiguous.
If you mean "master IDs selectable/allocated by the driver" then that will be 0 
- the driver has no control, and possibly no knowledge of which master is 
associated with the current execution context. (this is of course system 
dependent - it may well be possible to have some configuration database 
associating cores with hardware IDs, but this will be implementation and board 
support dependant).

Therefore, there is a requirement to tell both the user-space STM client and 
decoder that not only is master ID management not needed - it is in fact not 
possible and the key to identify the software source for a given STM packet is 
the channel alone. In addition we have a nominal single Master ID "available to 
the software", to satisfy the requirements of the generic ST module API.

So on Juno for example, while we do have 128 masters, each with 65536 channels, 
the master allocation is not visible to system software - each core sees a 
single master with 65536 channels. Therefore differentiation between software 
sources in the STM trace is by channel number allocations only.

Best 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 Rdmailto:mike.le...@arm.com
Guide
Blackburn
BB1 2QE



> -Original Message-
> From: Alexander Shishkin [mailto:alexander.shish...@linux.intel.com]
> Sent: 05 February 2016 12:52
> To: Chunyan Zhang; mathieu.poir...@linaro.org
> Cc: r...@kernel.org; broo...@kernel.org; prat...@codeaurora.org;
> nicolas.gu...@st.com; cor...@lwn.net; Mark Rutland; Mike Leach;
> t...@ti.com; Al Grant; zhang.l...@gmail.com; linux-ker...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
> d...@vger.kernel.org
> Subject: Re: [PATCH V2 3/6] stm class: provision for statically assigned
> masterIDs
>
> Chunyan Zhang <zhang.chun...@linaro.org> writes:
>
> > From: Mathieu Poirier <mathieu.poir...@linaro.org>
> >
> > Some architecture like ARM assign masterIDs statically at the HW design
> > phase, making masterID manipulation in the generic STM core irrelevant.
> >
> > This patch adds a new 'mstatic' flag to struct stm_data that tells the
> > core that this specific STM device doesn't need explicit masterID
> > management.
>
> So why do we need this patch? If your STM only has master 42 allocated
> for software sources, simply set sw_start = 42, sw_end = 42 and you're
> good to go, software will have exactly one channel to choose from. See
> also the comment from :
>
>  * @sw_start:   first STP master available to software
>  * @sw_end: last STP master available to software
>
> particularly the "available to software" part. Any other kinds of
> masters the STM class code doesn't care about (yet).
>
> > In the core sw_start/end of masterID are set to '1',
> > i.e there is only one masterID to deal with.
>
> This is also a completely arbitrary and unnecessary requirement. Again,
> you can set both to 42 and it will still work.
>
> > Also this patch depends on [1], so that the number of masterID
> > is '1' too.
> >
> > Finally the lower and upper bound for masterIDs as presented
&

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 5 February 2016 at 05:52, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> From: Mathieu Poirier 
>>
>> Some architecture like ARM assign masterIDs statically at the HW design
>> phase, making masterID manipulation in the generic STM core irrelevant.
>>
>> This patch adds a new 'mstatic' flag to struct stm_data that tells the
>> core that this specific STM device doesn't need explicit masterID
>> management.
>
> So why do we need this patch? If your STM only has master 42 allocated
> for software sources, simply set sw_start = 42, sw_end = 42 and you're
> good to go, software will have exactly one channel to choose from. See
> also the comment from :

On ARM each source, i.e entity capable of accessing STM channels, has
a different master ID set in HW.  We can't assume the IDs are
contiguous and from a SW point of view there is no way to probe the
values.

>
>  * @sw_start:   first STP master available to software
>  * @sw_end: last STP master available to software
>
> particularly the "available to software" part. Any other kinds of
> masters the STM class code doesn't care about (yet).
>
>> In the core sw_start/end of masterID are set to '1',
>> i.e there is only one masterID to deal with.
>
> This is also a completely arbitrary and unnecessary requirement. Again,
> you can set both to 42 and it will still work.

True - any value will do. The important thing to remember is that on
ARM, there is only one masterID channel (from an STM core point of
view).  But we could also proceed differently, see below for more
details.

>
>> Also this patch depends on [1], so that the number of masterID
>> is '1' too.
>>
>> Finally the lower and upper bound for masterIDs as presented
>> in ($SYSFS)/class/stm/XYZ.stm/masters and
>> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
>> are set to '-1'.  That way users can't confuse them with
>> architecture where masterID management is required (where any
>> other value would be valid).
>
> Why is this a good idea? Having the actual master there will allow
> software to know what it is and also tell the decoding side what it is
> (assuming you have more than one source in the STP stream, it might not
> be easy to figure out, unless you know it in advance).

In the ARM world masterIDs are irrelevant so why bother with them?
Writing a '-1' simply highlight this reality.

Another way of approaching the problem would be to change sw_start/end
to a bitfield that represent the valid masterIDs but in my opinion, it
is a lot of code churn for information that isn't used outside of the
decoder.

Thanks,
Mathieu

>
> I don't see how one master statically assigned to software sources is
> different from two masters or 32 masters. And I don't see any benefit of
> hiding the master id from userspace. Am I missing something?
>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Alexander Shishkin]

Chunyan Zhang  writes:

> From: Mathieu Poirier 
>
> Some architecture like ARM assign masterIDs statically at the HW design
> phase, making masterID manipulation in the generic STM core irrelevant.
>
> This patch adds a new 'mstatic' flag to struct stm_data that tells the
> core that this specific STM device doesn't need explicit masterID
> management.

So why do we need this patch? If your STM only has master 42 allocated
for software sources, simply set sw_start = 42, sw_end = 42 and you're
good to go, software will have exactly one channel to choose from. See
also the comment from :

 * @sw_start:   first STP master available to software
 * @sw_end: last STP master available to software

particularly the "available to software" part. Any other kinds of
masters the STM class code doesn't care about (yet).

> In the core sw_start/end of masterID are set to '1',
> i.e there is only one masterID to deal with.

This is also a completely arbitrary and unnecessary requirement. Again,
you can set both to 42 and it will still work.

> Also this patch depends on [1], so that the number of masterID
> is '1' too.
>
> Finally the lower and upper bound for masterIDs as presented
> in ($SYSFS)/class/stm/XYZ.stm/masters and
> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
> are set to '-1'.  That way users can't confuse them with
> architecture where masterID management is required (where any
> other value would be valid).

Why is this a good idea? Having the actual master there will allow
software to know what it is and also tell the decoding side what it is
(assuming you have more than one source in the STP stream, it might not
be easy to figure out, unless you know it in advance).

I don't see how one master statically assigned to software sources is
different from two masters or 32 masters. And I don't see any benefit of
hiding the master id from userspace. Am I missing something?

Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html