Re: [Intel-gfx] [PATCH v4 3/5] drm/i915: Introduce guard pages to i915_vma

[Tvrtko Ursulin]

On 01/12/2022 10:45, Andi Shyti wrote:

Hi Tvrtko,

[...]


@@ -768,8 +773,17 @@ 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 */
+   if (flags & PIN_OFFSET_GUARD) {
+   GEM_BUG_ON(overflows_type(flags & PIN_OFFSET_MASK, u32));
+   guard = max_t(u32, guard, flags & PIN_OFFSET_MASK);
+   }
+   roundup(guard, BIT(vma->vm->scratch_order + PAGE_SHIFT));


roundup = ?


ehehe... yes, please ignore, that's some copy/paste error during
the rebase...


Lets have a comment here as well.

/*
  * Be efficient with PTE use by using the native size for the guard.
  */

Would that be accurate?


and I also forgot the update of my previous comment... yours is
quite accurate.


+
start = flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
GEM_BUG_ON(!IS_ALIGNED(start, I915_GTT_PAGE_SIZE));
+   /* We need to be sure we do not ecceed the va area */
+   GEM_BUG_ON(2 * guard > end);


"exceed" but haven't we said this is not needed?


I wrote it in the cover letter. I had an offline chat with Chris
and he was keen to have this check not only for overflow
protection but also for a documentation purpose so that the
reader knows better about the size and usage of the guard.

Does it make sense?


Not to me really, I have no idea how could anyone ever end up with guard 
size of half+ of GGTT. And the total 2 * guard + size is checked and 
rejected already. So I have no idea what it is supposed to be 
documenting. GEM_BUG_ON suggests really bad things would happen if that 
was passed in, like something would be incorrectly calculated. If that 
is not the case and things would just safely fail then it is just 
confusing to have it.


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH v4 3/5] drm/i915: Introduce guard pages to i915_vma

[Andi Shyti]

Hi Tvrtko,

[...]

> > @@ -768,8 +773,17 @@ 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 */
> > +   if (flags & PIN_OFFSET_GUARD) {
> > +   GEM_BUG_ON(overflows_type(flags & PIN_OFFSET_MASK, u32));
> > +   guard = max_t(u32, guard, flags & PIN_OFFSET_MASK);
> > +   }
> > +   roundup(guard, BIT(vma->vm->scratch_order + PAGE_SHIFT));
> 
> roundup = ?

ehehe... yes, please ignore, that's some copy/paste error during
the rebase...

> Lets have a comment here as well.
> 
> /*
>  * Be efficient with PTE use by using the native size for the guard.
>  */
> 
> Would that be accurate?

and I also forgot the update of my previous comment... yours is
quite accurate.

> > +
> > start = flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
> > GEM_BUG_ON(!IS_ALIGNED(start, I915_GTT_PAGE_SIZE));
> > +   /* We need to be sure we do not ecceed the va area */
> > +   GEM_BUG_ON(2 * guard > end);
> 
> "exceed" but haven't we said this is not needed?

I wrote it in the cover letter. I had an offline chat with Chris
and he was keen to have this check not only for overflow
protection but also for a documentation purpose so that the
reader knows better about the size and usage of the guard.

Does it make sense?

Thanks a lot!

Andi

Re: [Intel-gfx] [PATCH v4 3/5] drm/i915: Introduce guard pages to i915_vma

[Tvrtko Ursulin]

On 30/11/2022 23:58, 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 
---
  drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 ++---
  drivers/gpu/drm/i915/i915_gem_gtt.h  |  3 +-
  drivers/gpu/drm/i915/i915_vma.c  | 40 +++-
  drivers/gpu/drm/i915/i915_vma.h  |  5 +--
  drivers/gpu/drm/i915/i915_vma_resource.c |  4 +--
  drivers/gpu/drm/i915/i915_vma_resource.h |  7 -
  drivers/gpu/drm/i915/i915_vma_types.h|  1 +
  7 files changed, 57 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 7644738b9cdbe..784d4a8c43ba9 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -296,8 +296,11 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
 */
  
  	gte = (gen8_pte_t __iomem *)ggtt->gsm;

-   gte += vma_res->start / I915_GTT_PAGE_SIZE;
-   end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE;
+   gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE;
+   end = gte + vma_res->guard / I915_GTT_PAGE_SIZE;
+   while (gte < end)
+   gen8_set_pte(gte++, vm->scratch[0]->encode);
+   end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE;
  
  	for_each_sgt_daddr(addr, iter, vma_res->bi.pages)

gen8_set_pte(gte++, pte_encode | addr);
@@ -347,9 +350,12 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
dma_addr_t addr;
  
  	gte = (gen6_pte_t __iomem *)ggtt->gsm;

-   gte += vma_res->start / I915_GTT_PAGE_SIZE;
-   end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE;
+   gte += (vma_res->start - vma_res->guard) / I915_GTT_PAGE_SIZE;
  
+	end = gte + vma_res->guard / I915_GTT_PAGE_SIZE;

+   while (gte < end)
+   iowrite32(vm->scratch[0]->encode, gte++);
+   end += (vma_res->node_size + vma_res->guard) / I915_GTT_PAGE_SIZE;
for_each_sgt_daddr(addr, iter, vma_res->bi.pages)
iowrite32(vm->pte_encode(addr, level, flags), gte++);
GEM_BUG_ON(gte > end);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8c2f57eb5ddaa..2434197830523 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -44,7 +44,8 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
  #define PIN_HIGH  BIT_ULL(5)
  #define PIN_OFFSET_BIAS   BIT_ULL(6)
  #define PIN_OFFSET_FIXED  BIT_ULL(7)
-#define PIN_VALIDATE   BIT_ULL(8) /* validate placement only, no need 
to call unpin() */
+#define PIN_OFFSET_GUARD   BIT_ULL(8)
+#define PIN_VALIDATE   BIT_ULL(9) /* validate placement only, no need 
to call unpin() */
  
  #define PIN_GLOBAL		BIT_ULL(10) /* I915_VMA_GLOBAL_BIND */

  #define PIN_USER  BIT_ULL(11) /* I915_VMA_LOCAL_BIND */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index fefee5fef38d3..3877847179710 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -419,7 +419,7 @@ i915_vma_resource_init_from_vma(struct i915_vma_resource 
*vma_res,
   obj->mm.rsgt, i915_gem_object_is_readonly(obj),
   i915_gem_object_is_lmem(obj), obj->mm.region,
   vma->ops, vma->private, __i915_vma_offset(vma),
-