From: Julien Grall <julien.grall@linaro.org>
To: Stefano Stabellini <sstabellini@kernel.org>,
Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Cc: Julien Grall <julien.grall@arm.com>, nd@arm.com, xen-devel@lists.xen.org
Subject: Re: [RFC 0/4] TEE mediator framework + OP-TEE mediator
Date: Fri, 27 Oct 2017 14:47:18 +0100 [thread overview]
Message-ID: <fe7aaff0-1060-8ee8-2d0c-1d5542a59105@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.10.1710241354320.574@sstabellini-ThinkPad-X260>
Hi,
Just answering to dom0 been 1:1 domain.
On 24/10/17 22:33, Stefano Stabellini wrote:
> On Tue, 24 Oct 2017, Volodymyr Babchuk wrote:
>>> For this series, I think we need a way to specify which domains can talk
>>> to TEE, so that we can only allow it for a specific subset of DomUs. I
>>> would probably use XSM for that.
>> I am afraid, this is not possible. As other domains aren't 1:1 mapped,
>> I need to have special translation code in mediator. Actually, I'm
>> writing it rigth now to test my changes in OP-TEE. But event this is
>> not enought for decent OP-TEE support.
>> What can be done right now: 100% Dom0-only support with vanilla
>> OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is
>> even simplier task, so I can throw out some code from this patch
>> series. On other hand, in the future this will lead to sutiation when
>> two mediators for the same TEE shall be supported: one, simple, in
>> XEN, another, fully-functional in stubdom.
>
> I think it is fine to support OP-TEE only in Dom0 to begin with.
>
> Ideally, it would be in Dom0 for convenience and speed and the OP-TEE
> capability would be specified as an XSM label. Ideally, it would not be
> only in Dom0 because it is tied to the 1:1 map, but I understand now
> that it is a requirement. I still think that the XSM label would be good
> to have even if today it cannot be changed as only Dom0 is 1:1.
I thought a bit more about Dom0 been a 1:1 domain. It is only true for
Device Memory and the initial RAM allocated for Dom0.
Dom0 may balloon out some pages because it has to map region belonging
to other domain. Those regions will not be 1:1 mapped and translation
will be needed if used.
The problem is very similar to DMA in dom0. I can't see any reason to
not use those regions with OP-TEE. Am I wrong here?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-10-27 13:47 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 19:01 [RFC 0/4] TEE mediator framework + OP-TEE mediator Volodymyr Babchuk
2017-10-11 19:01 ` [RFC 1/4] arm: add SMC wrapper that is compatible with SMCCC Volodymyr Babchuk
2017-10-16 14:53 ` Julien Grall
2017-10-11 19:01 ` [RFC 2/4] arm: add generic TEE mediator framework Volodymyr Babchuk
2017-10-16 13:00 ` Julien Grall
2017-10-17 16:22 ` Volodymyr Babchuk
2017-10-17 16:39 ` Julien Grall
2017-10-17 17:22 ` Volodymyr Babchuk
2017-10-17 17:35 ` Julien Grall
2017-10-11 19:01 ` [RFC 3/4] arm: tee: add OP-TEE header files Volodymyr Babchuk
2017-10-16 14:04 ` Julien Grall
2017-10-17 16:24 ` Volodymyr Babchuk
2017-10-17 16:41 ` Julien Grall
2017-10-11 19:01 ` [RFC 4/4] arm: tee: add basic OP-TEE mediator Volodymyr Babchuk
2017-10-16 14:36 ` Julien Grall
2017-10-17 17:08 ` Volodymyr Babchuk
2017-10-17 17:30 ` Julien Grall
2017-10-17 18:57 ` Volodymyr Babchuk
2017-10-19 14:01 ` Julien Grall
2017-10-19 15:33 ` Volodymyr Babchuk
2017-10-19 16:12 ` Julien Grall
2017-10-19 16:37 ` Volodymyr Babchuk
2017-10-19 16:52 ` Julien Grall
2017-10-16 12:00 ` [RFC 0/4] TEE mediator framework + " Julien Grall
2017-10-17 15:59 ` Volodymyr Babchuk
2017-10-20 13:11 ` Julien Grall
2017-10-20 16:57 ` Tamas K Lengyel
2017-10-20 17:46 ` Volodymyr Babchuk
2017-10-20 17:37 ` Volodymyr Babchuk
2017-10-23 16:59 ` Julien Grall
2017-10-23 20:11 ` Volodymyr Babchuk
2017-10-23 21:26 ` Stefano Stabellini
2017-10-24 16:33 ` Volodymyr Babchuk
2017-10-24 21:33 ` Stefano Stabellini
2017-10-27 13:47 ` Julien Grall [this message]
2017-10-27 19:59 ` Stefano Stabellini
2017-10-27 20:06 ` Julien Grall
2017-10-24 17:33 ` Julien Grall
2017-10-24 19:02 ` Volodymyr Babchuk
2017-11-02 13:17 ` Julien Grall
2017-11-02 16:53 ` Volodymyr Babchuk
2017-11-02 17:49 ` Julien Grall
2017-11-02 20:07 ` Volodymyr Babchuk
2017-11-07 16:03 ` Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fe7aaff0-1060-8ee8-2d0c-1d5542a59105@linaro.org \
--to=julien.grall@linaro.org \
--cc=julien.grall@arm.com \
--cc=nd@arm.com \
--cc=sstabellini@kernel.org \
--cc=volodymyr_babchuk@epam.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).