From: Liam Mark <lmark@codeaurora.org>
To: John Stultz <john.stultz@linaro.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
Laura Abbott <labbott@redhat.com>,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
Greg KH <gregkh@linuxfoundation.org>,
Sumit Semwal <sumit.semwal@linaro.org>,
Brian Starkey <Brian.Starkey@arm.com>,
"Andrew F . Davis" <afd@ti.com>, Chenbo Feng <fengc@google.com>,
Alistair Strachan <astrachan@google.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Vincent Donnefort <Vincent.Donnefort@arm.com>,
Marissa Wall <marissaw@google.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.2.10.1903131627160.5462@lmark-linux.qualcomm.com> (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 <lmark@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
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 [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) 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.2.10.1903131627160.5462@lmark-linux.qualcomm.com \
--to=lmark@codeaurora.org \
--cc=Brian.Starkey@arm.com \
--cc=Vincent.Donnefort@arm.com \
--cc=afd@ti.com \
--cc=astrachan@google.com \
--cc=benjamin.gaignard@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=fengc@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.stultz@linaro.org \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marissaw@google.com \
--cc=sumit.semwal@linaro.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).