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

[Chris Wilson]

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.

It's simple, userspace has no control over allocation of the GGTT.
Espcially something like address 0. They can make a request to have
their object at a certain location, but the kernel is entirely likely to
reject their request because it is pinned to hardware.

> 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.

Exactly.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre