Ken,
Task scheduling (context switching) in our RTOS is always performed in thread mode, even when asynchronous pre-emption occurs resulting from an ISR readying a higher priority task.
All kernel-managed interrupts are routed to a common interrupt dispatcher that, just prior to returning from an interrupt, will invoke the task scheduler when it determines that there are no more interrupts pending and there is scheduling work to do. In that case, an artificial interrupt context is created so that thread mode can be "returned to" from handler mode. The task scheduler is then invoked in thread mode from the stack of the pre-empted task.
Regarding secure interrupts, our use cases only employ secure interrupts as a consequence of a psa_call() initiating a process that completes when an interrupt goes off sometime later.
Rather than spin-waiting for the interrupt-completion signal, or parking in a WFI, we simply return from the psa_call() with a special return code indicating that the process has started and that the calling thread will be notified of completion by the secure callback mechanism I described at the conference in Lyon. The calling thread then pends on a semaphore. When the secure interrupt goes off later on, a dedicated non-secure interrupt is triggered that ultimately ends up posting the semaphore that the NS thread is pended on. Upon returning from the pend, the NS thread then re-enters the SP (using psa_call()) to complete the transaction.
Alan
-----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, December 10, 2019 8:04 PM To: tf-m@lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] [TF-M] Secure Interrupt handling - RE: TF-M technical Forum slides and recording
Thank Bill for updating this.
I want to use this thread to follow up on the topic 'secure interrupt' given in the 1st tech forum. That is a prologue of the scheduler and interrupt designs. And I do see there are some use cases that I did not focus on, so I want to collect more user scenarios first, and then try to enhance the drafting design (will be published after I updated it base on your inputs).
About the secure interrupt usage: - A secure interrupt would be introduced by a secure service call in general; is there any scenarios that there would be an interval secure interrupt since secure service want to do something? For example, a secure timer triggers to let secure service has the chance to do things in the background (not for an ongoing secure call from NSPE) after a period of time?
And the question about the system Alan mentioned, just want to confirm if it is a pure thread mode scheduling system? How does the system handle interrupts?
Thanks.
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Bill Fletcher via TF-M Sent: Monday, December 9, 2019 7:57 PM To: TF-M mailing list tf-m@lists.trustedfirmware.org Subject: [TF-M] TF-M technical Forum slides and recording
Hi all,
I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Regards
Bill