From: Liam Mark <firstname.lastname@example.org> To: John Stultz <email@example.com> Cc: lkml <firstname.lastname@example.org>, Laura Abbott <email@example.com>, Benjamin Gaignard <firstname.lastname@example.org>, Greg KH <email@example.com>, Sumit Semwal <firstname.lastname@example.org>, Brian Starkey <Brian.Starkey@arm.com>, "Andrew F . Davis" <email@example.com>, Chenbo Feng <firstname.lastname@example.org>, Alistair Strachan <email@example.com>, dri-devel <firstname.lastname@example.org>, Vincent Donnefort <Vincent.Donnefort@arm.com>, Marissa Wall <email@example.com> Subject: Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) Date: Wed, 13 Mar 2019 16:29:06 -0700 (PDT) [thread overview] Message-ID: <alpine.DEB.firstname.lastname@example.org> (raw) In-Reply-To: <CALAqxLUkGME+K=0g5QSja4CvN0w9z0WV60djy+5rRC+Dg-jCGg@mail.gmail.com> On Wed, 13 Mar 2019, John Stultz wrote: > On Wed, Mar 13, 2019 at 1:11 PM Liam Mark <email@example.com> 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
next prev parent reply other threads:[~2019-03-13 23:29 UTC|newest] Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-05 20:54 John Stultz 2019-03-05 20:54 ` [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework John Stultz 2019-03-06 16:12 ` Benjamin Gaignard 2019-03-06 16:57 ` John Stultz 2019-03-15 8:55 ` Christoph Hellwig 2019-03-06 16:27 ` Andrew F. Davis 2019-03-06 19:03 ` John Stultz 2019-03-06 21:45 ` Andrew F. Davis 2019-03-15 8:54 ` Christoph Hellwig 2019-03-15 20:24 ` Andrew F. Davis 2019-03-15 20:18 ` Laura Abbott 2019-03-15 20:49 ` Andrew F. Davis 2019-03-15 21:29 ` John Stultz 2019-03-15 22:44 ` Laura Abbott 2019-03-18 4:38 ` Sumit Semwal 2019-03-18 4:41 ` Sumit Semwal 2019-03-19 12:08 ` Brian Starkey 2019-03-19 15:24 ` Andrew F. Davis 2019-03-21 21:16 ` John Stultz 2019-03-27 14:53 ` Greg KH 2019-03-28 6:09 ` John Stultz 2019-03-05 20:54 ` [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers John Stultz 2019-03-13 20:18 ` Liam Mark 2019-03-13 21:48 ` Andrew F. Davis 2019-03-13 22:57 ` Liam Mark 2019-03-13 23:42 ` Andrew F. Davis 2019-03-15 9:06 ` Christoph Hellwig 2019-03-19 15:03 ` Andrew F. Davis 2019-03-21 20:01 ` John Stultz 2019-03-19 14:26 ` Brian Starkey 2019-03-21 20:11 ` John Stultz 2019-03-21 20:35 ` Andrew F. Davis 2019-03-21 20:43 ` Andrew F. Davis 2019-03-05 20:54 ` [RFC][PATCH 3/5 v2] dma-buf: heaps: Add system heap to dmabuf heaps John Stultz 2019-03-06 16:01 ` Benjamin Gaignard 2019-03-11 5:48 ` John Stultz 2019-03-13 20:20 ` Liam Mark 2019-03-13 22:49 ` John Stultz 2019-03-15 9:06 ` Christoph Hellwig 2019-03-05 20:54 ` [RFC][PATCH 4/5 v2] dma-buf: heaps: Add CMA heap to dmabuf heapss John Stultz 2019-03-06 16:05 ` Benjamin Gaignard 2019-03-21 20:15 ` John Stultz 2019-03-15 9:06 ` Christoph Hellwig 2019-03-15 20:08 ` John Stultz 2019-03-19 14:53 ` Brian Starkey 2019-03-05 20:54 ` [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test John Stultz 2019-03-06 16:14 ` Benjamin Gaignard 2019-03-06 16:35 ` Andrew F. Davis 2019-03-06 18:19 ` John Stultz 2019-03-06 18:32 ` Andrew F. Davis 2019-03-06 17:01 ` John Stultz 2019-03-15 20:07 ` Laura Abbott 2019-03-15 20:13 ` John Stultz 2019-03-15 20:49 ` Laura Abbott 2019-03-13 20:23 ` Liam Mark 2019-03-13 20:11 ` [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) Liam Mark 2019-03-13 22:30 ` John Stultz 2019-03-13 23:29 ` Liam Mark [this message] 2019-03-19 16:54 ` Benjamin Gaignard 2019-03-19 16:59 ` Andrew F. Davis 2019-03-19 21:58 ` Rob Clark 2019-03-19 22:36 ` John Stultz 2019-03-20 9:16 ` Benjamin Gaignard 2019-03-20 14:44 ` Andrew F. Davis 2019-03-20 15:59 ` Benjamin Gaignard 2019-03-20 16:11 ` John Stultz 2019-03-15 20:34 ` Laura Abbott 2019-03-15 23:15 ` Jerome Glisse 2019-03-16 0:16 ` John Stultz
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.DEB.firstname.lastname@example.org \ --email@example.com \ --cc=Brian.Starkey@arm.com \ --cc=Vincent.Donnefort@arm.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).