[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [RFC 4/4] arm: tee: add basic OP-TEE mediator
Hi,
On 19/10/17 17:37, Volodymyr Babchuk wrote:
On Thu, Oct 19, 2017 at 05:12:17PM +0100, Julien Grall wrote:
Hi Julien,
+ if ( rc < 0 )
+ {
+ gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc);
gprintk already dump the domid. So no need to say Dom0.
I just wanted to emphasis that we mappaed memory for Dom0. Will remove.
gprintk will printk d0. So there are no point to say it a second time...
+ set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL);
+ }
+
+ return true;
+}
+
+static bool handle_exchange_capabilities(struct cpu_user_regs *regs)
+{
+ forward_call(regs);
+
+ printk("handle_exchange_capabilities\n");
Same here, no plain prink.
Sorry, this is another debug print. Missed it when formatted patches.
+ /* Return error back to the guest */
+ if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK)
+ return true;
+
+ /* Don't allow guests to work without dynamic SHM */
Hmmm? But you don't support guests today. So why are you checking that?
This is a RFC. Will remove this parts of the code in a proper patch series.
I just wanted to ensure that community is okay with proposed approach and
to show how minimalistic mediator can look.
I don't think this is true. You only show how easy it is to let Dom0
accessing TEE. And as I said in the cover letter, this is not the
controversial part.
Actually I wanted to show approach when mediator resides right in xen.
I got valuable input from you. Now I see that I must completely rework the
first patch. And, probably, show more comprehensive support from OP-TEE side.
The more controversial one is the guest support that you completely left
aside. I believe this part will not be as minimalistic as you think because
you need to translate buffer address and prevent those buffers to disappear
under your feet.
Yes. I plan to copy all buffers where IPAs presented to another place,
so DomU will not be able to see PAs during translation. And I plan to
pin all DomU pages with a data. Also I'll read from guest pages only
once. I think, this will be enough.
There are probably other problem to fix...
Probably yes...
I think, I'll focus on OP-TEE side right now and come back when there will
be more more to show.
To clarify my view. I am not against a temporary support of OP-TEE for the
hardware domain in Xen. But it does not mean I would be ready to see the a
full OP-TEE support for guests in Xen.
Hm. What did you mean in last sentence? Our (here, at EPAM) target is full
virtualization support for OP-TEE. If you don't want to see it in Xen,
then what another ways we have?
Sorry it was not clear enough. I meant that whilst I am happy to see OP-TEE
support for the hardware domain in the hypervisor, we still need to discuss
on the approach for guests.
Excuse me, I still didn't get it. You imply that we need some
completely different approach for guests? Or I can stick with current
approach, just add more restrictions?
Under "current approach" I mostly mean "handle SMCs to TEE at EL2" as
opposed to "handle them in stubdom". Half patches of this RFC should
be severely reworked anyways.
Let me answer on your cover letter. That would be easier to draw a
decision with your last e-mail.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
