igt/gem_exec_await: Tag the final batch in the GTT

Batches are constrained in their position within the GTT by the kernel,
and if they are in an invalid position will be unbound and rebound
before execution. In our test setup, we therefore need to place the
batch into a valid poistion within the GTT before we fill the ring with
busyspinners.

The problem entirely lies in how we are constructing our set of busy
spinning batches. We try to fill the ring with a chain of batches that
are all linked to one buffer, and then try to execute that buffer. This
gives us the most implicit fences on that one buffer we can trivially
construct; with the goal being that the kernel handles them all with
aplomb. However, what we failed to take into account was that we might
end up with that final buffer being at address 0, which is in an invalid
location to execute from (because reasons) and the kernel would be
forced to move it. However, since we have a ring full of busy spinners
all using that buffer, we can not move that buffer until we wait for the
queue to complete -- which it never will and so we declare a GPU hang,
failing the test.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Katarzyna Dec <katarzyna.dec@intel.com>

1 files changed, 3 insertions, 0 deletions

diff --git a/tests/gem_exec_await.c b/tests/gem_exec_await.c
index b0d5c904..5cfeb8ec 100644
--- a/tests/gem_exec_await.c
+++ b/tests/gem_exec_await.c
@@ -135,6 +135,9 @@ static void wide(int fd, int ring_size, int timeout, unsigned int flags)
 	gem_write(fd, obj[nengine*ring_size].handle, 0, &bbe, sizeof(bbe));
 
 	memset(&execbuf, 0, sizeof(execbuf));
+	execbuf.buffers_ptr = to_user_pointer(&obj[nengine*ring_size]);
+	execbuf.buffer_count = 1;
+	gem_execbuf(fd, &execbuf); /* tag the object as a batch in the GTT */
 	execbuf.buffers_ptr = to_user_pointer(obj);
 	execbuf.buffer_count = nengine*ring_size + 1;