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?
The text you quoted is talking about different software models that are possible.
The pre-emption model requires the two worlds to co-operate. Interrupts are asynchronous, and you could get an interrupt belonging to Non-secure world while executing in the Secure world. The Secure would can choose to mask/ignore that interrupt, while still being able to process its own interrupts (Secure interrupts). That would give you blocking Secure world.
Alternatively, the Secure world could not mask the interrupts - or not mask all the interrupts (using the GIC's priority scheme). Then if/when a Non-secure interrupt arrives Secure software could use that as a trigger to yield back to Non-secure state.