[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7eb7ca8f64789c4eb5096e19f4cf15f6b53bb260.camel@mediatek.com>
Date: Fri, 27 Oct 2023 07:47:39 +0000
From: Yong Wu (吴勇) <Yong.Wu@...iatek.com>
To: "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
"christian.koenig@....com" <christian.koenig@....com>,
"quic_vjitta@...cinc.com" <quic_vjitta@...cinc.com>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"sumit.semwal@...aro.org" <sumit.semwal@...aro.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
"jstultz@...gle.com" <jstultz@...gle.com>,
"linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Jianjiao Zeng (曾健姣)
<Jianjiao.Zeng@...iatek.com>,
Kuohong Wang (王國鴻)
<kuohong.wang@...iatek.com>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
"Brian.Starkey@....com" <Brian.Starkey@....com>,
"benjamin.gaignard@...labora.com" <benjamin.gaignard@...labora.com>,
"tjmercier@...gle.com" <tjmercier@...gle.com>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"angelogioacchino.delregno@...labora.com"
<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH 4/9] dma-buf: heaps: Initialise MediaTek secure heap
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@...iatek.com>
> >>> ---
> >>> 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
> >>
Powered by blists - more mailing lists