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

Daniele Ceraolo Spurio daniele.ceraolospurio at intel.com
Tue Oct 3 16:02:44 UTC 2017



On 03/10/17 08:49, Chris Wilson wrote:
> 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
> 

Thanks for the clarification. I'll update the patch to replace the 
stolen tests with the vgem ones.

Daniele


More information about the Intel-gfx mailing list