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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
