[Beignet] [Intel-gfx] Preventing zero GPU virtual address allocation

[Zou, Nanhai]

I don't understand why we need a complex solution when there is already a simple solution with patch.
What is the drawback of reserving page 0?
Before we going to that complex solution, could we just reserve page zero?
It is simple and straight forward.

Thanks
Zou Nanhai

> -----Original Message-----
> From: Beignet [mailto:beignet-bounces at lists.freedesktop.org] On Behalf Of
> Daniel Vetter
> Sent: Thursday, March 05, 2015 11:28 PM
> To: Chris Wilson; Daniel Vetter; Song, Ruiling; Vetter, Daniel;
> intel-gfx at lists.freedesktop.org; Yang, Rong R; beignet at lists.freedesktop.org;
> Weinehall, David
> Subject: Re: [Beignet] [Intel-gfx] Preventing zero GPU virtual address allocation
> 
> On Thu, Mar 05, 2015 at 01:01:21PM +0000, Chris Wilson wrote:
> > On Thu, Mar 05, 2015 at 01:52:51PM +0100, Daniel Vetter wrote:
> > > On Thu, Mar 05, 2015 at 02:56:52AM +0000, Song, Ruiling wrote:
> > > > Hi Daniel,
> > > >
> > > > OpenCL language support NULL pointer, using zero as the NULL
> > > > pointer is the obvious way. That is zero will be treated as
> > > > invalid address.  Then it requires drm won't allocate zero to drm
> > > > buffer. And David in CC list has help us make a patch, please see
> > > > attached. The logic is only for ppgtt, and he said zero offset is
> > > > used under ggtt. My question is what is offset zero used under
> > > > ggtt? Will it make sure zero is not allocatable to drm buffer object?
> > >
> > > The code in i915_gem_execbuf.c already supports an optional bias to
> > > avoid putting a buffer into the first few kb. See
> > > __EXEC_OBJECT_NEEDS_BIAS. I suggest you expose this to userspace,
> > > which also address your issue that you didn't add an abi revision flag.
> >
> > A better API would be to allow userspace to request a buffer to place
> > at a specific point in the VM and fail if that is not possible aka
> > soft-pinning. Then OCL could assign a bo to offset 0 and detect writes
> > to the NULL address if it so desired. With full-ppgtt, userspace can
> > be sure of being able to evict any location in its VM and so also
> > allows graceful detection of scenarios under which it cannot provide
> > the NULL address safety feature (and opt not to run, or just bury its
> > head in the sand).
> 
> I recommended exposing the PIN_BIAS since that will work without full ppgtt
> too. And yeah for full ppgtt we could just use svm where userspace controls the
> address, but since that's still a bit out we might need a quick interim solution?
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Beignet mailing list
> Beignet at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/beignet