[Intel-gfx] [RFC] Fixing up relocation of secure buffers?

[Chris Wilson]

On Mon, Apr 11, 2016 at 07:47:12PM +0100, Dave Gordon wrote:
> Hi,
> 
> background to this is that one of our validation engineers has written
> a test that creates a batch that loops by jumping backwards using
> MI_BATCH_BUFFER_START to an address earlier in the batchbuffer, with
> whatever instruction sequence is being tested inside the loop.
> 
> This works perfectly well for normal cases, but in some cases the
> instruction to be tested is privileged, so the batch has to be submitted
> with the I915_DISPATCH_SECURE flag.
> 
> In this case, although the batch executes correctly on the first pass,
> the jump backwards doesn't. It appears that the relocation process has
> inserted a PPGTT-based address for the target, whereas the opcode in
> the batch has the GGTT bit set (as required for jumping to a privileged
> batch). The result is effectively a random jump :(

Tricky. Problem here is that even some relocations will read from the
ppgtt but a few will read from the ggtt. I was going to suggest a second
relocation pass for the ggtt secure batch - but we can't tell which will
be which. We do have the NEEDS_GGTT execobject flag, but that is not
allowed on full-ppgtt (atm). We could look for a read_domain = COMMAND,
but that will likely end up in confusion - though at first glance that
seems good enough.

So a second relocation pass for the secure batch applying the GGTT
offset to self-relocations with read_domain == COMMAND? (Being sure not
to apply the pass to promoted cmdparser batches.) The
relocation[].presumed_offsets should be set to -1, as should the
execobject.offset since the relocations are then inconsistent.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre