All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH libdrm] amdgpu: add VM test to exercise max/min address space
@ 2018-10-26 10:59 Christian König
       [not found] ` <20181026105921.3033-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 7+ messages in thread
From: Christian König @ 2018-10-26 10:59 UTC (permalink / raw)
  To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

Make sure the kernel doesn't crash if we map something at the minimum/maximum address.

Signed-off-by: Christian König <christian.koenig@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);
+
+	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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH libdrm] amdgpu: add VM test to exercise max/min address space
       [not found] ` <20181026105921.3033-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
@ 2018-10-26 13:43   ` Deucher, Alexander
  2018-10-29  5:50   ` Zhang, Jerry
  1 sibling, 0 replies; 7+ messages in thread
From: Deucher, Alexander @ 2018-10-26 13:43 UTC (permalink / raw)
  To: Christian König, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW


[-- Attachment #1.1: Type: text/plain, Size: 3201 bytes --]

Reviewed-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>

________________________________
From: amd-gfx <amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> on behalf of Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Friday, October 26, 2018 6:59:21 AM
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: [PATCH libdrm] amdgpu: add VM test to exercise max/min address space

Make sure the kernel doesn't crash if we map something at the minimum/maximum address.

Signed-off-by: Christian König <christian.koenig-5C7GfCeVMHo@public.gmane.org>
---
 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);
+
+       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-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[-- Attachment #1.2: Type: text/html, Size: 6307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH libdrm] amdgpu: add VM test to exercise max/min address space
       [not found] ` <20181026105921.3033-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
  2018-10-26 13:43   ` Deucher, Alexander
@ 2018-10-29  5:50   ` Zhang, Jerry
       [not found]     ` <B07E931A-8ABA-462E-AA99-C1CC8A695BF4-5C7GfCeVMHo@public.gmane.org>
  1 sibling, 1 reply; 7+ messages in thread
From: Zhang, Jerry @ 2018-10-29  5:50 UTC (permalink / raw)
  To: Christian König; +Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

在 2018年10月26日,18:59,Christian König <ckoenig.leichtzumerken@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@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.

BTW, is it a chance in practice that a process may map different VA ranges to the same bo?

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

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH libdrm] amdgpu: add VM test to exercise max/min address space
       [not found]     ` <B07E931A-8ABA-462E-AA99-C1CC8A695BF4-5C7GfCeVMHo@public.gmane.org>
@ 2018-10-29  7:32       ` Christian König
       [not found]         ` <1efd59cd-d605-b05f-4929-561c90709a60-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 7+ messages in thread
From: Christian König @ 2018-10-29  7:32 UTC (permalink / raw)
  To: Zhang, Jerry; +Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

Am 29.10.18 um 06:50 schrieb Zhang, Jerry:
> 在 2018年10月26日,18:59,Christian König <ckoenig.leichtzumerken@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@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.

> 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.

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

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH libdrm] amdgpu: add VM test to exercise max/min address space
       [not found]         ` <1efd59cd-d605-b05f-4929-561c90709a60-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2018-10-29  8:13           ` Zhang, Jerry
       [not found]             ` <68424CE7-03AF-488F-9855-E1C3AA0B4E94-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 7+ messages in thread
From: Zhang, Jerry @ 2018-10-29  8:13 UTC (permalink / raw)
  To: Koenig, Christian; +Cc: Zhang, Jerry, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

在 2018年10月29日,15:32,Christian König <ckoenig.leichtzumerken@gmail.com> 写道:
> 
> Am 29.10.18 um 06:50 schrieb Zhang, Jerry:
>> 在 2018年10月26日,18:59,Christian König <ckoenig.leichtzumerken@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@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@amd.com>

> 
>> 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.

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

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH libdrm] amdgpu: add VM test to exercise max/min address space
       [not found]             ` <68424CE7-03AF-488F-9855-E1C3AA0B4E94-5C7GfCeVMHo@public.gmane.org>
@ 2018-10-29  8:40               ` Koenig, Christian
       [not found]                 ` <5be172b4-765c-b81a-0899-e5e473472577-5C7GfCeVMHo@public.gmane.org>
  0 siblings, 1 reply; 7+ messages in thread
From: Koenig, Christian @ 2018-10-29  8:40 UTC (permalink / raw)
  To: Zhang, Jerry; +Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

Am 29.10.18 um 09:13 schrieb Zhang, Jerry:
> 在 2018年10月29日,15:32,Christian König <ckoenig.leichtzumerken@gmail.com> 写道:
>> Am 29.10.18 um 06:50 schrieb Zhang, Jerry:
>>> 在 2018年10月26日,18:59,Christian König <ckoenig.leichtzumerken@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@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@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@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH libdrm] amdgpu: add VM test to exercise max/min address space
       [not found]                 ` <5be172b4-765c-b81a-0899-e5e473472577-5C7GfCeVMHo@public.gmane.org>
@ 2018-10-29  9:13                   ` Zhang, Jerry
  0 siblings, 0 replies; 7+ messages in thread
From: Zhang, Jerry @ 2018-10-29  9:13 UTC (permalink / raw)
  To: Koenig, Christian; +Cc: Zhang, Jerry, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

在 2018年10月29日,16:40,Koenig, Christian <Christian.Koenig@amd.com> 写道:
> 
> Am 29.10.18 um 09:13 schrieb Zhang, Jerry:
>> 在 2018年10月29日,15:32,Christian König <ckoenig.leichtzumerken@gmail.com> 写道:
>>> Am 29.10.18 um 06:50 schrieb Zhang, Jerry:
>>>> 在 2018年10月26日,18:59,Christian König <ckoenig.leichtzumerken@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@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@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

It sounds MAP with map op

> and once page by page into the sparse populated PRT texture.

It sounds REPLACE with map op

Is there a case that map(MAP) the same bo range by different VA ranges?
work as a physical ram range is mapped by different virtual address.


Jerry

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

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-10-29  9:13 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-26 10:59 [PATCH libdrm] amdgpu: add VM test to exercise max/min address space Christian König
     [not found] ` <20181026105921.3033-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2018-10-26 13:43   ` Deucher, Alexander
2018-10-29  5:50   ` Zhang, Jerry
     [not found]     ` <B07E931A-8ABA-462E-AA99-C1CC8A695BF4-5C7GfCeVMHo@public.gmane.org>
2018-10-29  7:32       ` Christian König
     [not found]         ` <1efd59cd-d605-b05f-4929-561c90709a60-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-10-29  8:13           ` Zhang, Jerry
     [not found]             ` <68424CE7-03AF-488F-9855-E1C3AA0B4E94-5C7GfCeVMHo@public.gmane.org>
2018-10-29  8:40               ` Koenig, Christian
     [not found]                 ` <5be172b4-765c-b81a-0899-e5e473472577-5C7GfCeVMHo@public.gmane.org>
2018-10-29  9:13                   ` Zhang, Jerry

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.