On 2023/12/4 21:54, Sumit Garg wrote:
> Hi Randy,
>
> On Mon, 27 Nov 2023 at 13:03, Randy Li via OP-TEE
> <[email protected]> wrote:
>> Hello
>>
>> I was wondering whether the current op-tee os support this that secure
>> monitor would trigger the op-tee to handle the native interrupter
>> without forwarding it to the REE?
> I would suggest you to go through this doc [1] to see if it answers
> all your questions. If not then let us know, we will help to clarify
> further.
>
> [1] https://optee.readthedocs.io/en/latest/architecture/core.html#interrupt-handling
>
> -Sumit
"When a secure interrupt is signaled by the Arm GIC, it shall reach the
OP-TEE OS interrupt exception vector. If the secure world is executing,
OP-TEE OS will handle interrupt straight from its exception vector."
And Section "Deliver secure interrupt to secure world when SCR_NS is set"
I think those are the answer to my initial question.
But I didn't see such practice. In the recent changes to Linux kernel,
likes OP-TEE notifications, I think the most of platforms would like not
let the Secure OS handle the devices' interrupters? I didn't know such a
driver in Linux kernel either.
When a CPU core, which is holding a spinlock, have been restored to
Secure context by monitor, would it halt the other cores which are
waiting for the release of that spinlock?
Besides, when we use a spinlock in the kernel, in the most of time, we
except all IRQs are masked(spin_lock_irqsave), could this masked the
secure interrupter?
Also, I didn't see there is a guideline about how OP-TEE os should
handle native interrupt in this case. If it took too much time, it may
lead an innocent process be regarded as hardlockup (or softlockup if it
turns to REE after all) in the linux kernel.
>> If the answer is yes, could it lead to a dead lock when the linux kernel
>> is holding a spinlock(usually irq is disabled in that CPU core) ?
>>
>> I didn't find much about how should we handle the secure interrupter
>> from document, the general way seems to either forward it to REE or just
>> don't use the secure interrupter at all.
>>
>> Let the REE handle the interrupter may not be a good idea, since the
>> device could we should ack the interrupter in it, is protected by the
>> trustzone, we need to switch CPU to secure mode to handle this tiny task.
>>
>> I wish I could know more solution about the interrupter here.
>>
>> Sincerely
>>
>> Randy
>>