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

[Xen-devel] [optee ]: about the max optee threads limitation

  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Liu Ge/刘戈 <ge.liu@xxxxxxxxxxxx>
  • Date: Tue, 20 Aug 2019 10:12:28 +0000
  • Accept-language: zh-CN, en-US
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=ge.liu@xxxxxxxxxxxx;
  • Delivery-date: Tue, 20 Aug 2019 10:20:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AdVXPXlc5alEi1p3Ql+0A9IfmKKKvwAAhFZw
  • Thread-topic: [optee ]: about the max optee threads limitation






I am reading the code about the optee supported by xen.


I noticed following code which about the limitation of the max optee threads.

Is the limitation should be applied to all of the guest VMs running on Xen ?

if it is yes, however, ctx is per VM, so, if there is another VM enable the optee , the limitation may exceed the number of max optee threads.

Is it right?


File: xen/arch/arm/tee/optee.c

static struct optee_std_call *allocate_std_call(struct optee_domain *ctx)


    struct optee_std_call *call;

    int count;



     * Make sure that guest does not execute more than max_optee_threads.

     * This also indirectly limits number of RPC SHM buffers, because OP-TEE

     * allocates one such buffer per standard call.


    count = atomic_add_unless(&ctx->call_count, 1, max_optee_threads);

    if ( count == max_optee_threads )

        return ERR_PTR(-ENOSPC);

Xen-devel mailing list



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