From: Andi Shyti <andi.shyti@linux.intel.com> To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, "Chris Wilson" <chris@chris-wilson.co.uk>, "Matthew Auld" <matthew.auld@intel.com>, "Andi Shyti" <andi.shyti@linux.intel.com> Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Introduce guard pages to i915_vma Date: Wed, 23 Nov 2022 19:54:21 +0100 [thread overview] Message-ID: <Y35sXXLiAmwulDRU@ashyti-mobl2.lan> (raw) In-Reply-To: <a579e9a5-0bd4-d439-3193-64dc52e05997@linux.intel.com> Hi Tvrtko, [...] > > @@ -768,6 +768,9 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww, > > GEM_BUG_ON(!IS_ALIGNED(alignment, I915_GTT_MIN_ALIGNMENT)); > > GEM_BUG_ON(!is_power_of_2(alignment)); > > + guard = vma->guard; /* retain guard across rebinds */ > > + guard = ALIGN(guard, alignment); > > Why does guard area needs the same alignment as the requested mapping? What about the fact on 32-bit builds guard is 32-bit and alignment u64? I guess this just to round up/down guard to something, not necessarily to that alignment. Shall I remove it? [...] > > @@ -777,6 +780,7 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww, > > if (flags & PIN_ZONE_4G) > > end = min_t(u64, end, (1ULL << 32) - I915_GTT_PAGE_SIZE); > > GEM_BUG_ON(!IS_ALIGNED(end, I915_GTT_PAGE_SIZE)); > > + GEM_BUG_ON(2 * guard > end); > > End is the size of relevant VA area at this point so what and why is this checking? I think because we want to make sure the padding is at least not bigger that the size. What is actually wrong with this. [...] > > @@ -855,6 +869,7 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww, > > GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, color)); > > list_move_tail(&vma->vm_link, &vma->vm->bound_list); > > + vma->guard = guard; > > unsigned long into u32 - what guarantees no truncation? we are missing here this part above: guard = vma->guard; /* retain guard across rebinds */ if (flags & PIN_OFFSET_GUARD) { GEM_BUG_ON(overflows_type(flags & PIN_OFFSET_MASK, u32)); guard = max_t(u32, guard, flags & PIN_OFFSET_MASK); } that should make sure that we fit into 32 bits. [...] > > @@ -197,14 +197,15 @@ struct i915_vma { > > struct i915_fence_reg *fence; > > u64 size; > > - u64 display_alignment; > > struct i915_page_sizes page_sizes; > > /* mmap-offset associated with fencing for this vma */ > > struct i915_mmap_offset *mmo; > > + u32 guard; /* padding allocated around vma->pages within the node */ > > u32 fence_size; > > u32 fence_alignment; > > + u32 display_alignment; > > u64 -> u32 for display_alignment looks unrelated change. > > ./display/intel_fb_pin.c: vma->display_alignment = max_t(u64, vma->display_alignment, alignment); > ./gem/i915_gem_domain.c: vma->display_alignment = max_t(u64, vma->display_alignment, alignment); > > These two sites need to be changed not to use u64. > > Do this part in a separate patch? Right! will remove it. > > /** > > * Count of the number of times this vma has been opened by different > > Regards, Thanks, Andi > Tvrtko
WARNING: multiple messages have this Message-ID (diff)
From: Andi Shyti <andi.shyti@linux.intel.com> To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, "Chris Wilson" <chris@chris-wilson.co.uk>, "Matthew Auld" <matthew.auld@intel.com> Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Introduce guard pages to i915_vma Date: Wed, 23 Nov 2022 19:54:21 +0100 [thread overview] Message-ID: <Y35sXXLiAmwulDRU@ashyti-mobl2.lan> (raw) In-Reply-To: <a579e9a5-0bd4-d439-3193-64dc52e05997@linux.intel.com> Hi Tvrtko, [...] > > @@ -768,6 +768,9 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww, > > GEM_BUG_ON(!IS_ALIGNED(alignment, I915_GTT_MIN_ALIGNMENT)); > > GEM_BUG_ON(!is_power_of_2(alignment)); > > + guard = vma->guard; /* retain guard across rebinds */ > > + guard = ALIGN(guard, alignment); > > Why does guard area needs the same alignment as the requested mapping? What about the fact on 32-bit builds guard is 32-bit and alignment u64? I guess this just to round up/down guard to something, not necessarily to that alignment. Shall I remove it? [...] > > @@ -777,6 +780,7 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww, > > if (flags & PIN_ZONE_4G) > > end = min_t(u64, end, (1ULL << 32) - I915_GTT_PAGE_SIZE); > > GEM_BUG_ON(!IS_ALIGNED(end, I915_GTT_PAGE_SIZE)); > > + GEM_BUG_ON(2 * guard > end); > > End is the size of relevant VA area at this point so what and why is this checking? I think because we want to make sure the padding is at least not bigger that the size. What is actually wrong with this. [...] > > @@ -855,6 +869,7 @@ i915_vma_insert(struct i915_vma *vma, struct i915_gem_ww_ctx *ww, > > GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, color)); > > list_move_tail(&vma->vm_link, &vma->vm->bound_list); > > + vma->guard = guard; > > unsigned long into u32 - what guarantees no truncation? we are missing here this part above: guard = vma->guard; /* retain guard across rebinds */ if (flags & PIN_OFFSET_GUARD) { GEM_BUG_ON(overflows_type(flags & PIN_OFFSET_MASK, u32)); guard = max_t(u32, guard, flags & PIN_OFFSET_MASK); } that should make sure that we fit into 32 bits. [...] > > @@ -197,14 +197,15 @@ struct i915_vma { > > struct i915_fence_reg *fence; > > u64 size; > > - u64 display_alignment; > > struct i915_page_sizes page_sizes; > > /* mmap-offset associated with fencing for this vma */ > > struct i915_mmap_offset *mmo; > > + u32 guard; /* padding allocated around vma->pages within the node */ > > u32 fence_size; > > u32 fence_alignment; > > + u32 display_alignment; > > u64 -> u32 for display_alignment looks unrelated change. > > ./display/intel_fb_pin.c: vma->display_alignment = max_t(u64, vma->display_alignment, alignment); > ./gem/i915_gem_domain.c: vma->display_alignment = max_t(u64, vma->display_alignment, alignment); > > These two sites need to be changed not to use u64. > > Do this part in a separate patch? Right! will remove it. > > /** > > * Count of the number of times this vma has been opened by different > > Regards, Thanks, Andi > Tvrtko
next prev parent reply other threads:[~2022-11-23 18:54 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-22 18:57 [PATCH v2 0/4] Add guard padding around i915_vma Andi Shyti 2022-11-22 18:57 ` [Intel-gfx] " Andi Shyti 2022-11-22 18:57 ` [PATCH v2 1/4] drm/i915: Wrap all access to i915_vma.node.start|size Andi Shyti 2022-11-22 18:57 ` [Intel-gfx] " Andi Shyti 2022-11-23 9:46 ` Tvrtko Ursulin 2022-11-22 18:57 ` [PATCH v2 2/4] drm/i915: Introduce guard pages to i915_vma Andi Shyti 2022-11-22 18:57 ` [Intel-gfx] " Andi Shyti 2022-11-23 11:13 ` Tvrtko Ursulin 2022-11-23 18:54 ` Andi Shyti [this message] 2022-11-23 18:54 ` Andi Shyti 2022-11-24 9:20 ` Andi Shyti 2022-11-24 9:20 ` Andi Shyti 2022-11-24 12:01 ` Tvrtko Ursulin 2022-11-22 18:57 ` [PATCH v2 3/4] drm/i915: Refine VT-d scanout workaround Andi Shyti 2022-11-22 18:57 ` [Intel-gfx] " Andi Shyti 2022-11-22 18:57 ` [PATCH v2 4/4] Revert "drm/i915: Improve on suspend / resume time with VT-d enabled" Andi Shyti 2022-11-22 18:57 ` [Intel-gfx] " Andi Shyti 2022-11-22 21:19 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for add guard padding around i915_vma (rev2) Patchwork 2022-11-22 21:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2022-11-22 21:44 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-11-23 12:23 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Y35sXXLiAmwulDRU@ashyti-mobl2.lan \ --to=andi.shyti@linux.intel.com \ --cc=chris@chris-wilson.co.uk \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=matthew.auld@intel.com \ --cc=thomas.hellstrom@linux.intel.com \ --cc=tvrtko.ursulin@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.