From: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
To: Julien Grall <julien.grall@arm.com>
Cc: Volodymyr Babchuk <vlad.babchuk@gmail.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Stefano Stabellini <sstabellini@kernel.org>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
"tee-dev@lists.linaro.org" <tee-dev@lists.linaro.org>
Subject: Re: [PATCH v3 06/11] optee: add std call handling
Date: Thu, 17 Jan 2019 20:14:08 +0000 [thread overview]
Message-ID: <87o98ft52o.fsf@epam.com> (raw)
In-Reply-To: <5833586a-615d-ed88-5d2f-96e4b0c8c56f@arm.com>
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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-01-17 20:14 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-18 21:11 [PATCH v3 00/11] TEE mediator (and OP-TEE) support in XEN Volodymyr Babchuk
2018-12-18 21:11 ` [PATCH v3 01/11] arm: add generic TEE mediator framework Volodymyr Babchuk
2019-01-15 17:50 ` Julien Grall
2018-12-18 21:11 ` [PATCH v3 03/11] arm: tee: add OP-TEE header files Volodymyr Babchuk
2018-12-18 21:11 ` [PATCH v3 02/11] arm: add tee_enabled flag to xen_arch_domainconfig Volodymyr Babchuk
2019-01-15 17:35 ` Julien Grall
2019-01-16 17:22 ` Volodymyr Babchuk
2019-01-16 17:27 ` Julien Grall
2018-12-18 21:11 ` [PATCH v3 04/11] optee: add OP-TEE mediator skeleton Volodymyr Babchuk
2019-01-15 18:15 ` Julien Grall
2019-01-16 17:31 ` Volodymyr Babchuk
2019-01-16 17:51 ` Julien Grall
2018-12-18 21:11 ` [PATCH v3 05/11] optee: add fast calls handling Volodymyr Babchuk
2019-01-17 18:31 ` Julien Grall
2019-01-17 19:22 ` Volodymyr Babchuk
2019-01-17 20:02 ` Julien Grall
2019-01-17 20:10 ` Volodymyr Babchuk
2019-01-18 15:29 ` Julien Grall
2018-12-18 21:11 ` [PATCH v3 06/11] optee: add std call handling Volodymyr Babchuk
2019-01-16 18:45 ` Julien Grall
2019-01-17 15:21 ` Volodymyr Babchuk
2019-01-17 18:18 ` Julien Grall
2019-01-17 19:13 ` Volodymyr Babchuk
2019-01-17 20:00 ` Julien Grall
2019-01-17 20:14 ` Volodymyr Babchuk [this message]
2018-12-18 21:11 ` [PATCH v3 07/11] optee: add support for RPC SHM buffers Volodymyr Babchuk
2019-01-17 18:49 ` Julien Grall
2019-01-17 19:48 ` Volodymyr Babchuk
2019-01-17 20:08 ` Julien Grall
2019-01-17 21:01 ` Volodymyr Babchuk
2019-01-18 15:38 ` Julien Grall
2019-01-18 16:05 ` Volodymyr Babchuk
2019-01-18 17:51 ` Julien Grall
2019-01-18 18:29 ` Volodymyr Babchuk
2018-12-18 21:11 ` [PATCH v3 08/11] optee: add support for arbitrary shared memory Volodymyr Babchuk
2019-01-21 11:42 ` Julien Grall
2019-02-19 15:59 ` Volodymyr Babchuk
2019-02-20 13:26 ` Julien Grall
2018-12-18 21:11 ` [PATCH v3 09/11] optee: add support for RPC commands Volodymyr Babchuk
2019-01-21 11:58 ` Julien Grall
2019-02-19 16:14 ` Volodymyr Babchuk
2019-02-20 13:46 ` Julien Grall
2018-12-18 21:11 ` [PATCH v3 11/11] libxl: arm: create optee firmware node in DT if tee=1 Volodymyr Babchuk
2019-01-21 12:10 ` Julien Grall
2018-12-18 21:11 ` [PATCH v3 10/11] xl: add "tee" option for xl.cfg Volodymyr Babchuk
2019-01-21 12:08 ` Julien Grall
2018-12-19 13:25 ` [PATCH v3 00/11] TEE mediator (and OP-TEE) support in XEN Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o98ft52o.fsf@epam.com \
--to=volodymyr_babchuk@epam.com \
--cc=julien.grall@arm.com \
--cc=sstabellini@kernel.org \
--cc=tee-dev@lists.linaro.org \
--cc=vlad.babchuk@gmail.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).