[Intel-gfx] [PATCH] tests/gem_userptr_blits: Expanded userptr test cases

[Daniel Vetter]

On Wed, Jan 29, 2014 at 01:30:54PM +0000, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> 
> A set of userptr test cases to support the new feature.
> 
> For the eviction and swapping stress testing I have extracted
> some common behaviour from gem_evict_everything and made both
> test cases use it to avoid duplicating the code.
> 
> Both unsynchronized and synchronized userptr objects are
> tested but the latter set of tests will be skipped if kernel
> is compiled without MMU_NOTIFIERS.
> 
> Also, with 32-bit userspace swapping tests are skipped if
> the system has a lot more RAM than process address space.
> Forking swapping tests are not skipped since they can still
> trigger swapping by cumulative effect.
> 
> Tested with userptr patch v18 on Android (with some swap added).
> 
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

Minor thing on patch style: I'd split this up into 3 parts:
- Extraction of the helpers - always useful to shine a bit light onto new
  helper stuff so other people also notice them.
- The new testcase.
- Removal of the old vmap testcase.

The other patch style thing are the helpers - the forking_eviction stuff
doesn't really sound like a bit of helper code. igt_exchange_uint32_t
certainly is, but the other stuff I'd just put into a common source file
which is included by both tests. Yeah #include "common.c" is a bit evil,
but this is a testsuite ;-) Or just copy&paste the code into the userptr
test, which is the approach I'd have done.

Now for test coverage it sounds like this testcases here has been more
than good enough to shake down the userptr implementation, so I think
we're covered.

But there is also basic interface coverage for sanity-checking and
defending against evil userspace. For this case here I think we need:

- Tests with un-aligned ptr/size.
- Tests with invalid flags.
- Basic nastiness of handing in an invalid pointer.

Then there's all the interactions with other gem interfaces:
- pwrite/pread/set_tiling: Should probably all fail with -EINVAL or
  something like that.
- dma-buf export/gem flink: should succeed.
- But: dma-buf mapping for a foreign device should fail. This will be a
  pain to test on Android since we don't have anything else really. I can
  take that and do a test like the pile of prime_nv tests we have.
- gtt mmaps: Theoretically works, but dunno whether it makes sense.
- Anything esle I've forgotten?

I don't expect any real surprises here, but imo we need to have this.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch