[PATCH libdrm] amdgpu: add VM test to exercise max/min address space

[Koenig, Christian]

Am 29.10.18 um 09:13 schrieb Zhang, Jerry:
> 在 2018年10月29日，15:32，Christian König <ckoenig.leichtzumerken at gmail.com> 写道：
>> Am 29.10.18 um 06:50 schrieb Zhang, Jerry:
>>> 在 2018年10月26日，18:59，Christian König <ckoenig.leichtzumerken at gmail.com> 写道：
>>>> Make sure the kernel doesn't crash if we map something at the minimum/maximum address.
>>>>
>>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>>>> ---
>>>> tests/amdgpu/vm_tests.c | 45 ++++++++++++++++++++++++++++++++++++++++-
>>>> 1 file changed, 44 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/tests/amdgpu/vm_tests.c b/tests/amdgpu/vm_tests.c
>>>> index 7b6dc5d6..bbdeef4d 100644
>>>> --- a/tests/amdgpu/vm_tests.c
>>>> +++ b/tests/amdgpu/vm_tests.c
>>>> @@ -31,8 +31,8 @@ static  amdgpu_device_handle device_handle;
>>>> static  uint32_t  major_version;
>>>> static  uint32_t  minor_version;
>>>>
>>>> -
>>>> static void amdgpu_vmid_reserve_test(void);
>>>> +static void amdgpu_vm_mapping_test(void);
>>>>
>>>> CU_BOOL suite_vm_tests_enable(void)
>>>> {
>>>> @@ -84,6 +84,7 @@ int suite_vm_tests_clean(void)
>>>>
>>>> CU_TestInfo vm_tests[] = {
>>>> 	{ "resere vmid test",  amdgpu_vmid_reserve_test },
>>>> +	{ "vm mapping test",  amdgpu_vm_mapping_test },
>>>> 	CU_TEST_INFO_NULL,
>>>> };
>>>>
>>>> @@ -167,3 +168,45 @@ static void amdgpu_vmid_reserve_test(void)
>>>> 	r = amdgpu_cs_ctx_free(context_handle);
>>>> 	CU_ASSERT_EQUAL(r, 0);
>>>> }
>>>> +
>>>> +static void amdgpu_vm_mapping_test(void)
>>>> +{
>>>> +	struct amdgpu_bo_alloc_request req = {0};
>>>> +	struct drm_amdgpu_info_device dev_info;
>>>> +	const uint64_t size = 4096;
>>>> +	amdgpu_bo_handle buf;
>>>> +	uint64_t addr;
>>>> +	int r;
>>>> +
>>>> +	req.alloc_size = size;
>>>> +	req.phys_alignment = 0;
>>>> +	req.preferred_heap = AMDGPU_GEM_DOMAIN_GTT;
>>>> +	req.flags = 0;
>>>> +
>>>> +	r = amdgpu_bo_alloc(device_handle, &req, &buf);
>>>> +	CU_ASSERT_EQUAL(r, 0);
>>>> +
>>>> +	r = amdgpu_query_info(device_handle, AMDGPU_INFO_DEV_INFO,
>>>> +			      sizeof(dev_info), &dev_info);
>>>> +	CU_ASSERT_EQUAL(r, 0);
>>>> +
>>>> +	addr = dev_info.virtual_address_offset;
>>>> +	r = amdgpu_bo_va_op(buf, 0, size, addr, 0, AMDGPU_VA_OP_MAP);
>>>> +	CU_ASSERT_EQUAL(r, 0);
>>> Please confirm:
>>>
>>> We may need to unmap the VA before bo free, although this VA range is unlikely to be used by other test cases.
>> Unmapping is unnecessary, VA mappings of BOs are automatically removed when the BO is freed.
> Ah, correct. Feel free to add
> Reviewed-by: Junwei Zhang <Jerry.Zhang at amd.com>

Thanks.

>
>>> BTW, is it a chance in practice that a process may map different VA ranges to the same bo?
>> Yeah, that is used quite extensively with PRTs.
> PRT may use different ranges in entire BO.
> What I actually mean is the same bo range, e.g. 1 page of BO starting from offset 0, mapping to different VA ranges, like what the test does now.

Good point, but that should also be used by PRT mappings.

E.g. what we do with PRT is to have a BO filled with parts of a texture. 
This BO is then mapped once completely form start till end and once page 
by page into the sparse populated PRT texture.

Christian.

>
> Jerry
>
>> Regards,
>> Christian.
>>
>>> Regards,
>>> Jerry
>>>
>>>> +
>>>> +	addr = dev_info.virtual_address_max - size;
>>>> +	r = amdgpu_bo_va_op(buf, 0, size, addr, 0, AMDGPU_VA_OP_MAP);
>>>> +	CU_ASSERT_EQUAL(r, 0);
>>>> +
>>>> +	if (dev_info.high_va_offset) {
>>>> +		addr = dev_info.high_va_offset;
>>>> +		r = amdgpu_bo_va_op(buf, 0, size, addr, 0, AMDGPU_VA_OP_MAP);
>>>> +		CU_ASSERT_EQUAL(r, 0);
>>>> +
>>>> +		addr = dev_info.high_va_max - size;
>>>> +		r = amdgpu_bo_va_op(buf, 0, size, addr, 0, AMDGPU_VA_OP_MAP);
>>>> +		CU_ASSERT_EQUAL(r, 0);
>>>> +	}
>>>> +
>>>> +	amdgpu_bo_free(buf);
>>>> +}
>>>> -- 
>>>> 2.17.1
>>>>
>>>> _______________________________________________
>>>> amd-gfx mailing list
>>>> amd-gfx at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx