Enable dynamic SHM support #1631

lorc · 2017-06-22T15:07:56Z

Hello.

There are last patches for dynamic SHM.

I'm not sure, if I did right thing, when created two patches with ABI changes, because 4e5d00d ("ABI change: add shared memory support") enables new capability and 30260ae ("ABI change: enable TMEM parameters with non-contiguous shm") extends it.

Probably I should squash those two patches into one, or create one additional patch for entry_fast.c, that enables OPTEE_SMC_SEC_CAP_DYNAMIC_SHM. What do you think?

stuyoder · 2017-06-28T14:11:13Z

core/arch/arm/include/sm/optee_smc.h

@@ -290,6 +290,12 @@
 #define OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM	(1 << 0)
 /* Secure world can communicate via previously unregistered shared memory */
 #define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM	(1 << 1)
+/*


Based on the mailing list discussion, we don't need both OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM and OPTEE_SMC_SEC_CAP_DYNAMIC_SHM, right?

Jens had proposed changing the existing "UNREGISTERED_SHM" capability to this:

/*

Secure world supports shared memory objects to represent

physically non-contiguous memory and the commands

"register/unregister shared memory object" for more efficient

communication via physically non-contiguous memory.
*/
#define OPTEE_SMC_SEC_CAP_NONCONTIG_SHM (1 << 1)

Hi, @stuyoder. I did exactly this. I decided not to touch existing OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM. Instead I added new OPTEE_SMC_SEC_CAP_DYNAMIC_SHM. I think, that this name better describes this capability.

Actually the UNREGISTERED_SHM relates the the so-called default shm (NSEC_SHM in the core). This shm is "negotiated" at core inits with nsec world (some SMCs allow to get/set the nsec_shm location, but core_mmu.c expects it from static config CFG_SHMEM_START/_SIZE). It happens to be physically contiguous and as a single memory chunk. That's its real attributes.

@etienne-lms, What do you mean with respect to "negotiated"? UNREGISTERED_SHM is unused as of now in both OP-TEE and Linux.

This is how the capabilities are defined today:

/* Secure world has reserved shared memory for normal world to use /
#define OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM (1 << 0)
/ Secure world can communicate via previously unregistered shared memory */
#define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM (1 << 1)

It is HAVE_RESERVED_SHM that is referring to the physically contiguous static CFG_SHMEM_START/SIZE.

The question is what capabilities we need to refer to the new ability for OP-TEE to map arbitrary, non-contiguous physical addresses.

Do we need:
A). One capability that refers to the capability of OP-TEE to handle non-contiguous shared memory and the capability to handle the register/unregister core APIs?
or
B) . Two capabilities-- 1) one for the capability of OP-TEE to handle non-contiguous shared memory, and 2) one for the capability to handle the register/unregister core APIs.

Jens proposal on the mailing list was for option #A.

@lorc, what do the capabilities OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM and OPTEE_SMC_SEC_CAP_DYNAMIC_SHM mean in your view? How are they different?

As I stated above, the first question is whether we need one capability or two capabilities. Once that is decided, we can decide what the best name is.

I'd prefer only on capability as those two are so intertwined.

@stuyoder, I'm not using OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM at all. I have leaved it as is. I use only OPTEE_SMC_SEC_CAP_DYNAMIC_SHM in my patch series.
I decided not to rename OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM to OPTEE_SMC_SEC_CAP_DYNAMIC_SHM because that can add some confusion.
At this moment there are at least 30 free bits for capability flags, so I don't see why we need to reuse existing values.

prime-zeng · 2017-06-29T02:15:08Z

@lorc Do you have any plan to support user TA mapping for the dynamic SHM?

jenswi-linaro

Sorry I seem to have missed this. Here's my comments and then there's the comment by @stuyoder also.

jenswi-linaro · 2017-06-29T09:20:15Z

core/arch/arm/kernel/thread.c

