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

[Daniel Vetter]

On Fri, Mar 13, 2015 at 11:10:56AM +0200, David Weinehall wrote:
> On 2015-03-09 14:02, Chris Wilson wrote:
> >On Mon, Mar 09, 2015 at 02:34:46AM +0000, Zou, Nanhai wrote:
> >>We don't need MAP_FIXED, we just want to avoid address 0 to be allocated.
> >>
> >>Though I think using MAP_FIXED is overkill, will bring much unnecessary complexity on both kernel and beignet side.
> >>I don't mind if people can provide stable MAP_FIXED patches to resolve this problem a few months or years later.
> >>
> >>At that time, kernel driver can revert the reserve page 0 patch.
> >>Before that reserve page 0 can benefit all the Beignet user without breaking anything.
> >
> >The point is that is becomes ABI. So no the kernel can't just revert it.
> >There is nothing special about address 0 in ether GTT or virtual memory.
> >If you require a special object allocated at address 0, allocate a
> >special object at address 0.
> 
> I've explained the ABI issue in a separate e-mail discussion, and I believe
> that they now fully understand what you meant.
> 
> That said, their main chain of reasoning makes some sense -- there is a
> race condition if we rely on using MAP_FIXED, at least on systems that
> do not support ppgtt. Ending up in a situation where opencl applications
> work on other hw, but fails when run on an i915-system would, at least in my
> opinion, not be ideal, no matter if it's due to an unfortunate design.
> 
> *If* a MAP_FIXED solution is decided upon, how can userland be sure that the
> GTT page mapped to 0 is indeed usable as the NULL pointer?
> ON a PPGTT system that would be easy enough -- it's per process, so we'll be
> the only process allocating a page at 0, but if allocations
> use a global address space that won't be possible to guarantee.
> 
> I realise that the first submitted patch didn't cover the GTT case, since
> the first indication I got was that not only was there a special case for
> GTT to need page 0 for other things, but also that this was "good enough"
> for opencl, but it seems that a full solution would be needed.
> 
> Since this is a memory area we're talking about it's not uncommon to have
> the 0th page represent the NULL pointer and impossible for applications to
> reserve, so it would hardly be an unusual and inexplicable solution.
> 
> All this said, how do "the other two" (NVidia, ATI) deal with this?
> Implicit NULL-page, explicit MAP_FIXED allocation, or something else?

Afaik there's no opensource ocl implementation yet that needs this. So no
idea what they do.

If supporting systems without full ppgtt is a requirement for you (still
wonky on gen8 a bit, so might be a good strategy) then imo it's the
PIN_BIAS idea I've laid out earlier in this thread. That one will work
everywhere. softpin can unexpectedly fail without full ppgtt if the kernel
decides to put something at a given spot, which imo means we should only
expose it on full ppgtt systems.

And PIN_BIAS should be fairly easy to wire up since the internal logic is
all there already. So "just" needs an execbuf flag, igt test and
appropriate userspace to set that new bit.

> Kind regards, David
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 -
> 4 Domiciled in Helsinki
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

You want to remove this when submitting to public mailing lists. Either
apply for an exception or grab a 2nd mail address for mailing list
communication.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch