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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux