On Mon, 2017-08-28 at 11:46 +0100, Chris Wilson wrote:
> Sometimes we know we are the only user of the bo, but since we take a
> protective pin_pages early on, an attempt to change the vmap on the
> object is denied because it is busy. i915_gem_object_pin_map() cannot
> tell from our single pin_count if the operation is safe. Instead we must
> pass that information down from the caller in the manner of
> I915_MAP_OVERRIDE.
>
> This issue has existed from the introduction of the mapping, but was
> never noticed as the only place where this conflict might happen is for
> cached kernel buffers (such as allocated by i915_gem_batch_pool_get()).
> Until recently there was only a single user (the cmdparser) so no
> conflicts ever occurred. However, we now use it to allocate batches for
> different operations (using MAP_WC on !llc for writes) in addition to the
> existing shadow batch (using MAP_WB for reads).
>
> We could either keep both mappings cached, or use a different write
> mechanism if we detect a MAP_WB already exists (i.e. clflush
> afterwards), but as we haven't seen this issue in the wild (it requires
> hitting the GPU reloc path in addition to the cmdparser) for simplicity
> just allow the mappings to be recreated.
>
> v2: Include the i915_MAP_OVERRIDE bit in the enum so the compiler knows
> about all the valid values.
>
> Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
> Testcase: igt/gem_lut_handle # byt, completely by accident
> Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
