Hi Andersson,

That was the design decision mainly because of two issues:

* The preempted NS execution by the Secure interrupt remains blocked until the handling is done. The preempted NS execution could be a high priority task/thread that is irrelevant to the Secure interrupt. So the long-time second level interrupt handling is not supported in this case.

* In complex NSPE with multi-threads, the NSPE and SPE context could mismatch and it makes the multiple Secure Context support difficult and error-prone.

For your use case, you could try the First-Level Interrupt Handling (FLIH) if the handling is simple. The FLIH is ensured to be executed in bounded time.

Best Regards, Kevin

From: Andersson, Joakim via TF-M tf-m@lists.trustedfirmware.org Sent: Friday, March 11, 2022 7:04 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Secure Partition interrupt signal processing

Hi.

I've been working on making an example on how an application can use the secure interrupts in a secure partition in TF-M. During this I've encountered an issue where the secure partition will not be scheduled to process the secure interrupt signal in certain conditions. I've compared it to the current SLIH and FLIH test cases to my observed behaviour and I could see that they did not have this problem. I've created a test-case that triggers the problem [0].

In the mailing list I can see that this was actually discussed recently [1]

The summary is that secure partitions will not be scheduled to process a secure interrupt signal when the interrupt is interrupting the NSPE. I could not find that this was documented anyway, but maybe I have overlooked. In any case I find this behaviour very unexpected and I would like to know if this is indeed a design decision and the behaviour has to be this way? If I wanted to do some processing in the secure partition context it would now mean that I have to get the NSPE to trigger this through a secure partition call. This seems like a limitation to me .

I'd like to know what would be the issue with scheduling the partition once it now has the signal asserted. I've done a quick test with scheduling the partition at this point with [2] and this now works as I expect it to. I'd be happy to follow up with submitting a change to schedule the partition as done in [2] if that is an acceptable solution.

[0] https://github.com/joerchan/tf-m-tests/commit/d9f0a3a7653b594d0fa797d9e0bca1... [1] https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.o... [2] https://github.com/joerchan/sdk-trusted-firmware-m/commit/e5512c6e8b2bad95c2...