Quoting Joonas Lahtinen (2017-08-28 14:44:36)
> 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>
And pushed. Only afterwards when looking for the link did I notice I
forgot to mention the bugzilla.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
