Re: [PATCH v5 06/10] xen/arm: optee: add support for RPC SHM buffers

[Julien Grall <julien.grall@arm.com>]

Hi Volodymyr,

On 21/05/2019 22:26, Volodymyr Babchuk wrote:
> OP-TEE usually uses the same idea with command buffers (see
> previous commit) to issue RPC requests. Problem is that initially
> it has no buffer, where it can write request. So the first RPC
> request it makes is special: it requests NW to allocate shared
> buffer for other RPC requests. Usually this buffer is allocated
> only once for every OP-TEE thread and it remains allocated all
> the time until guest shuts down. Guest can ask OP-TEE to disable
> RPC buffers caching, in this case OP-TEE will ask guest to
> allocate/free buffer for the each RPC.
> 
> Mediator needs to pin this buffer to make sure that page will be
> not free while it is shared with OP-TEE.
> 
> Life cycle of this buffer is controlled by OP-TEE. It asks guest to
> create buffer and it asks it to free it. So it there is not much sense
> to limit number of those buffers, because we already limit the number
> of concurrent standard calls and prevention of RPC buffer allocation will
> impair OP-TEE functionality.
> 
> Those buffers can be freed in two ways: either OP-TEE issues
> OPTEE_SMC_RPC_FUNC_FREE RPC request or guest tries to disable
> buffer caching by calling OPTEE_SMC_DISABLE_SHM_CACHE function.
> In the latter case OP-TEE will return cookie of the SHM buffer it
> just freed.
> 
> OP-TEE expects that this RPC buffer have size of
> OPTEE_MSG_NONCONTIG_PAGE_SIZE, which equals to 4096 and is aligned
> with the same size. So, basically it expects one 4k page from the
> guest. This is the same as Xen's PAGE_SIZE.
> 
> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>

Acked-by: Julien Grall <julien.grall@arm.com>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel