On Tue, Oct 13, 2015 at 6:22 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> Pinning a userptr onto the hardware raises interesting questions about
> the lifetime of such a surface as the framebuffer extends that life
> beyond the client's address space. That is the hardware will need to
> keep scanning out from the backing storage even after the client wants
> to remap its address space. As the hardware pins the backing storage,
> the userptr becomes invalid and this raises a WARN when the clients
> tries to unmap its address space. The situation can be even more
> complicated when the buffer is passed between processes, between a
> client and display server, where the lifetime and hardware access is
> even more confusing. Deny it.
Can we allow this for unsynchronized userptrs?
Kristian
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> Cc: Michał Winiarski <michal.winiarski@xxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx
> ---
> drivers/gpu/drm/i915/i915_gem_userptr.c | 5 ++++-
> drivers/gpu/drm/i915/intel_display.c | 5 +++++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 2dd911ab3019..3ce1b557f7c4 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -974,7 +974,10 @@ out:
> * Also note, that the object created here is not currently a "first class"
> * object, in that several ioctls are banned. These are the CPU access
> * ioctls: mmap(), pwrite and pread. In practice, you are expected to use
> - * direct access via your pointer rather than use those ioctls.
> + * direct access via your pointer rather than use those ioctls. Another
> + * restriction is that we do not allow userptr surfaces to be pinned to the
> + * hardware and so we reject any attempt to create a framebuffer out of a
> + * userptr.
> *
> * If you think this is a good interface to use to pass GPU memory between
> * drivers, please use dma-buf instead. In fact, wherever possible use
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index b89131654a0e..d1deaedcc4ce 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14116,6 +14116,11 @@ static int intel_user_framebuffer_create_handle(struct drm_framebuffer *fb,
> struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> struct drm_i915_gem_object *obj = intel_fb->obj;
>
> + if (obj->userptr.mm) {
> + DRM_DEBUG("attempting to use a userptr for a framebuffer, denied\n");
> + return -EINVAL;
> + }
> +
> return drm_gem_handle_create(file, &obj->base, handle);
> }
>
> --
> 2.6.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html