xen/arm: optee: add support for RPC SHM buffers
authorVolodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Tue, 11 Jun 2019 18:46:36 +0000 (18:46 +0000)
committerJulien Grall <julien.grall@arm.com>
Wed, 19 Jun 2019 11:05:04 +0000 (12:05 +0100)
commitc75aca65528c0bc8f70da718ed9d25e247718849
tree725ed9cefb37705eb687131d7c318dfbe7ab2888
parentc688a8afb2649d955139e7d0d2a86a75fe93fa7e
xen/arm: optee: add support for RPC SHM buffers

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>
xen/arch/arm/tee/optee.c