forked from Minki/linux
d23db88c3a
This is pure evil. Userspace, I'm looking at you SNA, repacks batch buffers on the fly after generation as they are being passed to the kernel for execution. These batches also contain self-referenced relocations as a single buffer encompasses the state commands, kernels, vertices and sampler. During generation the buffers are placed at known offsets within the full batch, and then the relocation deltas (as passed to the kernel) are tweaked as the batch is repacked into a smaller buffer. This means that userspace is passing negative relocations deltas, which subsequently wrap to large values if the batch is at a low address. The GPU hangs when it then tries to use the large value as a base for its address offsets, rather than wrapping back to the real value (as one would hope). As the GPU uses positive offsets from the base, we can treat the relocation address as the minimum address read by the GPU. For the upper bound, we trust that userspace will not read beyond the end of the buffer. So, how do we fix negative relocations from wrapping? We can either check that every relocation looks valid when we write it, and then position each object such that we prevent the offset wraparound, or we just special-case the self-referential behaviour of SNA and force all batches to be above 256k. Daniel prefers the latter approach. This fixes a GPU hang when it tries to use an address (relocation + offset) greater than the GTT size. The issue would occur quite easily with full-ppgtt as each fd gets its own VM space, so low offsets would often be handed out. However, with the rearrangement of the low GTT due to capturing the BIOS framebuffer, it is already affecting kernels 3.15 onwards. I think only IVB+ is susceptible to this bug, but the workaround should only kick in rarely, so it seems sensible to always apply it. v3: Use a bias for batch buffers to prevent small negative delta relocations from wrapping. v4 from Daniel: - s/BIAS/BATCH_OFFSET_BIAS/ - Extract eb_vma_misplaced/i915_vma_misplaced since the conditions were growing rather cumbersome. - Add a comment to eb_get_batch explaining why we do this. - Apply the batch offset bias everywhere but mention that we've only observed it on gen7 gpus. - Drop PIN_OFFSET_FIX for now, that slipped in from a feature patch. v5: Add static to eb_get_batch, spotted by 0-day tester. Testcase: igt/gem_bad_reloc Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78533 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> |
||
|---|---|---|
| .. | ||
| dvo_ch7xxx.c | ||
| dvo_ch7017.c | ||
| dvo_ivch.c | ||
| dvo_ns2501.c | ||
| dvo_sil164.c | ||
| dvo_tfp410.c | ||
| dvo.h | ||
| i915_cmd_parser.c | ||
| i915_debugfs.c | ||
| i915_dma.c | ||
| i915_drv.c | ||
| i915_drv.h | ||
| i915_gem_context.c | ||
| i915_gem_debug.c | ||
| i915_gem_dmabuf.c | ||
| i915_gem_evict.c | ||
| i915_gem_execbuffer.c | ||
| i915_gem_gtt.c | ||
| i915_gem_stolen.c | ||
| i915_gem_tiling.c | ||
| i915_gem.c | ||
| i915_gpu_error.c | ||
| i915_ioc32.c | ||
| i915_irq.c | ||
| i915_params.c | ||
| i915_reg.h | ||
| i915_suspend.c | ||
| i915_sysfs.c | ||
| i915_trace_points.c | ||
| i915_trace.h | ||
| i915_ums.c | ||
| intel_acpi.c | ||
| intel_bios.c | ||
| intel_bios.h | ||
| intel_crt.c | ||
| intel_ddi.c | ||
| intel_display.c | ||
| intel_dp.c | ||
| intel_drv.h | ||
| intel_dsi_cmd.c | ||
| intel_dsi_cmd.h | ||
| intel_dsi_pll.c | ||
| intel_dsi.c | ||
| intel_dsi.h | ||
| intel_dvo.c | ||
| intel_fbdev.c | ||
| intel_hdmi.c | ||
| intel_i2c.c | ||
| intel_lvds.c | ||
| intel_modes.c | ||
| intel_opregion.c | ||
| intel_overlay.c | ||
| intel_panel.c | ||
| intel_pm.c | ||
| intel_ringbuffer.c | ||
| intel_ringbuffer.h | ||
| intel_sdvo_regs.h | ||
| intel_sdvo.c | ||
| intel_sideband.c | ||
| intel_sprite.c | ||
| intel_tv.c | ||
| intel_uncore.c | ||
| Kconfig | ||
| Makefile | ||