[Intel-gfx] [RFC i-g-t 1/6] tests/gem_pread: drop stolen memory related subtests

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2017-10-03 16:36:37)
> 
> 
> On 03/10/17 04:08, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2017-10-03 00:00:13)
> >> The feature was never merged and there has been no progress in the
> >> last year. The subtests are currently skipping on all platforms by
> >> checking a field in the get_aperture ioctl structure that doesn't
> >> exist in the kernel version of the struct.
> > 
> > The interface for this is upstream, fix the test to exercise the kernel
> > code (hint dmabuf).
> > -Chris
> > 
> 
> I'm not very familiar with the dmabuf interface, but looking at it I 
> couldn't find any way of allocating and/or accessing an object in stolen 
> memory from userspace. A grep for "create_stolen" also didn't show 
> anything. Can you point me in the right direction?

It's just that a dmabuf of a e.g. vgem bo will use the same pread paths
that we originally wrote for stolen support. (We need a bo that is not
backed by struct page.)

Something like 

static uint32_t create_foreign_bo(int device, uint32_t sz, void *data)
{
	struct vgem_bo scratch;
	int vgem, dmabuf;
	uint32_t handle;

	vgem = drm_driver_open(DRIVER_VGEM);

	scratch.width = 1024;
	scratch.height = sz / 4096;
	scratch.bpp = 32;
	vgem_create(vgem, &scratch);

	igt_assert_eq(sz, scratch.size);

	if (data) {
		void *ptr;

		ptr = vgem_mmap(vgem, &scratch, PROT_WRITE);
		memcpy(ptr, data, sz);
		munmap(ptr, scratch.size);
	}	

	dmabuf = prime_handle_to_fd(vgem, scratch.handle);
	handle = prime_fd_to_handle(device, dmabuf);
	close(dmabuf);

	close(vgem);

	return handle;
}

will create a handle that we can pass to pread to exercise the same
paths. For pwrite, we need to keep the vgem bo around so we can read
back from its mmapping.

We do have coverage in prime_vgem.c, but it's not the first place you
would go to exercise i915_gem_pread_ioctl().
-Chris