OPTEE OS on one core

[sakjain92]

Hi,

I have a requirement for OPTEE OS to run on Core0 only. All other cores shouldn't be able to make SMC calls to OPTEE (but should be able to make PSCI calls). So what all changes do this require (OPTEE OS, ATF, OPTEE clients, OPTEE driver)?

For OPTEE and ATF, I think we only need to change the number of cores to 1.

Within the driver, there might be three approaches as far as I can think: 1) OPTEE driver rejects any API calls from cores other than Core0 2) OPTEE Client application only run on Core 0 - using taskset (change core affinity) 3) OPTEE driver assigns the process to Core 0 - using sched_setaffinity.

Are these the only changes needed? And are all of these proper method to do this/ which is the best method?

[jenswi-linaro]

Since you plan to keep support for PSCI in ARM-TF you'll probably need to keep all the cores configured, but with some hack to refuse entering Secure EL1 on any but Core0.

For OP-TEE it should be OK to set the number of cores to 1.

For the driver I would recommend option 3, with a temporary affinity during the actual SMC if that's possible.

[ghost]

We're closing this issue since the question has been answered. If you however feel that you have additional questions or still thinks this is an issue, please feel free to re-open the issue again.

[chinnabha]

Hi Jens,

As optee_os, optee_LinuxDriver and optee_client should always run on the same core, what is the need for having support for more than one core and manipulating them via affinities?

Is it possible to run optee_LinuxDriver on core M and optee_os on core N?

[jenswi-linaro]

optee_client is Linux user space and can run on any core supported by Linux, but the driver and optee_os has to run on the same core when doing the transition between worlds.

[chinnabha]

@Then what may be the use of supporting multiple cores for optee_os?

Let us say optee-os has booted for core 0 and core 1, and Driver affinity set to support core 0 and core 1. initially let me assume the driver and optee_os run on core 0. Since the Driver affinity is set to support two cores, what happens if my Linux scheduler moves the driver to core 1? This is a undesired situation Driver on core 1 and optee-os on core 0. How does we control this?

[jenswi-linaro]

As we're switching worlds via the smc instruction we can only switch world on the same core. So in order to control which cores enters secure world you need to control which cores does the smc in normal world.

On the other hand, why bother controlling which core is going to run in secure world? It makes the software more complicated and interferes with the Linux scheduler.

[chinnabha]

I didn't say I want to control the core on which secure world runs. My question was different:

Is it possible that the Linux scheduler can attempt to switch the core for driver to core 1 (originally it was on core 0, before it entered secure os) when my secure world is executing slow smccc code on core 0?

The above situation is not the one I want to control. Its the Linux scheduler which may try to attempt load balancing on core 0 and try to put the optee_LinuxDriver on core 1. I am assuming this situation is possible when the secure world is executing slow smccc code on core 0. If this situation is not possible, then there is nothing to bother.

[jenswi-linaro]

From normal point of view is each call to secure world like a function call. Fast calls will execute with IRQ masked while in secure world so no rescheduling possible until the call returns. Standard calls will unmask IRQ while in secure world so rescheduling is possible.

The way secure world is rescheduled is via an IRQ just as in normal world (see https://github.com/OP-TEE/optee_os/blob/master/documentation/interrupt_handling.md for interrupt delivery). To change core in secure world the first need to exit via IRQ delivery and then change core in normal world and reenter on a different core.

Normally you don't need to worry about which core is in secure world and there's no possibility for the driver to get out of sync with secure world in with regards to that.

[chinnabha]

Thanks so much Jens for assisting on this. This has clarified all my questions on core switching.

One last question please. On aarch64, ATF bl31 stage sets up the runtime exception handlers for S-EL1. So, if I initialize the GIC driver in ATF bl31, is there any need to reinitialize the GIC driver in optee-os? Can the bl31 runtime exception handlers forward the irqs from secure world to normal world , and as well deliver the FIQs to secure world when SCR.NS = 0?

I am confused because the various platforms in optee-os are making GIC driver initializations.