+		*cookie = arg->params[0].u.tmem.shm_ref;
+		mobj = mobj_shm_alloc(arg->params[0].u.tmem.buf_ptr,
+				      arg->params[0].u.tmem.size);
+	} else if (arg->params[0].attr ==


I would have formatted these two lines as:

} else if (arg->params[0].attr == (OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT | OPTEE_MSG_ATTR_NONCONTIG)) {

but that's a matter of taste.

jenswi-linaro · 2017-06-29T09:56:17Z

core/arch/arm/mm/core_mmu.c

@@ -1052,6 +1052,9 @@ static void set_pg_region(struct core_mmu_table_info *dir_info,

 		r.size = MIN(CORE_MMU_PGDIR_SIZE - (r.va - pg_info->va_base),
 			     end - r.va);
+		r.size = MIN(r.size, mobj_get_phys_granule(region->mobj));


These two lines are not relevant for a paged mobj so they should be moved into the if below.

jenswi-linaro · 2017-06-29T10:01:54Z

core/arch/arm/tee/entry_std.c

@@ -94,8 +114,26 @@ static TEE_Result assign_mobj_to_param_mem(const paddr_t pa, const size_t sz,
 	return TEE_ERROR_BAD_PARAMETERS;
 }

+static TEE_Result set_rmem_param(const struct optee_msg_param *param,
+			  struct param_mem *mem)


Align with ( on the line above.

jenswi-linaro · 2017-06-29T10:14:04Z

core/arch/arm/tee/entry_std.c

 static TEE_Result copy_in_params(const struct optee_msg_param *params,
-		uint32_t num_params, struct tee_ta_param *ta_param)
+			 uint32_t num_params, struct tee_ta_param *ta_param,


Align with ( on the line above.

jenswi-linaro · 2017-06-29T10:52:24Z

core/arch/arm/tee/entry_std.c

+			mobj_free(mobj);
+			arg->ret = TEE_SUCCESS;
+		} else {
+			EMSG("Can't find mapping with given cookie\n");


\n not needed.

lorc · 2017-06-30T20:01:51Z

Addressed comments.

@prime-zeng, I'm sorry. I didn't get what are you asking.
User TAs can use memory that was registered by CA, if this is what you asked.

etienne-lms

i need to review this again, seems but still unclear to me.

etienne-lms · 2017-06-22T19:00:40Z

core/arch/arm/include/sm/optee_smc.h

@@ -290,6 +290,12 @@
 #define OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM	(1 << 0)
 /* 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",


typo /supporst/supports/
add empty line before comment.

etienne-lms · 2017-06-22T19:34:37Z

core/arch/arm/tee/entry_fast.c

+		IMSG("NS DDR configured. Enabling dynamic SHM");
+		args->a1 |= OPTEE_SMC_SEC_CAP_DYNAMIC_SHM;
+	} else {
+		EMSG("No NS DDR configured for the platform. Disabling dynamic SHM");


coudl you log on info level, it is not a error.

etienne-lms · 2017-06-22T19:46:54Z

core/arch/arm/include/sm/optee_smc.h

@@ -290,6 +290,12 @@
 #define OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM	(1 << 0)
 /* 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",
+ * secure world accepts command buffers located in any parts of unsecure RAM


s/unsecure/non secure/

etienne-lms · 2017-06-22T19:49:09Z

core/arch/arm/tee/entry_std.c

+			return;
+		}
+		mobj = map_cmd_buffer(parg, &num_params);
+	}


get_cmd_buffer() could handle both case. It would make tee_entry_std() more readable.

I prefer to leave it in current state. get_cmd_buffer() is responsible for buffers in MEM_AREA_NSEC_SHM which is already mapped in OP-TEE address space. map_cmd_buffer() maps buffers from MEM_AREA_RAM_NSEC. One task for one function.

As alternative I can create a third function that will choose to call get_cmd_buffer() or map_cmd_buffer().

etienne-lms · 2017-06-30T23:51:31Z

core/arch/arm/include/sm/optee_smc.h

@@ -290,6 +290,12 @@
 #define OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM	(1 << 0)
 /* Secure world can communicate via previously unregistered shared memory */
 #define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM	(1 << 1)
+/*


Actually the UNREGISTERED_SHM relates the the so-called default shm (NSEC_SHM in the core). This shm is "negotiated" at core inits with nsec world (some SMCs allow to get/set the nsec_shm location, but core_mmu.c expects it from static config CFG_SHMEM_START/_SIZE). It happens to be physically contiguous and as a single memory chunk. That's its real attributes.

etienne-lms · 2017-06-30T23:55:14Z

core/arch/arm/tee/entry_std.c

+		return TEE_SUCCESS;
+	}
+
+	/* Non-contigous buffer from non sec DDR? */


apology: could you add a space before the ? for consistency with below. (which could be rephrased some day).

No space before ? in English...

So we'll clean the other comments.

I added separate patch that does this.

etienne-lms · 2017-06-30T23:55:38Z

core/arch/arm/tee/entry_std.c

+							  false);
+		if (!mem->mobj)
+			return TEE_ERROR_BAD_PARAMETERS;
+		mem->offs = (pa & SMALL_PAGE_MASK);


minor: useless parenthesis.

etienne-lms · 2017-07-01T00:11:38Z

@lorc Do you have any plan to support user TA mapping for the dynamic SHM?

@prime-zeng, I'm sorry. I didn't get what are you asking.
User TAs can use memory that was registered by CA, if this is what you asked.

I agree with @lorc. Since his work on the shm, the memref parameters of TA invocations are now handled through memory object mobj. These abstract to underlying memory when one operates on the referred memory (identification, mapping, address conversion, ...). The current implementation of the mapping of user TA memref parameters should be able to map the new mobj_reg_shm reference (registered, not physically contiguous) as well as the currently used mobj_shm reference (from the NSEC_SHM). Yet, let's see the tests, but it should get functional.

etienne-lms · 2017-07-02T10:08:21Z

core/arch/arm/tee/entry_std.c

 			return TEE_ERROR_BAD_PARAMETERS;
-		if (params[n].attr & OPTEE_MSG_ATTR_NONCONTIG)
-			return TEE_ERROR_BAD_PARAMETERS;


I think we should reject noncontig attributes.
Non-contig reference are used only from register_[un]shm() std entries to register a reference related to the parameter type OPTEE_MSG_ATTR_RMEM_*.
Current function copy_in_params() is called from open/close_session() and and invoke_command(). It does not expect non-contig references, only value (with.. value), tmem (with its phys addr) and rmem (with its registered ref) types.

You mean we should disable noncontig bufs as parameters to TA unless it's via already registered buffers? Why?
I think it could be useful for one-shot invokes etc.

I think it could be useful for one-shot invokes etc.

You are right. It could be used.
So it would be allowed only for OPTEE_MSG_ATTR_TMEM_* types, as used in assign_mobj_to_param_mem().

But TEE Client API expects client to either use TEEC_AllocateSharedMemory() or TEE_RegisterSharedMemory(), do we really need to support here un-registered shm references ?

There's the TEEC_MEMREF_TEMP_* also.

prime-zeng · 2017-07-03T07:03:55Z

@etienne-lms @lorc I mean to ask whether the User TAs can use the registered (not physically contiguous )memory. And i see the final User TAs mapping are created in the function set_pg_region ,but i think this functions can't deal with non-contiguous memory. Do i miss something?

etienne-lms · 2017-07-03T07:42:53Z

set_pg_region() ,but i think this functions can't deal with non-contiguous memory. Do i miss something?

As of current implementation, yes, the function set_pg_region() may not fully handle the non-contiguous references. But it is already based on a loop that maps page per page and relies on mobj_get_pa() to retrieve each page physical address. So I think it is a matter of debugging to insure non-contiguous memory references are properly handled, if not already supported.

prime-zeng · 2017-07-04T02:23:39Z

@etienne-lms i got it, thank you, so i think maybe the problem now is how to fix the set_pg_region() to support non-contiguous memory, and this is another issue.

lorc · 2017-07-04T21:15:45Z

@prime-zeng , actually, one of the changes makes set_pg_region() (at [1]) to support non-contiguous memory. I especially tested this case.

@etienne-lms, I have addressed your comments.

[1] https://github.com/OP-TEE/optee_os/pull/1631/files#diff-21c5a372f38c092a429fd2b7e8f71ef3R1060

jenswi-linaro · 2017-07-06T08:47:27Z

I'd like to run some tests with this, which driver and client branch did you use?
Also we need to be happy about especially the driver changes before we commit to this new ABI.

lorc · 2017-07-06T13:54:57Z

Hi @jenswi-linaro, you will need kernel patches from this PR: linaro-swg/linux#29
And client library patches from this PR: OP-TEE/optee_client#72

jenswi-linaro · 2017-08-22T12:56:58Z

This works very well. The ABI provided to normal world is flexible enough to handle all use cases and I'm pretty sure it will survive a review on the kernel mailing lists without incompatible changes.

I'd like to wrap this up and merge it as soon as possible. We should do the same for linaro-swg/linux#29 and OP-TEE/optee_client#72. When it comes to upstreaming the kernel changes I'd be grateful I you posted the patches @lorc, in order to drive the process on the kernel mailing lists.

etienne-lms

Some late minor comments.
Looks ok to me: Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>

etienne-lms · 2017-08-22T13:00:06Z

core/arch/arm/tee/entry_fast.c

@@ -103,6 +103,13 @@ static void tee_entry_exchange_capabilities(struct thread_smc_args *args)

 	args->a0 = OPTEE_SMC_RETURN_OK;
 	args->a1 = OPTEE_SMC_SEC_CAP_HAVE_RESERVED_SHM;
+
+	if (core_mmu_nsec_ddr_is_defined()) {
+		IMSG("NS DDR configured. Enabling dynamic SHM");


minor: s/configured/defined/. This code does not really configure anything.
Same below.

etienne-lms · 2017-08-22T13:02:48Z

core/arch/arm/tee/entry_std.c

+		return TEE_SUCCESS;
+	}
+
+	/* belongs to nonsecure shared memory? */


minor: s/belongs/Belongs/

etienne-lms · 2017-08-22T13:03:00Z

core/arch/arm/tee/entry_std.c

 	if (param_mem_from_mobj(mem, shm_mobj, pa, sz))
 		return TEE_SUCCESS;

 #ifdef CFG_SECURE_DATA_PATH
-	/* belongs to SDP memories ? */
+	/* belongs to SDP memories? */


minor: s/belongs/Belongs/

jenswi-linaro · 2017-08-22T14:48:00Z

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

jforissier · 2017-08-31T09:19:46Z

@lorc could you please squash/rebase the patches and apply the Reviewed-by: tags?

Can this safely be merged without the linux and optee_client patches? I'm concerned by the "ABI change:" text. Assuming the changes are compatible, I'd suggest changing the subject of two commits as follows:

"ABI change: add shared memory support" would become "core: add support for dynamic registration of shared memory"
"ABI change: enable TMEM parameters with non-contiguous shm" would become "core: allow non-contiguous shared memory in temporary memory references"

Did I get this right?

lorc · 2017-09-19T20:58:31Z

Hello.

I have squashed, rebased and applied tags to this patch series.
But there is one new patch, that was born during kernel part rework: core: enable TMEM parameters with non-contiguous shm (eb3e932). I didn't applied tags to it, because it wasn't reviewed. I don't know what to do with it. Will you review it as a part of this series, or should I post it as a separate PR?

jenswi-linaro · 2017-09-20T09:05:04Z

You can add:
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
to "core: enable TMEM parameters with non-contiguous shm"

lorc · 2017-09-20T10:25:55Z

Thank you, @jenswi-linaro , I added your R-b tag and repushed patches.

jforissier · 2017-09-20T11:28:37Z

Sorry to bother, but I'm still not happy with the commit subject: "core: add shared memory support". OP-TEE already supports shared memory so it doesn't make sense. Say waht you are really adding.

Same goes with "core: enable TMEM parameters with non-contiguous shm". What is TMEM? This acronym appears absolutely nowhere, not even in that patch.

etienne-lms

still late comments....

Commit " entry_std.c: comment fixes: "

can you change 1st line to "core: fix comments in entry_std.c"

Comment of commit "entry_std: save parameters attributes into local memory"

s/poses/pose/
s/parameter attribute/parameter attributes/.

etienne-lms · 2017-09-20T11:33:44Z

core/arch/arm/tee/entry_std.c

@@ -292,6 +325,9 @@ static void entry_open_session(struct thread_smc_args *smc_args,
 	plat_prng_add_jitter_entropy();

 out:
+	cleanup_params(arg->params + num_meta, saved_attr,


Can you cross check that there is no issue when this cleanup from get_open_session_meta(). num_meta may not be inited ?

lorc · 2017-10-10T15:16:38Z

On my side, I feel ok with the feature being disable when platform doest not register nsec physical area(s).

Yeah, I thought about this. But, it does not eliminate unused code and also, strictly speaking, defined nsec region is not equal to enabled SHM. Yes, defined nsec memory region is prerequisite for dynamic SHM, but It can have other uses...

jforissier · 2017-10-10T15:28:06Z

@lorc I think your CFG_DBG_DISABLE_DYN_SHM_CAP approach is good enough. At least, it fit my testing needs and is not too intrusive.

@etienne-lms relying on register_nsec_ddr() is not strictly correct as said above, and is also not convenient because it cannot be controlled from the command line (test environment...).
So I think we should stick to the simple CFG_ approach in this PR, which has been discussed quite a lot already! And do further changes in a separate PR if needed.

That being said... for simplicity, I would recommend CFG_DYN_SHM_CAP ?= y and #if defined(CFG_DYN_SHM_CAP). That is, reverse the logic and drop the useless _DBG.
Note also: s/nevertheles/nevertheless/

With that, commit "build: disable..." is:
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

etienne-lms · 2017-10-10T15:40:12Z

Actually, the last change (introduces CFG_...) does not remove dynamic shm support from the optee kernel, it only drop the capability flag. Hence even disabled, the REE can still register and use dyn-shm. It is the expected behaviour?

lorc · 2017-10-10T15:43:03Z

Yep. I have pointed this in comments to config.mk:

 +# Note that you can disable this feature for debug purposes. OP-TEE will not
 +# report to Normal World that it support dynamic SHM. But, nevertheles it
 +# will accept dynamic SHM buffers.

etienne-lms · 2017-10-10T15:45:01Z

:) i should have read further. Well, so this is the expected behaviour.
Thanks.

jforissier · 2017-10-10T15:46:16Z

@etienne-lms yes and it's enough to exercise the usual shm pool on a platform that otherwise supports the dyn shm. make CFG_DYN_SHM_CAP=n, run xtest and you're done.

lorc · 2017-10-10T16:02:20Z

@jforissier I did as you asked. That was trivial change, so I did it in place, if you don't mind. Also I added your A-b

jforissier · 2017-10-10T16:09:58Z

@lorc thanks but you forgot to update the commit subject ;-)

lorc · 2017-10-10T16:12:44Z

@jforissier oops :) Should be fine now. I also elaborated commit message a bit.

lorc · 2017-10-10T20:18:26Z

Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> (Rcar M3) with #1871
and with CFG_UNWIND=n (see #1872)

jforissier · 2017-10-11T07:05:39Z

Shippable fails due to checkpatch warnings that can easily be fixed.

jenswi-linaro · 2017-10-11T08:30:36Z

Together with #1874
Tested-by: Jens Wiklander <jens.wiklander@linaro.org> (Juno with and without pager)

lorc · 2017-10-11T11:37:49Z

@jforissier, should I fix this one?

WARNING: line over 80 characters
#95: FILE: core/arch/arm/tee/entry_fast.c:112:
+		IMSG("No NS DDR defined for the platform. Disabling dynamic SHM");

Kernel coding style recommends leave long text constants as is even if they are longer than 80 characters to ease up grepping:

However, never break user-visible strings such as
printk messages, because that breaks the ability to grep for them.

jforissier · 2017-10-11T11:48:54Z

What about this (we want the message even when CFG_DYN_SHM_CAP is disabled):

        bool dshm_en = false;

#ifdef CFG_DYN_SHM_CAP
        dhsm_en = core_mmu_nsec_ddr_is_defined();
        if (dhsm_en)
                args->a1 |= OPTEE_SMC_SEC_CAP_DYNAMIC_SHM;
#endif
        IMSG("Dynamic shared memory is %sabled", dhsm_en ? "en" : "dis");

lorc · 2017-10-11T12:14:51Z

Okay, will do in this way.

Normal world now can call OPTEE_MSG_CMD_REGISTER_SHM and OPTEE_MSG_CMD_UNREGISTER_SHM functions to register/unregister shared memory. After that, it can use OPTEE_MSG_ATTR_TYPE_RMEM_* to reference to that registered shared buffers. Signed-off-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>

Now, when we can pass list of pages between REE and TEE it is possible to use temporary memory references that are not located in a preallocated shared memory area. By employing OPTEE_MSG_ATTR_NONCONTIG parameter attribute, REE can provide own buffer as a temporary memory reference. Actually, such parameters are indistinguishable from registered shared memory references. So, when OP-TEE spots temporary memory reference with OPTEE_MSG_ATTR_NONCONTIG attribute, it will create `mobj_reg_shm` for it. After call was handled, it will free that mobj. Signed-off-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey) Tested-by: Jens Wiklander <jens.wiklander@linaro.org> (FVP, QEMU v7/v8) Tested-by: Jens Wiklander <jens.wiklander@linaro.org> (Juno with and without pager) Tested-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> (Rcar M3)

- removed spaces before "?" in comments - Capitalized first letter in first words Signed-off-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>

This variable can disable reported capability OPTEE_SMC_SEC_CAP_DYNAMIC_SHM. But dynamic SHM remains fully operational, though. This can be used for testing and debugging to emulate system, where dynamic SHM is not supported. Signed-off-by: Volodymyr Babchuk <vlad.babchuk@gmail.com> Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

lorc · 2017-10-11T12:40:40Z

Reworked tee_entry_exchange_capabilities() and also added new T-b tags.

jforissier · 2017-10-11T13:50:11Z

Thanks to all the contributors in this thread, @lorc good job! 👍
I'm merging this PR now.

lorc · 2017-10-11T14:03:11Z

Wow, I can't believe that it is done! Thank you to all of you guys for your support and help. I learned much while working on this feature.
BTW, I already tested it with Xen and it allowed me to call OP-TEE from Dom0 without dirty hacks in the hypervisor. I'm going to upstream needed patches to Xen, so Dom0<->OP-TEE interaction will be a standard feature.
Next big task is to add virtualization support in OP-TEE: tag sessions, shared memory, loaded TAs with virtual machine ID, check accesses and so on.

etienne-lms · 2017-10-11T14:51:38Z

congratulations @lorc (and all contribs) for this. took a while, thanks for your patience.

stuyoder reviewed Jun 28, 2017

View reviewed changes

jenswi-linaro reviewed Jun 29, 2017

View reviewed changes

etienne-lms reviewed Jul 1, 2017

View reviewed changes

etienne-lms reviewed Jul 2, 2017

View reviewed changes

This was referenced Jul 13, 2017

Secure mapping attribute is missing in core_mmu_map_pages. #1686

Closed

Accessing Normal World Memory Space from TA #1706

Closed

etienne-lms reviewed Aug 22, 2017

View reviewed changes

jenswi-linaro mentioned this pull request Sep 19, 2017

New OP-TEE SHM design. linaro-swg/linux#29

Merged

lorc force-pushed the dyn_shm branch 2 times, most recently from ae9d888 to 0f0cff2 Compare September 19, 2017 20:57

lorc force-pushed the dyn_shm branch from 0f0cff2 to 060549c Compare September 20, 2017 10:24

etienne-lms reviewed Sep 20, 2017

View reviewed changes

lorc force-pushed the dyn_shm branch 2 times, most recently from e6091b5 to 126bf59 Compare September 20, 2017 16:24

lorc force-pushed the dyn_shm branch from 35f5ace to 0656022 Compare October 10, 2017 16:01

lorc force-pushed the dyn_shm branch from 0656022 to ed91c98 Compare October 10, 2017 16:11

lorc mentioned this pull request Oct 10, 2017

TA from older version crashes stack unwind layer in OP-TEE (WAS Stack unwind causes data abort on Rcar M3 board) #1872

Closed

lorc force-pushed the dyn_shm branch from ed91c98 to 3d3f699 Compare October 11, 2017 12:23

lorc added 4 commits October 11, 2017 15:23

lorc force-pushed the dyn_shm branch from 3d3f699 to 6a86455 Compare October 11, 2017 12:24

jforissier merged commit d81f93a into OP-TEE:master Oct 11, 2017

lorc deleted the dyn_shm branch October 11, 2017 14:09

Enable dynamic SHM support #1631

Enable dynamic SHM support #1631

Conversation

lorc commented Jun 22, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stuyoder Jul 3, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prime-zeng commented Jun 29, 2017 • edited Loading

jenswi-linaro left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lorc commented Jun 30, 2017

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

etienne-lms commented Jul 1, 2017 • edited Loading

etienne-lms Jul 2, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prime-zeng commented Jul 3, 2017

etienne-lms commented Jul 3, 2017

prime-zeng commented Jul 4, 2017

lorc commented Jul 4, 2017

jenswi-linaro commented Jul 6, 2017

lorc commented Jul 6, 2017

jenswi-linaro commented Aug 22, 2017

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jenswi-linaro commented Aug 22, 2017

jforissier commented Aug 31, 2017

lorc commented Sep 19, 2017

jenswi-linaro commented Sep 20, 2017

lorc commented Sep 20, 2017

jforissier commented Sep 20, 2017

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lorc commented Oct 10, 2017

jforissier commented Oct 10, 2017

etienne-lms commented Oct 10, 2017

lorc commented Oct 10, 2017

etienne-lms commented Oct 10, 2017

jforissier commented Oct 10, 2017

lorc commented Oct 10, 2017

jforissier commented Oct 10, 2017

lorc commented Oct 10, 2017

lorc commented Oct 10, 2017

jforissier commented Oct 11, 2017

jenswi-linaro commented Oct 11, 2017

lorc commented Oct 11, 2017

jforissier commented Oct 11, 2017 • edited Loading

lorc commented Oct 11, 2017

lorc commented Oct 11, 2017

jforissier commented Oct 11, 2017

lorc commented Oct 11, 2017

etienne-lms commented Oct 11, 2017

stuyoder Jul 3, 2017 •

edited

Loading

prime-zeng commented Jun 29, 2017 •

edited

Loading

etienne-lms commented Jul 1, 2017 •

edited

Loading

etienne-lms Jul 2, 2017 •

edited

Loading

jforissier commented Oct 11, 2017 •

edited

Loading