Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] tests/gem_ctx_bad_exec: Consolidate to gem_ctx_exec

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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?

> 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.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx