linux-kernel - Re: [Linaro-mm-sig] [PATCH v5 00/40] drm/msm: sparse / "VM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPM=9twuSfvQ0_NUdRmp0_VtTE_Br7GAysRw+XOoX7BTxUBGYQ@mail.gmail.com>
Date: Tue, 20 May 2025 07:45:31 +1000
From: Dave Airlie <airlied@...il.com>
To: Rob Clark <robdclark@...il.com>
Cc: dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org, 
	linux-arm-msm@...r.kernel.org, Connor Abbott <cwabbott0@...il.com>, 
	Rob Clark <robdclark@...omium.org>, Abhinav Kumar <quic_abhinavk@...cinc.com>, 
	André Almeida <andrealmeid@...lia.com>, 
	Arnd Bergmann <arnd@...db.de>, Barnabás Czémán <barnabas.czeman@...nlining.org>, 
	Christopher Snowhill <chris@...e54.net>, Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, 
	Dmitry Baryshkov <lumag@...nel.org>, Eugene Lepshy <fekz115@...il.com>, 
	"open list:IOMMU SUBSYSTEM" <iommu@...ts.linux.dev>, Jason Gunthorpe <jgg@...pe.ca>, 
	Jessica Zhang <quic_jesszhan@...cinc.com>, Joao Martins <joao.m.martins@...cle.com>, 
	Jonathan Marek <jonathan@...ek.ca>, Jun Nie <jun.nie@...aro.org>, 
	Kevin Tian <kevin.tian@...el.com>, Konrad Dybcio <konradybcio@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, 
	"moderated list:DMA BUFFER SHARING FRAMEWORK:Keyword:bdma_?:buf|fence|resvb" <linaro-mm-sig@...ts.linaro.org>, 
	"m oderated list:ARM SMMU DRIVERS" <linux-arm-kernel@...ts.infradead.org>, 
	open list <linux-kernel@...r.kernel.org>, 
	"open list:DMA BUFFER SHARING FRAMEWORK:Keyword:bdma_?:buf|fence|resvb" <linux-media@...r.kernel.org>, 
	Marijn Suijten <marijn.suijten@...ainline.org>, Nicolin Chen <nicolinc@...dia.com>, 
	"Rob Herring (Arm)" <robh@...nel.org>, Robin Murphy <robin.murphy@....com>, Sean Paul <sean@...rly.run>, 
	Will Deacon <will@...nel.org>
Subject: Re: [Linaro-mm-sig] [PATCH v5 00/40] drm/msm: sparse / "VM_BIND" support

On Tue, 20 May 2025 at 07:25, Rob Clark <robdclark@...il.com> wrote:
>
> On Mon, May 19, 2025 at 2:15 PM Dave Airlie <airlied@...il.com> wrote:
> >
> > On Tue, 20 May 2025 at 03:54, Rob Clark <robdclark@...il.com> wrote:
> > >
> > > From: Rob Clark <robdclark@...omium.org>
> > >
> > > Conversion to DRM GPU VA Manager[1], and adding support for Vulkan Sparse
> > > Memory[2] in the form of:
> > >
> > > 1. A new VM_BIND submitqueue type for executing VM MSM_SUBMIT_BO_OP_MAP/
> > >    MAP_NULL/UNMAP commands
> > >
> > > 2. A new VM_BIND ioctl to allow submitting batches of one or more
> > >    MAP/MAP_NULL/UNMAP commands to a VM_BIND submitqueue
> > >
> > > I did not implement support for synchronous VM_BIND commands.  Since
> > > userspace could just immediately wait for the `SUBMIT` to complete, I don't
> > > think we need this extra complexity in the kernel.  Synchronous/immediate
> > > VM_BIND operations could be implemented with a 2nd VM_BIND submitqueue.
> >
> > This seems suboptimal for Vulkan userspaces. non-sparse binds are all
> > synchronous, you are adding an extra ioctl to wait, or do you manage
> > these via a different mechanism?
>
> Normally it's just an extra in-fence for the SUBMIT ioctl to ensure
> the binds happen before cmd execution
>
> When it comes to UAPI, it's easier to add something later, than to
> take something away, so I don't see a problem adding synchronous binds
> later if that proves to be needed.  But I don't think it is.

I'm not 100% sure that is conformant behaviour to the vulkan spec,

Two questions come to mind:
1. where is this out fence stored? vulkan being explicit with no
guarantee of threads doing things, seems like you'd need to use a lock
in the vulkan driver to store it, esp if multiple threads bind memory.

2. If it's fine to lazy bind on the hw side, do you also handle the
case where something is bound and immediately freed, where does the
fence go then, do you wait for the fence before destroying things?

Dave.


Dave.