All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Bragg <robert@sixbynine.org>
To: intel-gfx@lists.freedesktop.org
Cc: David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	Sourab Gupta <sourab.gupta@intel.com>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: [PATCH v2] drm/i915: don't whitelist oacontrol in cmd parser
Date: Tue,  8 Nov 2016 12:51:48 +0000	[thread overview]
Message-ID: <20161108125148.25007-1-robert@sixbynine.org> (raw)
In-Reply-To: <20161107194957.3385-5-robert@sixbynine.org>

This v2 patch bumps the command parser version so it can be referenced in
corresponding i-g-t gem_exec_parse changes.

--- >8 ---

Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL via a batch buffer isn't able to report useable
data without a more complete OA unit configuration. Mesa handles the
possibility that writes to OACONTROL may not be allowed and so only
advertises the extension after explicitly testing that a write to
OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
should be ok for userspace.

Removing this simplifies adding a new kernel api for configuring the OA
unit without needing to consider the possibility that userspace might
trample on OACONTROL state which we'd like to start managing within
the kernel instead. In particular running any Mesa based GL application
currently results in clearing OACONTROL when initializing which would
disable the capturing of metrics.

v2:
    This bumps the command parser version from 8 to 9, as the change is
    visible to userspace.

Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Sourab Gupta <sourab.gupta@intel.com>
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 42 ++++------------------------------
 1 file changed, 5 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
index c9d2ecd..f5762cd 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -450,7 +450,6 @@ static const struct drm_i915_reg_descriptor gen7_render_regs[] = {
 	REG64(PS_INVOCATION_COUNT),
 	REG64(PS_DEPTH_COUNT),
 	REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-	REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
 	REG64(MI_PREDICATE_SRC0),
 	REG64(MI_PREDICATE_SRC1),
 	REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1060,8 +1059,7 @@ bool intel_engine_needs_cmd_parser(struct intel_engine_cs *engine)
 static bool check_cmd(const struct intel_engine_cs *engine,
 		      const struct drm_i915_cmd_descriptor *desc,
 		      const u32 *cmd, u32 length,
-		      const bool is_master,
-		      bool *oacontrol_set)
+		      const bool is_master)
 {
 	if (desc->flags & CMD_DESC_SKIP)
 		return true;
@@ -1099,31 +1097,6 @@ static bool check_cmd(const struct intel_engine_cs *engine,
 			}
 
 			/*
-			 * OACONTROL requires some special handling for
-			 * writes. We want to make sure that any batch which
-			 * enables OA also disables it before the end of the
-			 * batch. The goal is to prevent one process from
-			 * snooping on the perf data from another process. To do
-			 * that, we need to check the value that will be written
-			 * to the register. Hence, limit OACONTROL writes to
-			 * only MI_LOAD_REGISTER_IMM commands.
-			 */
-			if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
-				if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
-					DRM_DEBUG_DRIVER("CMD: Rejected LRM to OACONTROL\n");
-					return false;
-				}
-
-				if (desc->cmd.value == MI_LOAD_REGISTER_REG) {
-					DRM_DEBUG_DRIVER("CMD: Rejected LRR to OACONTROL\n");
-					return false;
-				}
-
-				if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1))
-					*oacontrol_set = (cmd[offset + 1] != 0);
-			}
-
-			/*
 			 * Check the value written to the register against the
 			 * allowed mask/value pair given in the whitelist entry.
 			 */
@@ -1214,7 +1187,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs *engine,
 	u32 *cmd, *batch_end;
 	struct drm_i915_cmd_descriptor default_desc = noop_desc;
 	const struct drm_i915_cmd_descriptor *desc = &default_desc;
-	bool oacontrol_set = false; /* OACONTROL tracking. See check_cmd() */
 	bool needs_clflush_after = false;
 	int ret = 0;
 
@@ -1270,8 +1242,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs *engine,
 			break;
 		}
 
