OACONTROL is no longer white listed in the command parser so this checks
at attempted LRI will be disallowed and (more importantly) checks that
userspace doesn't get an EINVAL error for an attempted OACONTROL LRI.
This is important becase Mesa application attempt OACONTROL LRIs while
initializing and will abort for any execbuf error.
Signed-off-by: Robert Bragg <robert@xxxxxxxxxxxxx>
---
tests/gem_exec_parse.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 0fa3af8..702b6f4 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -457,6 +457,22 @@ igt_main
/* dummy head pointer */
{ OASTATUS2, 0xffffff80, 0xdeadf000, 0xbeeff000 }
};
+ struct test_lri v9_bad_lris[] = {
+ /* It's really important for us to check that
+ * an LRI to OACONTROL doesn't result in an
+ * EINVAL error because Mesa attempts writing
+ * to OACONTROL to determine what extensions to
+ * expose and will abort() for execbuffer()
+ * errors.
+ *
+ * Mesa can gracefully recognise and handle the
+ * LRI becoming a NOOP.
+ *
+ * The test values represent dummy context IDs
+ * while leaving the OA unit disabled
+ */
+ { OACONTROL, 0xfffff000, 0xfeed0000, 0x31337000 }
+ };
struct test_lri ok_lris[] = {
/* NB: [1:0] MBZ */
{ SO_WRITE_OFFSET_0, 0xfffffffc,
@@ -475,6 +491,15 @@ igt_main
bad_lris + i, bad_lri_errno,
bad_lris[i].init_val);
}
+
+ if (parser_version >= 9) {
+ for (int i = 0; i < ARRAY_LEN(v9_bad_lris); i++) {
+ test_lri(fd, handle,
+ v9_bad_lris + i,
+ 0,
+ v9_bad_lris[i].init_val);
+ }
+ }
}
igt_fixture {
--
2.10.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
