[RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)

[Liam Mark]

On Wed, 13 Mar 2019, John Stultz wrote:

> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark <lmark at codeaurora.org> wrote:
> > On Tue, 5 Mar 2019, John Stultz wrote:
> > >
> > > Eventual TODOS:
> > > * Reimplement page-pool for system heap (working on this)
> > > * Add stats accounting to system/cma heaps
> > > * Make the kselftest actually useful
> > > * Add other heaps folks see as useful (would love to get
> > >   some help from actual carveout/chunk users)!
> >
> > We use a modified carveout heap for certain secure use cases.
> 
> Cool! It would be great to see if you have any concerns about adding
> such a secure-carveout heap to this framework. I suspect it would be
> fairly similar to how its integrated into ION, but particularly I'd be
> interested in issues around the lack of private flags and other
> allocation arguments like alignment.
> 

We are actively working to drop our secure careveout heap in order to 
improve memory utilization so I don't think there would be a good case for 
upstreaming it.

Our other secure heaps are CMA based and system heap based.
Because people have had difficulty designing a generic secure heap which 
would satisfy enough of everybody's use cases to be upstreamable we have 
been looking into moving away from having local secure heap changes and 
instead have been looking at how to instead have a separate driver be 
responsible for making an ION buffer memory secure. The idea was to do 
this in order to remove a lot of our local ION changes, but if a secure 
heap was upstreamed that supported our secure use cases I am sure we would 
be interested in using that.

The local change the ION API to support these heaps is the addition of all 
the VMID flags so that the client can specify where the client wants the 
memory assigned.


> > Although there would probably be some benefit in discssing how the dma-buf
> > heap framework may want to support
> > secure heaps in the future it is a large topic which I assume you don't
> > want to tackle now.
> 
> So I suspect others (Benjamin?) would have a more informed opinion on
> the details, but the intent is to allow secure heap implementations.
> I'm not sure what areas of concern you have for this allocation
> framework in particular?
> 

I don't have any areas of concern, my thought was just that flushing out a 
potential design for an upstreamable secure heap would allow us catch 
early on if there is anything fundamental that would need to change 
dma-buf heaps framework (such as the allocation API).
I don't think this is a necessary task at this point. 

Liam

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project