Hi Jens and Stuart:
#define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM vs. UNRESITERED_SHM (1 << 1)
The topic of managing RichOS-and-TEE shared memory for *use case* scalability is of interest to Qualcomm as well. We might want to reserve "DYNAMIC_SHM" to mean that additional contiguous physical memory regions can be runtime registered / deregistered with Secure World, and the CA's can suballocate from these, just like they suballocate from the initial 1MB of carveout.
Meanwhile, the SMC_SEC_CAP_UNREGISTERED_SHM flag might be a better name to communicate the semantics that the Secure World, as a matter of policy, allows any NS memory to be mapped to TAs without restrictions.
That is to say, the semantics of SMC_CAP_DYNAMIC_REGISTER_SHM might better off set aside for future, when, post boot, some contiguous NS=1 regions can be added to the SHM pool, in order to lift the limitation of the initial 1MB SHM pool.
Granted it requires the addition of new SMC commands. That is why I chose the word, “future”.
Thoughts?
Thanks, -thomas
-----Original Message----- From: Tee-dev [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Jens Wiklander Sent: Monday, June 12, 2017 1:12 AM To: Stuart Yoder stuart.yoder@arm.com Cc: tee-dev@lists.linaro.org Subject: Re: [Tee-dev] comment about "unregistered" vs "register" shared memory
+tee-dev
On Mon, Jun 12, 2017 at 10:11 AM, Jens Wiklander jens.wiklander@linaro.org wrote:
Hi Stuart,
On Sat, Jun 10, 2017 at 12:12 AM, Stuart Yoder stuart.yoder@arm.com wrote:
+Volodymyr (correcting corrupted email address)
On 6/9/17 11:51 AM, Stuart Yoder wrote:
All,
I've been reviewing and trying out Volodymyr's patches related to dynamic shared memory.
One thing I found thoroughly confusing was that in the same capabilities list we use the word "register" in two completely different ways.
/* Secure world can communicate via previously unregistered shared memory */ #define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM (1 << 1) /* Secure world supporst commands "register/unregister shared memory" */ #define OPTEE_SMC_SEC_CAP_REGISTER_SHM (1 << 2)
As far as I can tell "unregistered shared memory" simply means "dynamic shared memory" vs a pre-allocated static region.
It would be much clearer if we tweaked the names:
/* Secure world can communicate via previously unregistered shared memory */ #define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM (1 << 1) /* Secure world supporst commands "register/unregister shared memory" */ #define OPTEE_SMC_SEC_CAP_CMD_REGISTER_SHM (1 << 2)
Are you open to that change?
I agree, what you're proposing is more clear. It's not an ABI change, only how it's documented. Since we already have OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM defined on the (optee_os) master branch we do the change there via a pull request.
If possible please create a pull request at github.
Thanks, Jens
_______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev