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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 1582FC4321E for ; Fri, 2 Dec 2022 12:38:50 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 24F5F10E18B; Fri, 2 Dec 2022 12:38:41 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id E744A10E6E3; Fri, 2 Dec 2022 12:38:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669984716; x=1701520716; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=9YP/9ZcHz3tEC4PSjp6JBrVKRvDaVTB1z5m2auiLJlM=; b=M4Qw3XO32hlp2S1ebZt15uCdcuSUvyizNziJGtcrKlLUjldGYNshqZdO BVNAMG13GFn1vfPQJ3mF+4OljsR5gkY1a5A00zzxtoXEfwikG84jYX/y8 AGCpd/8Q2kJ5wuP7QVop/Nkv8YJ+XsBA7Y/pMayyOo3EY4l3s5enw2Pmf ujXF62FdlgobRVrtPbkftXdlLVO33VqsB3y8AHXroqUF/4zRutSxTTAnU bSY5NxIeBHU0vanqEcNFqvXz9j0vVT4oqlF2oE3C3dirNQNcYwf713uMC lH807N9rz84UeyMz3J86rPp3NW86N0FSYh5hXy7Ju9Gci0rtj+PtKmnKL Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="296299292" X-IronPort-AV: E=Sophos;i="5.96,212,1665471600"; d="scan'208";a="296299292" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 04:38:36 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="647155619" X-IronPort-AV: E=Sophos;i="5.96,212,1665471600"; d="scan'208";a="647155619" Received: from macematx-mobl1.ger.corp.intel.com (HELO [10.213.211.34]) ([10.213.211.34]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 04:38:34 -0800 Message-ID: <170ec9a0-10e2-9413-31de-7694854e903f@linux.intel.com> Date: Fri, 2 Dec 2022 12:38:32 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US To: Andi Shyti References: <20221201144446.333776-1-andi.shyti@linux.intel.com> <20221201203912.346110-1-andi.shyti@linux.intel.com> <8a8152b6-a7f9-7ecb-4e5b-2b961f8e3ee2@linux.intel.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Intel-gfx] [PATCH v6 3/5] drm/i915: Introduce guard pages to i915_vma 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: =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= , intel-gfx@lists.freedesktop.org, Matthew Auld , dri-devel@lists.freedesktop.org, Chris Wilson Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On 02/12/2022 11:11, Andi Shyti wrote: > Hi Tvrtko, > > On Fri, Dec 02, 2022 at 10:20:11AM +0000, Tvrtko Ursulin wrote: >> >> On 01/12/2022 20:39, Andi Shyti wrote: >>> From: Chris Wilson >>> >>> Introduce the concept of padding the i915_vma with guard pages before >>> and after. The major consequence is that all ordinary uses of i915_vma >>> must use i915_vma_offset/i915_vma_size and not i915_vma.node.start/size >>> directly, as the drm_mm_node will include the guard pages that surround >>> our object. >>> >>> The biggest connundrum is how exactly to mix requesting a fixed address >>> with guard pages, particularly through the existing uABI. The user does >>> not know about guard pages, so such must be transparent to the user, and >>> so the execobj.offset must be that of the object itself excluding the >>> guard. So a PIN_OFFSET_FIXED must then be exclusive of the guard pages. >>> The caveat is that some placements will be impossible with guard pages, >>> as wrap arounds need to be avoided, and the vma itself will require a >>> larger node. We must not report EINVAL but ENOSPC as these are unavailable >>> locations within the GTT rather than conflicting user requirements. >>> >>> In the next patch, we start using guard pages for scanout objects. While >>> these are limited to GGTT vma, on a few platforms these vma (or at least >>> an alias of the vma) is shared with userspace, so we may leak the >>> existence of such guards if we are not careful to ensure that the >>> execobj.offset is transparent and excludes the guards. (On such platforms >>> like ivb, without full-ppgtt, userspace has to use relocations so the >>> presence of more untouchable regions within its GTT such be of no further >>> issue.) >>> >>> Signed-off-by: Chris Wilson >>> Signed-off-by: Tejas Upadhyay >>> Signed-off-by: Tvrtko Ursulin >>> Signed-off-by: Andi Shyti >>> --- >>> Hi Tvrtko, >>> >>> I removed your r-b in this version because I restored the original value >>> of the guard being aligned with the vma size alignment. Turns out that >>> CI failed with the latest version because the guard was becoming too big >>> (we would have hit the GEM_BUG_ON)[*]. >>> >>> The reason why now the guard is aligned with the vma alignment is that >>> the area is already aligned and if we use as a starting address start + >>> guard, guard needs to be aligned, otherwise we screw up all the memory >>> alignment. >>> >>> Let me know if it makes sense to you. >> >> Reviewed-by: Tvrtko Ursulin >> >> Conditional to promise of a prioritised follow up improvement, if it turns >> out GGTT wastage due a bit over zealous guard size comes to bite. > > Sure! I'll be alert! > > There are some unrelated failures from CI, just to be sure I sent > last night a trybot run. Trybot looked okay, and I just pressed re-test for the intel-gfx series so lets see that too. Regards, Tvrtko