[Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] tests/gem_ctx_bad_exec: Consolidate to gem_ctx_exec
Chris Wilson
chris at chris-wilson.co.uk
Tue Sep 18 10:45:42 UTC 2018
Quoting Tvrtko Ursulin (2018-09-18 11:33:14)
>
> On 18/09/2018 11:03, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-09-18 11:02:09)
> >> Quoting Tvrtko Ursulin (2018-09-18 10:59:11)
> >>>
> >>> On 18/09/2018 10:44, Chris Wilson wrote:
> >>>> Quoting Tvrtko Ursulin (2018-09-18 10:38:44)
> >>>>> Can I say it is testing the i915_execbuffer2_set_context_id as well by
> >>>>> knowing underlying ABI field is 64-bit wide and keep the r-b? (No trash
> >>>>> in unused part of rsvd1.)
> >>>>
> >>>> The field isn't 64-bit wide, so the test would be misleading unfortunately.
> >>>
> >>> rsvd1? It is 64-bit in i915_drm.h I am looking at. And ABI is free to
> >>> set it directly.
> >>>
> >>> But true, it seems we are not checking for trash in upper 32-bits in
> >>> execbuf paths.. :(
> >>>
> >>> So this means regardless of what helper does the ABI is actually 64-bit.
> >>> So test should actually bypass the helper I think and set rsvd1 directly
> >>> I think. And keep the 64-bit invalid values.
> >>
> >> We are not checking 64b. Think of one value that invalidates the test.
>
> eb.rsdvd = ctx << 32; always gives you the default context?
>
> But is ABI the macro helper or the comment in i915_drm.h against rsvd1?
>
> Probably the main problem is that we forgot to check for trash in upper
> bits..
>
> Or in other words, what do you want to see here in terms of invalid
> values and helper or not? Stick to 32-bits just because that's where we
> are now with the historical implementation?
The context id ABI has always been u32, and that's the field under test.
> > We can construct more values that would fail if we create a few contexts
> > and destroy them testing that that are invalid after use.
>
> Hello scope creep, okay, I'll add it.
The test is "invalid context id" :-p Feature creep would be identifying
that we have several tests that poke at IDRs through the ABI that could
be refactored into a framework for light fuzzing.
-Chris
More information about the Intel-gfx
mailing list