Hi Alan,
That's a quite difficult question I think.
At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR.
However implementing this seems to be a nontrivial task.
The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it.
The phenomenon we observed with your setup was the following: 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal'
Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation.
To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts.
The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec.
Regards, Mate
From: DeMars, Alan ademars@ti.com Sent: 12 November 2019 17:47 To: Mate Toth-Pal Mate.Toth-Pal@arm.com Cc: Ken Liu (Arm Technology China) Ken.Liu@arm.com Subject: RE: secure interrupt handlng in IPC mode
You can CC the tf-m mailing list.
From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] Sent: Tuesday, November 12, 2019 8:02 AM To: DeMars, Alan Cc: Ken Liu (Arm Technology China) Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode
Hi Alan
Would it be OK to you if I cc the TF-M mailing list in my answer?
Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit.
Thanks, Mate
From: DeMars, Alan mailto:ademars@ti.com Sent: 11 November 2019 21:05 To: Mate Toth-Pal mailto:Mate.Toth-Pal@arm.com Cc: Ken Liu (Arm Technology China) mailto:Ken.Liu@arm.com Subject: secure interrupt handlng in IPC mode
Hi Mate!
I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv.
I think the below statements in the Cooperative Scheduling Rules discussion:
a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must extend to the priority level of the SP as it services the interrupt while in thread mode.
Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring.
So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced.
Is this correct thinking?
Alan
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.