[igt,v4,13/13] igt/gem_exec_parse: check oacontrol lri bad for >= v9

Commit Message

Robert Bragg Nov. 14, 2016, 8:51 p.m. UTC

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 <[e-mail]>
Reviewed-by: Matthew Auld <[e-mail]>
---
 tests/gem_exec_parse.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

Patch

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 43f25ce..cc2103a 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -485,6 +485,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,
@@ -503,6 +519,15 @@  igt_main
 					 bad_lris + i, bad_lri_errno,
 					 bad_lris[i].init_val);
 			}
+
+			if (parser_version >= 9) {
+				for (int i = 0; i < ARRAY_SIZE(v9_bad_lris); i++) {
+					test_lri(fd, handle,
+						 v9_bad_lris + i,
+						 0,
+						 v9_bad_lris[i].init_val);
+				}
+			}
 		}
 
 		igt_fixture {