TrustZone preemption

When the processor is running in the Secure World, it generally remains in control until it voluntarily switches back to the Non-Secure World. This process is typically triggered by an explicit Secure Monitor Call (SMC) from the Non-Secure World or a return from a Secure operation. In this setup, the Secure World is non-preemptive because it decides when to give up control.

I've came across this on `TrustZone for Armv8-A`

In a TrustZone system there are two software stacks, one for Non-secure state and another for Secure state. A processor core can only be in one state at a time. Who decides when each world is allowed to run? Explicit calls to the EL3 firmware, like power management requests using Power State Coordination Interface (PSCI), are typically blocking. This means that control will only be returned to Non-secure state when the requested operation is complete. However, these calls tend to be short and infrequent. The TEE typically runs under the control of the Non-secure state OS scheduler. A possible design is to have a daemon running under the OS as a place holder for the TEE. When the daemon is scheduled by the OS, the daemon hands control to the TEE through an SMC. The TEE then runs, processing outstanding requests, until the next scheduler tick or interrupt. Then control returns to the Non-secure state OS.

I am trying to understand how come that on one hand ARM's TZ is non-preemptive, while on the other hand, there's an option to run TEE from a userspace's daemon, and somehow get TZ preempted?