Message-ID: <ZnxWWtdShekGSUif@phenom.ffwll.local>
Date: Wed, 26 Jun 2024 19:56:42 +0200
From: Daniel Vetter <daniel@...ll.ch>
To: Christian König <christian.koenig@....com>
Cc: Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>,
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
	Yong Wu (吴勇) <Yong.Wu@...iatek.com>,
	"sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"mripard@...nel.org" <mripard@...nel.org>,
	"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>,
	"willy@...radead.org" <willy@...radead.org>,
	Kuohong Wang (王國鴻) <kuohong.wang@...iatek.com>,
	"quic_vjitta@...cinc.com" <quic_vjitta@...cinc.com>,
	"pavel@....cz" <pavel@....cz>,
	"robin.murphy@....com" <robin.murphy@....com>,
	"contact@...rsion.fr" <contact@...rsion.fr>,
	"logang@...tatee.com" <logang@...tatee.com>,
	"daniel@...ll.ch" <daniel@...ll.ch>,
	"jkardatzke@...gle.com" <jkardatzke@...gle.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>,
	"joakim.bech@...aro.org" <joakim.bech@...aro.org>,
	"ppaalanen@...il.com" <ppaalanen@...il.com>,
	"angelogioacchino.delregno@...labora.com" <angelogioacchino.delregno@...labora.com>,
	Youlin Pei (裴友林) <youlin.pei@...iatek.com>
Subject: Re: [PATCH v5 2/9] scatterlist: Add a flag for the restricted memory

On Wed, Jun 26, 2024 at 12:49:02PM +0200, Christian König wrote:
> Am 26.06.24 um 10:05 schrieb Jason-JH Lin (林睿祥):
> > > > I think I have the same problem as the ECC_FLAG mention in:
> > > > > > https://lore.kernel.org/linux-media/20240515-dma-buf-ecc-heap-v1-0-54cbbd049511@kernel.org/
> > > > > > I think it would be better to have the user configurable private
> > > > information in dma-buf, so all the drivers who have the same
> > > > requirement can get their private information from dma-buf directly
> > > > and
> > > > no need to change or add the interface.
> > > > > > What's your opinion in this point?
> > >  > Well of hand I don't see the need for that.
> > > > What happens if you get a non-secure buffer imported in your secure
> > > device?
> > 
> > We use the same mediatek-drm driver for secure and non-secure buffer.
> > If non-secure buffer imported to mediatek-drm driver, it's go to the
> > normal flow with normal hardware settings.
> > 
> > We use different configurations to make hardware have different
> > permission to access the buffer it should access.
> > 
> > So if we can't get the information of "the buffer is allocated from
> > restricted_mtk_cma" when importing the buffer into the driver, we won't
> > be able to configure the hardware correctly.
> 
> Why can't you get this information from userspace?

Same reason amd and i915/xe also pass this around internally in the
kernel, it's just that for those gpus the render and kms node are the same
driver so this is easy.

But on arm you have split designs everywhere and dma-buf import/export, so
something else is needed. And neither current kms uapi nor
protocols/extensions have provisions for this (afaik) because it works on
the big gpus, and on android it's just hacked up with backchannels.

So yeah essentially I think we probably need something like this, as much
as it sucks. I see it somewhat similar to handling pcip2pdma limitations
in the kernel too.

Not sure where/how it should be handled though, and maybe I've missed
something around protocols, in which case I guess we should add some
secure buffer flags to the ADDFB2 ioctl.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Powered by blists - more mailing lists