Julien Grall writes:
On 1/17/19 7:13 PM, Volodymyr Babchuk wrote:
Actually, OP-TEE protocol have possibility to handle limited number of threads correctly. OP-TEE can report that all threads are busy and client will wait for a free one. XEN can do the same, although this is not implemented in this patch series. But I can add this.
Could you expand by wait? Will it block in OP-TEE/Xen or does it return to the guest?
It returns to the guest with response code OPTEE_SMC_RETURN_ETHREAD_LIMIT. Linux driver blocks calling application thread until one of the calls to OP-TEE is finished. Then driver awakens one of the blocked threads, so it can perform the call.
Shouldn't not you return this value when you reach out MAX_STD_CALLS?
Yes, I should. As I said earlier, this isn't done right now. But apparently will be done in the next version.
Actually, looking at the code, you don't seem to return in error code when there are a failure in the mediator. Instead you seem to always return "false". Which means the virtual SMCCC framework thinks the call was never handled. However, this is not true, you handled the call but the there was a failure during it.
In general, handle_call should return false only if the call is non-existent. In all the other case, you should feed a proper return by yourself.
Agree. At first I seen OP-TEE mediator as relatively thin shim between guest and OP-TEE. And I expected that it should not return errors to a good behaving guest. But logic becomes more complex and indeed, there are cases when even behaving guest can get an error.