Hi Julien,
On 7 December 2017 at 00:33, Julien Grall julien.grall@arm.com wrote:
Hi Volodymyr,
I am not an OP-TEE expert, thought I have one comment below on how Xen works.
If guest suddenly dies, we can't cleanup resources (consider mutex that will be never unlocked). Instead we can just drop whole guest context and forged about it. But we will need special cleanup code for kernel state, though. This is a reason to keep kernel data footprint as small as possible.
I don't think the mutex example is correct. When there are a sudden guest crash (e.g when the guest badly behave), Xen will notify all the guest vCPUs by raising a softirq. This will raise a SGI target the pCPU where the vCPU is running.
So the vCPU will finish what he is doing (such as handling an hypercall or SMC) and will get unscheduled before returning to EL1/EL0.
Yes, this is not a problem. If pCPU is busy in Secure World, OP-TEE will let it out only when it is relatively safe. E.g. it will not issue RPC return to handle SGI during an atomic operation. But it can issue RPC return while holding a mutex. Or, it is possible, that one of OP-TEE threads is already locked on a mutex and it is waiting its turn in Normal World, sleeping on completion in linux optee driver.
Do you expect the mutex to stay locked accross SMC call?
Yes, this is the case. As I said in xen-devel discussion, OP-TEE is scheduled by Normal World. So, when OP-TEE thread gets blocked on a mutex, it issues RPC to exit to Normal World. When mutex owner unlocks it, it also issues RPC to unblock the first thread, so it can return back into Secure World.
But, as OP-TEE uses mutexes only in STD calls, it is possible to have a mutex instance per-guest. So, when guest dies, OP-TEE can just forget about all guest threads, mutexes and other state.