[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC] WIP: optee: add OP-TEE mediator


Answering to myself.

On 12/04/2017 02:30 PM, Julien Grall wrote:
On 01/12/17 22:58, Stefano Stabellini wrote:
On Mon, 27 Nov 2017, Volodymyr Babchuk wrote:
= Xen command forwarding =

In the code below, it looks like Xen is forwarding everything to OP-TEE.
Are there some commands Xen should avoid forwarding? Should we have a
whitelist or a blacklist?

= Long running OP-TEE commands and interruptions =

I have been told that some OP-TEE RPC commands might take long to
complete. Is that right? Like for example one of the

If so, we need to think what to do in those cases. Specifically, do we
need a technique to restart certain commands in Xen, so that when they
run for too long and get interrupted by something (such as an
interrupt) we know how to restart them? In fact, do we need to setup a
timer interrupt to make sure the command doesn't block Xen for too long,
consuming the next vcpu's slot as well?

I am not sure to understand your suggestion here. Where do you want that timer? In Xen? If so, I don't think this could work. That's OP-TEE job to break down long running operation.

This is very similar to when a guest is doing an hypercall. Even if setup a timer, the interrupt will only be received once the hypercall is done (or Xen decided to preempt it).

So from Stuart's e-mail, I was slightly wrong about this. Most of the time a timer interrupt would get OP-TEE stopping his work and then return to the hypervisor. Although, this is still at the will of OP-TEE :).

The scheduler is already setting a timer interrupt to prevent a guest running outside of its slice. So I think this would do the job here to preempt OP-TEE.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.