Thanks guys! The dmbish() is not a huge deal. Just get a little nervous when i see barriers and don't completely understand why it is there. :)

Ah, You are right. Having taken a look at it again, yes, the SP-> SPM communication is register based and this spm_response_add() is invoked by SPM to push to a buffer within EL3 (its not a shared buffer between different ELs). I suspect the shared buffer primitives were written with shared buffer scenario in mind and the current prototype implementation does not optimize it for the case when the buffer is within EL3.

Thanks Paul, Soby.
spm_response_*() currently cannot invoked by any secure partition since the responses[] array is in EL3 space. Is this not the case ? or is it the expectation that the responses array will be mapped to secure EL0 some time in the future? I don't see how a secure partition can invoke spm_response_* other than through an SMC, in which case we are already in EL3 context and dont require the dmbish(), as Paul pointed. I understand your argument for sprt_queue_*, since they are invoked by EL3 and the secure partition.

Who is the lockless reader for spm_response_add() and spm_response_get()?

Apologies for the delay. I've had a look into the spm_buffers.c file and I understand your query is around the dmbish() that's performed shortly before releasing the lock in both spm_response_add() and spm_response_get().

anything ?

In T335#3913, @raghuncstate wrote:

Thanks for taking a look and providing confirmation! :)

Thanks for taking a look and providing confirmation! :)

Hello. Thanks for your report.

Thanks. Missed the lockless reader of the queue. Who is the lockless reader for spm_response_add() and spm_response_get()?

A secure partition may be reading from the queue from CPU1 at the same time as CPU0 pushes a new request. If this happens, it is needed that the stores are seen in the same order by all observers of the system.

Example comment 3

In T314#3758, @kennyliang-mtk wrote:

According to Hung-Te's comment,
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/860#message-233c99d5_765db5d9
I split the initial commit to several smaller patches.

According to Hung-Te's comment,
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/860#message-233c99d5_765db5d9
I split the initial commit to several smaller patches.

Hello kennyliang-mtk,

In T314#3510, @jts-arm wrote:

In T314#3507, @kennyliang-mtk wrote:

Excuse me, how do I link the commit,
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/860
to this task?

Hello kennyliang-mtk,
the link to the code review that you provided seems fine to me. Unless you had something more in mind?

John

In T314#3507, @kennyliang-mtk wrote:

Excuse me, how do I link the commit,
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/860
to this task?

Excuse me, how do I link the commit,
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/860
to this task?
Thanks.

Example comment 2

Example comment 1