Re: [TF-M] [EXTERNAL] Secure Interrupt handling - RE: TF-M technical Forum slides and recording
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
Hi Alan,
Thanks for you explanation, that helps much.
From your description, I think you have finished these two parts: 1. Return specific error code while psa_call() meets psa_wait() for interrupts. 2. psa_call() could support re-call and return the result back.
Are there any patches for these two parts?
The point I guess is, IPC SP runs at the lowest priority and when you notify non-secure by IRQ it may get preempted immediately. From the system you described, scheduling is always doing under thread mode, then it would be hard for you creating the context to return back to secure side because the scheduler is running based on the thread being preempted. The implementation may be something like this (May be it is wrong because I'm just guessing):
ISR() { if (ICSR.RETTOBASE) { somewhere = {preempted_ctx->r0~r3, r12, lr}; preempted_ctx->lr = preempted_ctx->ra; preempted_ctx->ra = scheduler(); /* Backup of callee registers are done in scheduler */
BX EXC_RETURN; } }
In this case, I think we have to trigger the interrupt in some mode with higher priority so that after SPM schedules back to non-secure context (The secure context preempted one is non-secure I guess) and then a tail-chain to non-secure scheduler which makes non-secure thread being preempted and get handled by the non-secure ISR.
Well, looks in your case you are using Secure IRQ for some service related issues and may be preempted while non-secure is running with a pending psa_call(). Let me take a note to make it as an scenario.
BR
/Ken
-----Original Message----- From: DeMars, Alan ademars@ti.com Sent: Thursday, December 12, 2019 1:59 PM To: Ken Liu (Arm Technology China) Ken.Liu@arm.com Cc: 'tf-m@lists.trustedfirmware.org' tf-m@lists.trustedfirmware.org Subject: RE: [EXTERNAL] [TF-M] Secure Interrupt handling - RE: TF-M technical Forum slides and recording
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
tf-m@lists.trustedfirmware.org
-
DeMars, Alan -
Ken Liu (Arm Technology China)