New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-secure OS Schedules OP-TEE Question #1183

SimonWan opened this Issue Nov 15, 2016 · 5 comments


None yet
4 participants

SimonWan commented Nov 15, 2016

Hi experts,

Now I'm trying to understand how does the both secure and non-secure tasks schedule together.

I think I once read the document which says that OPTEE-OS doesn't have a scheduler by itself so I think it's the non-secure OS takes responsibility for schedule both OS's tasks.

In my opinion, the non-secure OS could either takes entire secure OS as an entity to schedule or takes every Trusted Application as a separate entity so I want to know which way is the current implementation, thank you.



This comment has been minimized.


jbech-linaro commented Nov 15, 2016

Hi Simon,

You're right OP-TEE doesn't have its own scheduler, instead it's being scheduled by Linux kernel.

// Joakim


This comment has been minimized.


jenswi-linaro commented Nov 15, 2016

And what scheduled is the work done during an SMC. This is usually an open session, invoke command or close session, each of those involves running some TA code also.


This comment has been minimized.

SimonWan commented Nov 15, 2016

@jenswi-linaro thank you for the answer.

Now let's say there is a CA and it opens a session, invokes TA function and then closes session.
You mean the NS OS's scheduler would take "opening", "invoking" and "closing" as three entities and schedule them separately?

@SimonWan SimonWan closed this Nov 15, 2016

@SimonWan SimonWan reopened this Nov 15, 2016


This comment has been minimized.


etienne-lms commented Nov 16, 2016

@SimonWan, the NS OS usually reschedules its active tasks (threads) based on non-secure timer notifications. OP-TEE is designed to relay such non-secure events when they occur while CPU executes in the secure world (OP-TEE).

When a CA 'opens', invokes' and 'closes' a session, it does this sequentially.

First CA calls "open session": a NS OS thread (thread A) invokes OP-TEE.
While the "open" request is being executed in OPTEE, if a non-secure timer interrupt occurs, the OP-TEE handler for non-secure interrupts freeze the OP-TEE execution thread and schedules back the NS OS. When core enter back NS OS, the pending HW exception is handled.

While NS OS handles the exception, the NS OS thread A (see above) is halted in linux optee driver. Since exception (scheduler timer event?), NS OS may decide to reschedule tasks, thread A might be freezed. When NS OS will decide to schedule back thread A, the linux optee driver will invoke back OP-TEE and resume initial "open" request.

OP-TEE will return to CA only upon completion of the initial "open session" request, with status info.

The "invoke TA command" request it called by CA only after completion of the "open session" request. Same, the "close session" request from CA will be called only once CA has completed "open" and "invoke" requests. Each is sequential. NS OS timer interrupts may occur at any time leading to NS OS rescheduling its active threads.


This comment has been minimized.

SimonWan commented Nov 16, 2016

@etienne-lms thank you for the detailed explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment