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

[Jesse Barnes]

>>> Yeah we'll rebind if needed. We can make this an execbuf or context
>>> flag, in either case anything that gets executed by ocl will be moved
>>> around if it accidentally ended up at the wrong place. The only
>>> exception is if a buffer is pinned already, i.e. if you're doing
>>> direct rendering to the frontbuffer. That will give you an EBUSY, but
>>> otoh that also shouldn't ever happen really.
>>
>> Ruiling, are you working on this or someone from your team, presumably based
>> on the patch Chris posted earlier?  The zero page reservation certainly seems
>> simpler to me, but the MAP_FIXED approach is a lot more flexible, and can be
>> used for other types of debug and usages as well (we'll need something like it
>> for OCL pointer sharing for example), so seems like a good thing to pursue
>> regardless.
>>
> Hi Jesse,
> 	MAP_FIXED cannot solve this issue. You may see my previous comments for this topic, 
> There could be many components in on single process, Beignet cannot be guaranteed to be the first one who has allocated address 0.

Yeah, MAP_FIXED sounds a bit more ambitious and though I think it would
work for OCL 2.0 pointer sharing, it's a little different than we were
planning.  To summarize, we have three possible approaches, each with
its own problems:
  1) simple patch to avoid binding at address 0 in PPGTT:
     does impact the ABI (though generally not in a harmful way), and
     may not be possible with aliasing PPGTT with e.g. framebuffers
     bound at offset 0
  2) exposing PIN_BIAS to userspace
     Would allow userspace to avoid pinning any buffers at offset 0 at
     execbuf time, but still has the problem with previously bound buffers
     and aliasing PPGTT
  3) MAP_FIXED interface
     Flexible approach allowing userspace to manage its own virtual
     memory, but still has the same issues with aliasing PPGTT, and with
     shared contexts, which would have to negotiate between libraries how to
     handle the zero page

For (1) and (2) the kernel pieces are really already in place, the main
thing we need is a new flag to userspace to indicate behavior.  I'd
prefer (1) with a context creation flag to indicate "don't bind at 0".
Execbuf would try to honor this, and userspace could check if any
buffers ended up at 0 in the aliasing PPGTT case by checking the
resulting offsets following the call.  I expect in most cases this would
be fine.

It should be pretty easy to extend Ruiling's patch to use a context flag
to determine the behavior; is that something you can do?  Any objections
to this approach?

It does mean that shared contexts need to be handled specially, or won't
get the 0 page protection, but I think Mesa wants this behavior too, and
libva probably wouldn't mind, so you could just require new versions of
those that set this flag when telling people what's supported for proper
NULL pointer handling.

Any objections to that approach?

Thanks,
Jesse