Julien Grall writes: Hi Julien,
> Hi Volodymyr, > > On 07/03/2019 21:04, Volodymyr Babchuk wrote: >> From: Volodymyr Babchuk <vlad.babc...@gmail.com> >> >> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel