From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74333C4361B for ; Wed, 16 Dec 2020 08:43:26 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8434C2071C for ; Wed, 16 Dec 2020 08:43:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8434C2071C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=chris-wilson.co.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id ABEEC89B0C; Wed, 16 Dec 2020 08:43:22 +0000 (UTC) Received: from fireflyinternet.com (unknown [77.68.26.236]) by gabe.freedesktop.org (Postfix) with ESMTPS id 42FDE89B0C for ; Wed, 16 Dec 2020 08:43:20 +0000 (UTC) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 23340248-1500050 for multiple; Wed, 16 Dec 2020 08:43:15 +0000 MIME-Version: 1.0 In-Reply-To: <498fa7d973bb49acba439b0060d9e7d3@intel.com> References: <20201215203111.650-1-chris@chris-wilson.co.uk> <3e4fe0b2533e48d19d78f3a4752b6508@intel.com> <160806973208.14591.6953006911801735484@build.alporthouse.com> <498fa7d973bb49acba439b0060d9e7d3@intel.com> From: Chris Wilson To: "Tang, CQ" , intel-gfx@lists.freedesktop.org Date: Wed, 16 Dec 2020 08:43:16 +0000 Message-ID: <160810819627.1420.3427754786741837992@build.alporthouse.com> User-Agent: alot/0.9 Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: , vger.kernel.orgstable@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Quoting Tang, CQ (2020-12-16 00:51:21) > > > > -----Original Message----- > > From: Chris Wilson > > Sent: Tuesday, December 15, 2020 2:02 PM > > To: Tang, CQ ; intel-gfx@lists.freedesktop.org > > Cc: stable@ > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced > > vma check and vma insert > > > > Quoting Tang, CQ (2020-12-15 21:50:53) > > > > > > > > > > -----Original Message----- > > > > From: Chris Wilson > > > > Sent: Tuesday, December 15, 2020 12:31 PM > > > > To: intel-gfx@lists.freedesktop.org > > > > Cc: Chris Wilson ; Tang, CQ > > > > ; stable@vger.kernel.org > > > > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check > > > > and vma insert > > > > > > > > When inserting a VMA, we restrict the placement to the low 4G unless > > > > the caller opts into using the full range. This was done to allow > > > > usersapce the opportunity to transition slowly from a 32b address > > > > space, and to avoid breaking inherent 32b assumptions of some > > commands. > > > > > > > > However, for insert we limited ourselves to 4G-4K, but on > > > > verification we allowed the full 4G. This causes some attempts to > > > > bind a new buffer to sporadically fail with -ENOSPC, but at other times be > > bound successfully. > > > > > > > > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 > > > > page") suggests that there is a genuine problem with stateless > > > > addressing that cannot utilize the last page in 4G and so we purposefully > > excluded it. > > > > > > > > Reported-by: CQ Tang > > > > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 > > > > page") > > > > Signed-off-by: Chris Wilson > > > > Cc: CQ Tang > > > > Cc: stable@vger.kernel.org > > > > --- > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > > > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > > > > index 193996144c84..2ff32daa50bd 100644 > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > > > > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct > > > > drm_i915_gem_exec_object2 *entry, > > > > return true; > > > > > > > > if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) && > > > > - (vma->node.start + vma->node.size - 1) >> 32) > > > > + (vma->node.start + vma->node.size + 4095) >> 32) > > > > > > Why 4095 not 4096? > > > > It's the nature of the test that we need an inclusive bound. > > > > Consider an object of size 4G - 4K, that is allowed to fit within our 32b GTT. > > > > 4G - 4k + 4K = 4G == 1 << 32: => vma misplaced > > > > 4G - 4k + 4k - 1 = 4G -1 = 0xffffffff => vma ok > > How do we trigger this code? I run gem_exec_params@larger-than-life-batch but did not see this code is executed. > Basically how do we triggre first attempt to pin the object in place. It's the first pin tried, but the incoming execobj.offset must be available and the object itself must be ready to be pinned. That's true for the current tree on all current gen. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx