Without opting into 48B addressing, objects are strictly limited to
being placed only the first (4G - 4K). This is to avoid an issue with
stateless 32b addressing being unable to access the last 32b page.
Assert that we do indeed fail to fit in a 4G object without setting the
EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag.
Reported-by: CQ Tang <cq.t...@intel.com>
References:: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: CQ Tang <cq.t...@intel.com>
---
tests/i915/gem_exec_params.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index c405f4eb7..e679c512a 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -340,7 +340,13 @@ static void test_larger_than_life_batch(int fd)
for_each_engine(e, fd) {
/* Keep the batch_len implicit [0] */
execbuf.flags = eb_ring(e);
- gem_execbuf(fd, &execbuf);
+
+ /* non-48b objects are limited to the low (4G - 4K) */
+ igt_assert_eq(__gem_execbuf(fd, &execbuf), -ENOSPC);
+
+ exec.flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+ igt_assert_eq(__gem_execbuf(fd, &execbuf), 0);
+ exec.flags = 0;
}
gem_sync(fd, exec.handle);
--
2.29.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
