From patchwork Thu Sep 11 08:39:46 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mika Kuoppala X-Patchwork-Id: 4883661 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1310D9FC59 for ; Thu, 11 Sep 2014 08:39:38 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7DE9120256 for ; Thu, 11 Sep 2014 08:39:36 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 2D21F2022D for ; Thu, 11 Sep 2014 08:39:35 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 95A8A6E509; Thu, 11 Sep 2014 01:39:34 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id A1A316E509 for ; Thu, 11 Sep 2014 01:39:30 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 11 Sep 2014 01:39:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,504,1406617200"; d="scan'208";a="601337927" Received: from rosetta.fi.intel.com (HELO rosetta) ([10.237.72.93]) by orsmga002.jf.intel.com with ESMTP; 11 Sep 2014 01:39:29 -0700 Received: by rosetta (Postfix, from userid 1000) id 7781780052; Thu, 11 Sep 2014 11:39:50 +0300 (EEST) From: Mika Kuoppala To: intel-gfx@lists.freedesktop.org Date: Thu, 11 Sep 2014 11:39:46 +0300 Message-Id: <1410424786-22992-1-git-send-email-mika.kuoppala@intel.com> X-Mailer: git-send-email 1.9.1 Subject: [Intel-gfx] [PATCH] drm/i915: Add secure batch ggtt vma as active during execution X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When PPGGT is in use, we need to bind secure batches also to ggtt. We used to pin, exec and unpin. This trick worked as there was nothing competing in ggtt space and the ppggt vma was used to tracking. But this left the ggtt vma untracked and potentially it could vanish during the batch execution. Track ggtt vma properly by piggypacking it into the eb->vmas list just before batch submission is made. This ensures that vma gets into the active list properly. Suggested-by: Daniel Vetter Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 1a0611b..06c71e9 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -217,6 +217,10 @@ i915_gem_execbuffer_unreserve_vma(struct i915_vma *vma) entry = vma->exec_entry; + /* Check if piggypacked ggtt batch entry */ + if (!entry) + return; + if (entry->flags & __EXEC_OBJECT_HAS_FENCE) i915_gem_object_unpin_fence(obj); @@ -224,6 +228,8 @@ i915_gem_execbuffer_unreserve_vma(struct i915_vma *vma) vma->pin_count--; entry->flags &= ~(__EXEC_OBJECT_HAS_FENCE | __EXEC_OBJECT_HAS_PIN); + + vma->exec_entry = NULL; } static void eb_destroy(struct eb_vmas *eb) @@ -970,7 +976,7 @@ i915_gem_execbuffer_move_to_active(struct list_head *vmas, /* update for the implicit flush after a batch */ obj->base.write_domain &= ~I915_GEM_GPU_DOMAINS; } - if (entry->flags & EXEC_OBJECT_NEEDS_FENCE) { + if (entry && entry->flags & EXEC_OBJECT_NEEDS_FENCE) { obj->last_fenced_seqno = seqno; if (entry->flags & __EXEC_OBJECT_HAS_FENCE) { struct drm_i915_private *dev_priv = to_i915(ring->dev); @@ -1385,6 +1391,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, * batch" bit. Hence we need to pin secure batches into the global gtt. * hsw should have this fixed, but bdw mucks it up again. */ if (flags & I915_DISPATCH_SECURE) { + struct i915_vma *vma; /* * So on first glance it looks freaky that we pin the batch here * outside of the reservation loop. But: @@ -1399,6 +1406,18 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, if (ret) goto err; + vma = i915_gem_obj_to_ggtt(batch_obj); + + /* If there is no exec_entry in this stage, ggtt vma + * is not in the eb->vmas list. Piggypack our ggtt + * address to the list in order for it to be added as + * an active vma in do_execbuf() + */ + if (vma->exec_entry == NULL) { + drm_gem_object_reference(&batch_obj->base); + list_add_tail(&vma->exec_list, &eb->vmas); + } + exec_start += i915_gem_obj_ggtt_offset(batch_obj); } else exec_start += i915_gem_obj_offset(batch_obj, vm); @@ -1406,14 +1425,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data, ret = dev_priv->gt.do_execbuf(dev, file, ring, ctx, args, &eb->vmas, batch_obj, exec_start, flags); - /* - * FIXME: We crucially rely upon the active tracking for the (ppgtt) - * batch vma for correctness. For less ugly and less fragility this - * needs to be adjusted to also track the ggtt batch vma properly as - * active. - */ - if (flags & I915_DISPATCH_SECURE) - i915_gem_object_ggtt_unpin(batch_obj); err: /* the request owns the ref now */ i915_gem_context_unreference(ctx);