On Thu, 2023-10-26 at 10:18 +0530, Vijayanand Jitta 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:29 PM, Yong Wu (吴勇) wrote: > > On Thu, 2023-10-19 at 10:15 +0530, Vijayanand Jitta wrote: > >> > >> External email : Please do not click links or open attachments > until > >> you have verified the sender or the content. > >> > >> > >> On 9/11/2023 8:00 AM, Yong Wu wrote: > >>> Initialise a mtk_svp heap. Currently just add a null heap, > Prepare > >> for > >>> the later patches. > >>> > >>> Signed-off-by: Yong Wu <yong.wu@xxxxxxxxxxxx> > >>> --- > >>> drivers/dma-buf/heaps/Kconfig | 8 ++ > >>> drivers/dma-buf/heaps/Makefile | 1 + > >>> drivers/dma-buf/heaps/mtk_secure_heap.c | 99 > >> +++++++++++++++++++++++++ [...] > >>> + > >>> +static struct dma_buf * > >>> +mtk_sec_heap_allocate(struct dma_heap *heap, size_t size, > >>> + unsigned long fd_flags, unsigned long heap_flags) > >>> +{ > >>> +struct mtk_secure_heap_buffer *sec_buf; > >>> +DEFINE_DMA_BUF_EXPORT_INFO(exp_info); > >>> +struct dma_buf *dmabuf; > >>> +int ret; > >>> + > >>> +sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL); > >> > >> As we know, kzalloc can only allocate 4MB at max. So, secure heap > has > >> this limitation. > >> can we have a way to allocate more memory in secure heap ? maybe > >> similar to how system heap does? > > > > This is just the size of a internal structure. I guess you mean the > > secure memory size here. Regarding secure memory allocating flow, > our > > flow may be different with yours. > > > > Let me explain our flow, we have two secure buffer types(heaps). > > a) mtk_svp > > b) mtk_svp_cma which requires the cma binding. > > > > The memory management of both is inside the TEE. We only need to > tell > > the TEE which type and size of buffer we want, and then the TEE > will > > perform and return the memory handle to the kernel. The > > kzalloc/alloc_pages is for the normal buffers. > > > > Regarding the CMA buffer, we only call cma_alloc once, and its > > management is also within the TEE. > > > > Thanks for the details. > > I see for mvp_svp, allocation is also specific to TEE, as TEE takes > care of allocation as well. Yes. The allocation management of these two heaps is in the TEE. > > I was thinking if allocation path can also be made generic ? without > having > dependency on TEE. > For eg : A case where we want to allocate from kernel and secure that > memory, > the current secure heap design can't be used. Sorry, This may be because our HW is special. The HW could protect a certain region, but it can only protect 32 regions. So we cannot allocate them in the kernel arbitrarily and then enter TEE to protect them. > > Also i suppose TEE allocates contiguous memory for mtk_svp ? or does > it support > scattered memory ? Yes. After the TEE runs for a period of time, the TEE memory will become discontinuous, and a secure IOMMU exists in the TEE. > >> > >> Thanks, > >> Vijay > >>