Re: [Xen-devel] [PATCH v4 06/10] xen/arm: optee: add support for RPC SHM buffers

[Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>]

Julien Grall writes:

Hi Julien,

> Hi Volodymyr,
>
> On 07/03/2019 21:04, Volodymyr Babchuk wrote:
>> From: Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>
>>
>> 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 domain can't
>> transfer it to someone else.
>
> At the moment, Xen on Arm doesn't support transfer of a page between
> domain (see steal_page). What we want to prevent here is the domain to
> free the page (via XENMEM_decrease_reservation). If the reference drop
> to 0, the page will be freed and could potentially be allocated for
> Xen usage or another domain. Taking the reference here, will prevent
> it to free until the reference is dropped.
>
> So I would reword this sentence. Something like:
>
> "Mediator needs to pin the buffer to make sure the page will not be
> freed while it is shared with OP-TEE".
When I wrote that, I kept in mind grant mappings as well. But, I
think, I was mistaken there, because grant mappings will have p2m type
p2m_grant_map_rw/p2m_grant_map_ro. So yeah, your variant is better. Thanks.

[...]

>> concurrent standard calls, because this can impair functionality of
>> OP-TEE.
>
> Could you add a similar comment on top of call_count?
Sure, will do.

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