Re: [Xen-devel] [PATCH v3 06/11] optee: add std call handling

[Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>]

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.

-- 
Best regards,Volodymyr Babchuk
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel