From: Robert Bragg <robert@sixbynine.org>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH igt v3 11/11] igt/gem_exec_parse: check oacontrol lri bad for >= v9
Date: Wed, 9 Nov 2016 16:16:02 +0000 [thread overview]
Message-ID: <20161109161602.2402-12-robert@sixbynine.org> (raw)
In-Reply-To: <20161109161602.2402-1-robert@sixbynine.org>
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@sixbynine.org>
---
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-11-09 16:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 16:15 [PATCH igt v3 00/11] corresponding changes for i915-perf interface Robert Bragg
2016-11-09 16:15 ` [PATCH igt v3 01/11] igt/perf: add i915 perf stream tests for Haswell Robert Bragg
2016-11-09 16:33 ` Chris Wilson
2016-11-10 23:03 ` Matthew Auld
2016-11-14 15:52 ` Robert Bragg
2016-11-09 16:15 ` [PATCH igt v3 02/11] igt/gem_exec_parse: some minor cleanups Robert Bragg
2016-11-11 21:49 ` Matthew Auld
2016-11-09 16:15 ` [PATCH igt v3 03/11] igt/gem_exec_parse: move hsw_load_register_reg down Robert Bragg
2016-11-11 21:51 ` Matthew Auld
2016-11-09 16:15 ` [PATCH igt v3 04/11] igt/gem_exec_parse: update hsw_load_register_reg Robert Bragg
2016-11-11 22:01 ` Matthew Auld
2016-11-09 16:15 ` [PATCH igt v3 05/11] igt/gem_exec_parse: req. v < 9 for oacontrol tracking test Robert Bragg
2016-11-11 22:07 ` Matthew Auld
2016-11-09 16:15 ` [PATCH igt v3 06/11] igt/gem_exec_parse: make basic-rejected version agnostic Robert Bragg
2016-11-14 18:57 ` Matthew Auld
2016-11-09 16:15 ` [PATCH igt v3 07/11] igt/gem_exec_parse: update bitmasks test for v >=8 Robert Bragg
2016-11-11 22:08 ` Matthew Auld
2016-11-09 16:15 ` [PATCH igt v3 08/11] igt/gem_exec_parse: update cmd-crossing-page for >= v8 Robert Bragg
2016-11-11 22:10 ` Matthew Auld
2016-11-09 16:16 ` [PATCH igt v3 09/11] igt/gem_exec_parse: update hsw_load_register_reg for v >= 8 Robert Bragg
2016-11-11 22:14 ` Matthew Auld
2016-11-09 16:16 ` [PATCH igt v3 10/11] igt/gem_exec_parse: update registers test " Robert Bragg
2016-11-11 22:28 ` Matthew Auld
2016-11-09 16:16 ` Robert Bragg [this message]
2016-11-11 22:36 ` [PATCH igt v3 11/11] igt/gem_exec_parse: check oacontrol lri bad for >= v9 Matthew Auld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161109161602.2402-12-robert@sixbynine.org \
--to=robert@sixbynine.org \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.