[Intel-gfx] [PATCH] drm/i915: reinstate call to trace_i915_vma_bind

From: Daniele Ceraolo Spurio The call went away in: commit 3b16525cc4c1a43e9053cfdc414356eea24bdfad Author: Chris Wilson Date: Thu Aug 4 16:32:25 2016 +0100 drm/i915: Split insertion/binding of an object into the VM It is

[Intel-gfx] [PATCH] drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

From: Daniele Ceraolo Spurio The mmio_start offset for the whitelist is the first FORCE_TO_NONPRIV register the GuC can use to restore the provided whitelist when an engine reset via GuC (which we still don't support) is triggered. We're currently adding the

[Intel-gfx] [PATCH 2/2] drm/i915: re-use computed offset bias for context pin

From: Daniele Ceraolo Spurio The context has to obey the same offset requirements as the ring, so we can re-use the same bias value we computed for the ring instead of unconditionally using GUC_WOPCM_TOP. Suggested-by: Chris Wilson

[Intel-gfx] [PATCH v2 1/2] drm/i915: request ring to be pinned above GUC_WOPCM_TOP

From: Daniele Ceraolo Spurio GuC will validate the ring offset and fail if it is in the [0, GUC_WOPCM_TOP) range. The bias is conditionally applied only if GuC loading is enabled (we can't check for guc submission enabled as in other cases because HuC loading

[Intel-gfx] [PATCH] drm/i915: request ring to be pinned above GUC_WOPCM_TOP

From: Daniele Ceraolo Spurio GuC will validate the ring offset and fail if it is in the [0, GUC_WOPCM_TOP) range. Signed-off-by: Daniele Ceraolo Spurio Cc: Chris Wilson Cc: Michal Wajdeczko

[Intel-gfx] [PATCH i-g-t v4 1/2] lib: move i915_wedged_set to ig_gt.c

From: Daniele Ceraolo Spurio Upcoming tests will call it to recover from bad states caused by hangcheck bugs.the function was renamed to igt_force_gpu_reset to have a naming closer to other hang-related functions in the same file. The value written to the

[Intel-gfx] [PATCH i-g-t v4 2/2] tests/drv_hangman: test for acthd increasing through invalid VM space

From: Daniele Ceraolo Spurio The hangcheck logic will not flag an hang if acthd keeps increasing. However, if a malformed batch jumps to an invalid offset in the ppgtt it can potentially continue executing through the whole address space without triggering the

[Intel-gfx] [PATCH i-g-t v3] tests/drv_hangman: test for acthd increasing through invalid VM space

From: Daniele Ceraolo Spurio The hangcheck logic will not flag an hang if acthd keeps increasing. However, if a malformed batch jumps to an invalid offset in the ppgtt it can potentially continue executing through the whole address space without triggering the

[Intel-gfx] [PATCH i-g-t] tests/gem_exec_params: test all valid execution flags

From: Daniele Ceraolo Spurio The control subtest has been extended to check the execution flags for all the rings that are present in the HW. Cc: Chris Wilson Signed-off-by: Daniele Ceraolo Spurio ---

[Intel-gfx] [PATCH i-g-t] tests/gem_exec_basic: don't use gem_require_ring to check ring availability

From: Daniele Ceraolo Spurio gem_require_ring will submit an execbuf using the provided flags and skip the test if the ioctl fails. This test is however designed to catch issues with the ioctl, so it should fail if the ioctl fails on a ring that the HW possesses.

[Intel-gfx] [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem

From: Daniele Ceraolo Spurio While running some tests on the scheduler patches with rpm enabled I came across a corruption in the ringbuffer, which was root-caused to the GPU being suspended while commands were being emitted to the ringbuffer. The access to

[Intel-gfx] [RFC] drm/i915: check that rpm ref is held when writing to ringbuf in stolen mem

From: Daniele Ceraolo Spurio While running some tests on the scheduler patches with rpm enabled I came across a corruption in the ringbuffer, which was root-caused to the GPU being suspended while commands were being emitted to the ringbuffer. The access to

[Intel-gfx] [PATCH v2] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem

From: Daniele Ceraolo Spurio While running some tests on the scheduler patches with rpm enabled I came across a corruption in the ringbuffer, which was root-caused to the GPU being suspended while commands were being emitted to the ringbuffer. The access to

[Intel-gfx] [PATCH i-g-t] tests/gem_ctx_param_basic.c: fix non-root-set-no-zeromap subtest

From: Daniele Ceraolo Spurio The test expects an ioctl failure when it tries to set CONTEXT_PARAM_NO_ZEROMAP from a non-root process. However, there is no requirement in the kernel for the user to be root to set this parameter, so the test is failing (it never

[Intel-gfx] [PATCH i-g-t] tests/gem_bad_reloc: use correct page table size

From: Daniele Ceraolo Spurio 2 subparts of gem_bad_reloc check that the reloc address is below the global gtt boundary. However, when executing from ppgtt the reloc address can be greater than that and still be a valid address. To be sure that we're using the

[Intel-gfx] [PATCH] [i-g-t] tests/gem_cs_tlb: fix hardcoded ring id

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com The test has 4 subparts, one for each ring, but internally they all submit to ring 0. Fix it to use the provided ring_id --- tests/gem_cs_tlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/gem_cs_tlb.c

[Intel-gfx] [PATCH v4] [i-g-t] tests/gem_ppgtt: Check for vm leaks with flink and ppgtt

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com Using imported objects should not leak i915 vmas (and vms). In practice this simulates Xorg importing fbcon and leaking (or not) one vma per Xorg startup cycle. v2: use low-level ioctl wrappers and bo offset to check the leak (Chris)

[Intel-gfx] [PATCH v4] [i-g-t] tests/gem_ppgtt: Check for vm leaks with flink and ppgtt

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com Using imported objects should not leak i915 vmas (and vms). In practice this simulates Xorg importing fbcon and leaking (or not) one vma per Xorg startup cycle. v2: use low-level ioctl wrappers and bo offset to check the leak (Chris)

[Intel-gfx] [PATCH v2] [i-g-t] tests/gem_ppgtt: Check for vm leaks with flink and ppgtt

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com From: Tvrtko Ursulin tvrtko.ursu...@intel.com Using imported objects should not leak i915 vmas (and vms). In practice this simulates Xorg importing fbcon and leaking (or not) one vma per Xorg startup cycle. v2: use low-level ioctl

[Intel-gfx] [PATCH v3] [i-g-t] tests/gem_ppgtt: Check for vm leaks with flink and ppgtt

From: Tvrtko Ursulin tvrtko.ursu...@intel.com Using imported objects should not leak i915 vmas (and vms). In practice this simulates Xorg importing fbcon and leaking (or not) one vma per Xorg startup cycle. v2: use low-level ioctl wrappers and bo offset to check the leak (Chris) v3: use the

[Intel-gfx] [PATCH v7] drm/i915: Add tracepoints to track a vm during its lifetime

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com - ppgtt init/release: these tracepoints are useful for observing the creation and destruction of Full PPGTTs. - ctx create/free: we can use the ctx_free trace in combination with the ppgtt_release one to be sure that the ppgtt

[Intel-gfx] [PATCH v6] drm/i915: Add tracepoints to track a vm during its lifetime

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com - ppgtt init/release: these tracepoints are useful for observing the creation and destruction of Full PPGTTs. - ctx create/free: we can use the ctx_free trace in combination with the ppgtt_release one to be sure that the ppgtt

[Intel-gfx] [PATCH v5] drm/i915: Add ppgtt create/release trace points

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com These tracepoints are useful for observing the creation and destruction of Full PPGTTs. v4: add DOC information v5: pull the DOC in drm.tmpl Signed-off-by: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com ---

[Intel-gfx] [PATCH v4] drm/i915: Add ppgtt create/release trace points

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com These tracepoints are useful for observing the creation and destruction of Full PPGTTs. v4: add DOC information Signed-off-by: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com --- drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +++

[Intel-gfx] [PATCH v3] drm/i915: Add ppgtt create/release trace points

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com These tracepoints are useful for observing the creation and destruction of Full PPGTTs. Signed-off-by: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com --- drivers/gpu/drm/i915/i915_gem_gtt.c | 4

[Intel-gfx] [RFC v2 0/3] drm/i915: Trace point callbacks for kernel validation

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com The callbacks are useful for validation because they can be used to extract real-time information from the kernel. v2: duplicate the i915_gem_ring_dispatch trace instead of modifying the existing one. I plan to resubmit these

[Intel-gfx] [RFC v2 3/3] drm/i915: Trace point callbacks for validation

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com These callbacks can be assigned to specific functions inside an external validation kernel module. This module can then extract run-time information to make sure everything is working as expected. Specifically, these two callbacks

[Intel-gfx] [RFC v2 2/3] drm/i915: duplicate i915_gem_ring_dispatch trace and add ctx parameter

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com The context used to execute a batchbuffer is becoming increasingly important. Duplicating to avoid modifications to the original trace. Signed-off-by: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com ---

[Intel-gfx] [PATCH 2/3] drm/i915: Add ctx param to i915_gem_ring_dispatch trace point

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com The context used to execute a batchbuffer is becoming increasingly important. Signed-off-by: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-

[Intel-gfx] [PATCH 1/3] drm/i915: Add ppgtt init/release trace points

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com These tracepoints are useful for observing the creation and destruction of Full PPGTTs. Signed-off-by: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com --- drivers/gpu/drm/i915/i915_gem_context.c | 6 +

[Intel-gfx] [PATCH 3/3] drm/i915: Trace point callbacks for validation

From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com These callbacks can be assigned to specific functions inside an external validation kernel module. This module can then extract run-time information to make sure everything is working as expected. Specifically, these two callbacks