[Intel-gfx] [PATCH] drm/i915: Implement vm_ops->access for gdb access into GTT mmaps.

[Chris Wilson]

Quoting Chris Wilson (2017-07-14 00:27:05)
> First question is whether or not we should wait for the gpu. Using
> peekdata/pokedata implies the target thread is stopped, we could infer
> that also means that any gpu tasks are also stopped for the client. (To
> be accurate we would have to flush the requests when the tracee handles
> SIGSTOP.) But without the serialisation, it does mean that the data may
> changed underneath the tracer, which is not intended. (Now there are
> other means for that data to change, it is shared between clients.)
> 
> I'm thinking we actually do want the serialisation -- it should reduce
> the potential strange behaviour under gdb.

A counter point though is that CPU mmaps are not aware of the GPU at
all. Neither waiting for the task, nor ensuring that the read is
coherent. Oh noes, more pressure for gemfs. (And perhaps not so much as
a counter point at all, but that GTT waiting and flushing is the correct
implementation?)

We could after the call to vm_mmap() copy out the shmem_vm_ops and
replace it, or we could add another driver hook to shemfs (but at what
point do we realise the midlayer mistake)?
-Chris