On 24/07/2020 13:19, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-07-24 11:07:18)
On 24/07/2020 12:26, Chris Wilson wrote:
Quoting Umesh Nerlige Ramappa (2020-07-24 01:18:59)
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index febc9e6692ba..3b1d3dbcd477 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -934,6 +934,10 @@ static bool pardon_reg(struct drm_i915_private *i915, i915_reg_t reg)
static const struct regmask pardon[] = {
{ GEN9_CTX_PREEMPT_REG, INTEL_GEN_MASK(9, 9) },
{ GEN8_L3SQCREG4, INTEL_GEN_MASK(9, 9) },
+ { OAREPORTTRIG2, INTEL_GEN_MASK(8, 11) },
+ { OAREPORTTRIG6, INTEL_GEN_MASK(8, 11) },
+ { GEN12_OAG_OAREPORTTRIG2, INTEL_GEN_MASK(12, 12) },
+ { GEN12_OAG_OAREPORTTRIG6, INTEL_GEN_MASK(12, 12) },
Because we are not making the mistake of exposing more globals, and the
pardon is a list of our past sins, not an excuse for more.
I'm afraid the HW design leave us no choice on Gen12 :(
The question then is how much mischief can a client get up to if they
subvert the OA of the privileged user. It's a privilege escalation hole,
but is there anything dangerous behind it? Or is it just going to disturb
the data being fed to the privileged client... (Which seems scary enough.)
-Chris
The trigger registers will allow any other application to generate
reports in the global OA buffer.
If you've built your OA report parsing correctly, this shouldn't be a
problem because you'll filter on context ID prior to the reason of the
report being recorded.
That's a downside of this patch, that's also a feature because you can
use this to monitor particular chunks of work in a global timeline of OA
reports for multiple applications.
-Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