-		if (!check_cmd(engine, desc, cmd, length, is_master,
-			       &oacontrol_set)) {
+		if (!check_cmd(engine, desc, cmd, length, is_master)) {
 			ret = -EACCES;
 			break;
 		}
@@ -1279,11 +1250,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs *engine,
 		cmd += length;
 	}
 
-	if (oacontrol_set) {
-		DRM_DEBUG_DRIVER("CMD: batch set OACONTROL but did not clear it\n");
-		ret = -EINVAL;
-	}
-
 	if (cmd >= batch_end) {
 		DRM_DEBUG_DRIVER("CMD: Got to the end of the buffer w/o a BBE cmd!\n");
 		ret = -EINVAL;
@@ -1336,6 +1302,8 @@ int i915_cmd_parser_get_version(struct drm_i915_private *dev_priv)
 	 * 8. Don't report cmd_check() failures as EINVAL errors to userspace;
 	 *    rely on the HW to NOOP disallowed commands as it would without
 	 *    the parser enabled.
+	 * 9. Don't whitelist or handle oacontrol specially, as ownership
+	 *    for oacontrol state is moving to i915-perf.
 	 */
-	return 8;
+	return 9;
 }
-- 
2.10.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-11-08 12:51 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-07 19:49 [PATCH v9 00/11] Enable i915 perf stream for Haswell OA unit Robert Bragg
2016-11-07 19:49 ` [PATCH v9 01/11] drm/i915: Add i915 perf infrastructure Robert Bragg
2016-11-09 20:00   ` Matthew Auld
2016-11-22 13:29     ` [Intel-gfx] " Daniel Vetter
2016-11-22 13:31       ` Daniel Vetter
2016-11-22 14:02         ` [Intel-gfx] " Robert Bragg
2016-11-22 15:35           ` Daniel Vetter
2016-11-07 19:49 ` [PATCH v9 02/11] drm/i915: rename OACONTROL GEN7_OACONTROL Robert Bragg
2016-11-07 19:49 ` [PATCH v9 03/11] drm/i915: return EACCES for check_cmd() failures Robert Bragg
2016-11-07 19:49 ` [PATCH v9 04/11] drm/i915: don't whitelist oacontrol in cmd parser Robert Bragg
2016-11-08 12:51   ` Robert Bragg [this message]
2016-11-22 13:34     ` [Intel-gfx] [PATCH v2] " Daniel Vetter
2016-11-22 14:09       ` Robert Bragg
2016-11-22 15:36         ` Daniel Vetter
2016-11-07 19:49 ` [PATCH v9 05/11] drm/i915: Add 'render basic' Haswell OA unit config Robert Bragg
2016-11-08  6:04   ` sourab gupta
2016-11-07 19:49 ` [PATCH v9 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit Robert Bragg
2016-11-15  9:24   ` sourab gupta
2016-11-07 19:49 ` [PATCH v9 07/11] drm/i915: advertise available metrics via sysfs Robert Bragg
2016-11-07 19:49 ` [PATCH v9 08/11] drm/i915: Add dev.i915.perf_stream_paranoid sysctl option Robert Bragg
2016-11-07 19:49 ` [PATCH v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl Robert Bragg
2016-11-08  6:19   ` sourab gupta
2016-11-08 11:47     ` Robert Bragg
2016-11-08 12:14       ` sourab gupta
2016-11-09 19:52   ` Matthew Auld
2016-11-10 13:57     ` Robert Bragg
2016-11-07 19:49 ` [PATCH v9 10/11] drm/i915: Add more Haswell OA metric sets Robert Bragg
2016-11-07 19:49 ` [PATCH v9 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c Robert Bragg
2016-11-08  6:27   ` sourab gupta
2016-11-22 13:43   ` Daniel Vetter
2016-11-07 20:14 ` ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit Patchwork
2016-11-08 13:19 ` ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit (rev2) Patchwork

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=20161108125148.25007-1-robert@sixbynine.org \
    --to=robert@sixbynine.org \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=sourab.gupta@intel.com \
    /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.