Hi,
Please only CC relevant people to the patches. This could be done easily
using the new script add_maintainers.pl.
On 22/08/18 15:11, Volodymyr Babchuk wrote:
Add OP-TEE mediator, so guests can access OP-TEE services.
OP-TEE mediator support address translation for DomUs.
It tracks execution of STD calls, correctly handles memory-related RPC
requests, tracks buffer allocated for RPCs.
With this patch OP-TEE sucessfully passes own tests, while client is
running in DomU.
Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com>
---
Changes from "RFC":
- Removed special case for Dom0/HwDOM
- No more support for plain OP-TEE (only OP-TEE with virtualization
config enabled is supported)
- Multiple domains is now supported
- Pages that are shared between OP-TEE and domain are now pinned
- Renamed CONFIG_ARM_OPTEE to CONFIG_OPTEE
- Command buffers from domain are now shadowed by XEN
- Mediator now filters out unknown capabilities and requests
- call contexts, shared memory object now stored per-domain
xen/arch/arm/tee/Kconfig | 4 +
xen/arch/arm/tee/Makefile | 1 +
xen/arch/arm/tee/optee.c | 972 ++++++++++++++++++++++++++++++++++++
This patch is far to big to get a proper review with understanding of
the code. Can you split it in smaller ones with appropriate commit message?
From a quick look at it, I would like to understand how the memory
allocated in Xen is bounded for a given guest? Same question for the time.
I am interested in a normal case but also in the case where someone
malicious is using that API. How much damage can it do to the hypervisor?
I will give a proper look when it is split.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel