On Wed, 2023-11-01 at 11:20 +0530, Jaskaran Singh wrote:

External email : Please do not click links or open attachments until you have verified the sender or the content. On 10/20/2023 3:20 PM, Yong Wu (吴勇) wrote:

...

On Thu, 2023-10-19 at 10:16 +0530, Vijayanand Jitta wrote:

...

Instead of having a vendor specific binding for cma area, How

about

...

...

retrieving

https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunihi...

...

...

? dma_heap_add_cma can just associate cma region and create a heap.

So,

...

...

we can reuse cma heap code for allocation instead of replicating that code here.

Thanks for the reference. I guess we can't use it. There are two reasons: a) The secure heap driver is a pure software driver and we have no device for it, therefore we cannot call dma_heap_add_cma.

Hi Yong,

We're considering using struct cma as the function argument to dma_heap_add_cma() rather than struct device. Would this help resolve the problem of usage with dma_heap_add_cma()?

Yes. If we use "struct cma", I guess it works.

...

b) The CMA area here is dynamic for SVP. Normally this CMA can be

used

...

in the kernel. In the SVP case we use cma_alloc to get it and pass

the

...

entire CMA physical start address and size into TEE to protect the

CMA

...

region. The original CMA heap cannot help with the TEE part.

Referring the conversation at

https://lore.kernel.org/lkml/7a2995de23c24ef22c071c6976c02b97e9b50126.camel@...

;

since we're considering abstracting secure mem ops, would it make sense to use the default CMA heap ops (cma_heap_ops), allocate buffers from it and secure each allocated buffer?

Then it looks you also need tee operation like tee_client_open_session and tee_client_invoke_func, right?

It seems we also need change a bit for "cma_heap_allocate" to allow cma support operations from secure heap.

I will send a v2 to move the discussion forward. The v2 is based on our case, It won't include the cma part.

Thanks, Jaskaran.

...

Thanks.

...

Thanks, Vijay