[PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

To align the kernel uapi change from Alex:

"Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
this flag set will be created with the TMZ bit set in the PTEs or engines
accessing them. This is required in order to properly access the data from the
engines."

We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 include/drm/amdgpu_drm.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 5c28aa7..1a95e37 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -141,6 +141,11 @@ extern "C" {
  * releasing the memory
  */
 #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE	(1 << 9)
+/* Flag that BO will be encrypted and that the TMZ bit should be
+ * set in the PTEs when mapping this buffer via GPUVM or
+ * accessing it with various hw blocks
+ */
+#define AMDGPU_GEM_CREATE_ENCRYPTED		(1 << 10)
 
 /* Hybrid specific */
 /* Flag that the memory allocation should be from top of domain */
-- 
2.7.4

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

[PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

To align the kernel uapi change from Alex:

"Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
this flag set will be created with the TMZ bit set in the PTEs or engines
accessing them. This is required in order to properly access the data from the
engines."

We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 include/drm/amdgpu_drm.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 5c28aa7..1a95e37 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -141,6 +141,11 @@ extern "C" {
  * releasing the memory
  */
 #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE	(1 << 9)
+/* Flag that BO will be encrypted and that the TMZ bit should be
+ * set in the PTEs when mapping this buffer via GPUVM or
+ * accessing it with various hw blocks
+ */
+#define AMDGPU_GEM_CREATE_ENCRYPTED		(1 << 10)
 
 /* Hybrid specific */
 /* Flag that the memory allocation should be from top of domain */
-- 
2.7.4

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

[PATCH 02/12] tests/amdgpu: add security test suite (v2)

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

This patch is to add a new test suite to store security tests.
In Raven+ asics, it will support TMZ (trust memory zone), and it is
page-based protection feature.

v2: remove tests/amdgpu/Makefile.am and update to
tests/amdgpu/meson.build

Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Aaron Liu <aaron.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 tests/amdgpu/amdgpu_test.c    |  7 ++++
 tests/amdgpu/amdgpu_test.h    | 21 ++++++++++
 tests/amdgpu/meson.build      |  2 +-
 tests/amdgpu/security_tests.c | 96 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 tests/amdgpu/security_tests.c

diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 94bc305..f6ea23a 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -58,6 +58,7 @@
 #define VM_TESTS_STR "VM Tests"
 #define RAS_TESTS_STR "RAS Tests"
 #define SYNCOBJ_TIMELINE_TESTS_STR "SYNCOBJ TIMELINE Tests"
+#define SECURITY_TESTS_STR "Security Tests"
 
 /**
  *  Open handles for amdgpu devices
@@ -130,6 +131,12 @@ static CU_SuiteInfo suites[] = {
 		.pCleanupFunc = suite_syncobj_timeline_tests_clean,
 		.pTests = syncobj_timeline_tests,
 	},
+	{
+		.pName = SECURITY_TESTS_STR,
+		.pInitFunc = suite_security_tests_init,
+		.pCleanupFunc = suite_security_tests_clean,
+		.pTests = security_tests,
+	},
 
 	CU_SUITE_INFO_NULL,
 };
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index 0cb6ee9..b7f8de2 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -243,6 +243,27 @@ extern CU_TestInfo syncobj_timeline_tests[];
 
 
 /**
+ * Initialize security test suite
+ */
+int suite_security_tests_init();
+
+/**
+ * Deinitialize security test suite
+ */
+int suite_security_tests_clean();
+
+/**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_security_tests_enable(void);
+
+/**
+ * Tests in security test suite
+ */
+extern CU_TestInfo security_tests[];
+
+
+/**
  * Helper functions
  */
 static inline amdgpu_bo_handle gpu_mem_alloc(
diff --git a/tests/amdgpu/meson.build b/tests/amdgpu/meson.build
index 1726cb4..2a48b43 100644
--- a/tests/amdgpu/meson.build
+++ b/tests/amdgpu/meson.build
@@ -24,7 +24,7 @@ if dep_cunit.found()
     files(
       'amdgpu_test.c', 'basic_tests.c', 'bo_tests.c', 'cs_tests.c',
       'vce_tests.c', 'uvd_enc_tests.c', 'vcn_tests.c', 'deadlock_tests.c',
-      'vm_tests.c', 'ras_tests.c', 'syncobj_tests.c',
+      'vm_tests.c', 'ras_tests.c', 'syncobj_tests.c', 'security_tests.c',
     ),
     dependencies : [dep_cunit, dep_threads],
     include_directories : [inc_root, inc_drm, include_directories('../../amdgpu')],
diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
new file mode 100644
index 0000000..182b03d
--- /dev/null
+++ b/tests/amdgpu/security_tests.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright 2019 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+*/
+
+#include "CUnit/Basic.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+#include "amdgpu_internal.h"
+
+static amdgpu_device_handle device_handle;
+static uint32_t major_version;
+static uint32_t minor_version;
+
+static void amdgpu_security_alloc_buf_test(void);
+
+CU_BOOL suite_security_tests_enable(void)
+{
+	CU_BOOL enable = CU_TRUE;
+
+	if (amdgpu_device_initialize(drm_amdgpu[0], &major_version,
+				     &minor_version, &device_handle))
+		return CU_FALSE;
+
+	if (device_handle->info.family_id < AMDGPU_FAMILY_RV) {
+		printf("\n\nDon't support TMZ (trust memory zone), security suite disabled\n");
+		enable = CU_FALSE;
+	}
+
+	if (amdgpu_device_deinitialize(device_handle))
+		return CU_FALSE;
+
+	return enable;
+}
+
+int suite_security_tests_init(void)
+{
+	if (amdgpu_device_initialize(drm_amdgpu[0], &major_version,
+				     &minor_version, &device_handle))
+		return CUE_SINIT_FAILED;
+
+	return CUE_SUCCESS;
+}
+
+int suite_security_tests_clean(void)
+{
+	int r;
+
+	r = amdgpu_device_deinitialize(device_handle);
+	if (r)
+		return CUE_SCLEAN_FAILED;
+
+	return CUE_SUCCESS;
+}
+
+
+CU_TestInfo security_tests[] = {
+	{ "allocate secure buffer test", amdgpu_security_alloc_buf_test },
+	CU_TEST_INFO_NULL,
+};
+
+static void amdgpu_security_alloc_buf_test(void)
+{
+	amdgpu_bo_handle bo;
+	amdgpu_va_handle va_handle;
+	uint64_t bo_mc;
+	int r;
+
+	/* Test secure buffer allocation in VRAM */
+	bo = gpu_mem_alloc(device_handle, 4096, 4096,
+			   AMDGPU_GEM_DOMAIN_VRAM,
+			   AMDGPU_GEM_CREATE_ENCRYPTED,
+			   &bo_mc, &va_handle);
+
+	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
+	CU_ASSERT_EQUAL(r, 0);
+}
-- 
2.7.4

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

[PATCH 02/12] tests/amdgpu: add security test suite (v2)

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

This patch is to add a new test suite to store security tests.
In Raven+ asics, it will support TMZ (trust memory zone), and it is
page-based protection feature.

v2: remove tests/amdgpu/Makefile.am and update to
tests/amdgpu/meson.build

Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Aaron Liu <aaron.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 tests/amdgpu/amdgpu_test.c    |  7 ++++
 tests/amdgpu/amdgpu_test.h    | 21 ++++++++++
 tests/amdgpu/meson.build      |  2 +-
 tests/amdgpu/security_tests.c | 96 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 tests/amdgpu/security_tests.c

diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 94bc305..f6ea23a 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -58,6 +58,7 @@
 #define VM_TESTS_STR "VM Tests"
 #define RAS_TESTS_STR "RAS Tests"
 #define SYNCOBJ_TIMELINE_TESTS_STR "SYNCOBJ TIMELINE Tests"
+#define SECURITY_TESTS_STR "Security Tests"
 
 /**
  *  Open handles for amdgpu devices
@@ -130,6 +131,12 @@ static CU_SuiteInfo suites[] = {
 		.pCleanupFunc = suite_syncobj_timeline_tests_clean,
 		.pTests = syncobj_timeline_tests,
 	},
+	{
+		.pName = SECURITY_TESTS_STR,
+		.pInitFunc = suite_security_tests_init,
+		.pCleanupFunc = suite_security_tests_clean,
+		.pTests = security_tests,
+	},
 
 	CU_SUITE_INFO_NULL,
 };
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index 0cb6ee9..b7f8de2 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -243,6 +243,27 @@ extern CU_TestInfo syncobj_timeline_tests[];
 
 
 /**
+ * Initialize security test suite
+ */
+int suite_security_tests_init();
+
+/**
+ * Deinitialize security test suite
+ */
+int suite_security_tests_clean();
+
+/**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_security_tests_enable(void);
+
+/**
+ * Tests in security test suite
+ */
+extern CU_TestInfo security_tests[];
+
+
+/**
  * Helper functions
  */
 static inline amdgpu_bo_handle gpu_mem_alloc(
diff --git a/tests/amdgpu/meson.build b/tests/amdgpu/meson.build
index 1726cb4..2a48b43 100644
--- a/tests/amdgpu/meson.build
+++ b/tests/amdgpu/meson.build
@@ -24,7 +24,7 @@ if dep_cunit.found()
     files(
       'amdgpu_test.c', 'basic_tests.c', 'bo_tests.c', 'cs_tests.c',
       'vce_tests.c', 'uvd_enc_tests.c', 'vcn_tests.c', 'deadlock_tests.c',
-      'vm_tests.c', 'ras_tests.c', 'syncobj_tests.c',
+      'vm_tests.c', 'ras_tests.c', 'syncobj_tests.c', 'security_tests.c',
     ),
     dependencies : [dep_cunit, dep_threads],
     include_directories : [inc_root, inc_drm, include_directories('../../amdgpu')],
diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
new file mode 100644
index 0000000..182b03d
--- /dev/null
+++ b/tests/amdgpu/security_tests.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright 2019 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+*/
+
+#include "CUnit/Basic.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+#include "amdgpu_internal.h"
+
+static amdgpu_device_handle device_handle;
+static uint32_t major_version;
+static uint32_t minor_version;
+
+static void amdgpu_security_alloc_buf_test(void);
+
+CU_BOOL suite_security_tests_enable(void)
+{
+	CU_BOOL enable = CU_TRUE;
+
+	if (amdgpu_device_initialize(drm_amdgpu[0], &major_version,
+				     &minor_version, &device_handle))
+		return CU_FALSE;
+
+	if (device_handle->info.family_id < AMDGPU_FAMILY_RV) {
+		printf("\n\nDon't support TMZ (trust memory zone), security suite disabled\n");
+		enable = CU_FALSE;
+	}
+
+	if (amdgpu_device_deinitialize(device_handle))
+		return CU_FALSE;
+
+	return enable;
+}
+
+int suite_security_tests_init(void)
+{
+	if (amdgpu_device_initialize(drm_amdgpu[0], &major_version,
+				     &minor_version, &device_handle))
+		return CUE_SINIT_FAILED;
+
+	return CUE_SUCCESS;
+}
+
+int suite_security_tests_clean(void)
+{
+	int r;
+
+	r = amdgpu_device_deinitialize(device_handle);
+	if (r)
+		return CUE_SCLEAN_FAILED;
+
+	return CUE_SUCCESS;
+}
+
+
+CU_TestInfo security_tests[] = {
+	{ "allocate secure buffer test", amdgpu_security_alloc_buf_test },
+	CU_TEST_INFO_NULL,
+};
+
+static void amdgpu_security_alloc_buf_test(void)
+{
+	amdgpu_bo_handle bo;
+	amdgpu_va_handle va_handle;
+	uint64_t bo_mc;
+	int r;
+
+	/* Test secure buffer allocation in VRAM */
+	bo = gpu_mem_alloc(device_handle, 4096, 4096,
+			   AMDGPU_GEM_DOMAIN_VRAM,
+			   AMDGPU_GEM_CREATE_ENCRYPTED,
+			   &bo_mc, &va_handle);
+
+	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
+	CU_ASSERT_EQUAL(r, 0);
+}
-- 
2.7.4

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

[PATCH 03/12] tests/amdgpu: add secure buffer allocation test for system memory

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

This patch is to add secure buffer allocation test for system memory.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 tests/amdgpu/security_tests.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
index 182b03d..afe79e5 100644
--- a/tests/amdgpu/security_tests.c
+++ b/tests/amdgpu/security_tests.c
@@ -93,4 +93,13 @@ static void amdgpu_security_alloc_buf_test(void)
 
 	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
 	CU_ASSERT_EQUAL(r, 0);
+
+	/* Test secure buffer allocation in system memory */
+	bo = gpu_mem_alloc(device_handle, 4096, 4096,
+			   AMDGPU_GEM_DOMAIN_GTT,
+			   AMDGPU_GEM_CREATE_ENCRYPTED,
+			   &bo_mc, &va_handle);
+
+	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
+	CU_ASSERT_EQUAL(r, 0);
 }
-- 
2.7.4

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

[PATCH 03/12] tests/amdgpu: add secure buffer allocation test for system memory

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

This patch is to add secure buffer allocation test for system memory.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 tests/amdgpu/security_tests.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
index 182b03d..afe79e5 100644
--- a/tests/amdgpu/security_tests.c
+++ b/tests/amdgpu/security_tests.c
@@ -93,4 +93,13 @@ static void amdgpu_security_alloc_buf_test(void)
 
 	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
 	CU_ASSERT_EQUAL(r, 0);
+
+	/* Test secure buffer allocation in system memory */
+	bo = gpu_mem_alloc(device_handle, 4096, 4096,
+			   AMDGPU_GEM_DOMAIN_GTT,
+			   AMDGPU_GEM_CREATE_ENCRYPTED,
+			   &bo_mc, &va_handle);
+
+	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
+	CU_ASSERT_EQUAL(r, 0);
 }
-- 
2.7.4

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

[PATCH 04/12] tests/amdgpu: add secure buffer allocation test for invisible VRAM

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

This patch is to add secure buffer allocation test for invisible VRAM.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 tests/amdgpu/security_tests.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
index afe79e5..a3807ee 100644
--- a/tests/amdgpu/security_tests.c
+++ b/tests/amdgpu/security_tests.c
@@ -102,4 +102,14 @@ static void amdgpu_security_alloc_buf_test(void)
 
 	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
 	CU_ASSERT_EQUAL(r, 0);
+
+	/* Test secure buffer allocation in invisible VRAM */
+	bo = gpu_mem_alloc(device_handle, 4096, 4096,
+			   AMDGPU_GEM_DOMAIN_GTT,
+			   AMDGPU_GEM_CREATE_ENCRYPTED |
+			   AMDGPU_GEM_CREATE_NO_CPU_ACCESS,
+			   &bo_mc, &va_handle);
+
+	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
+	CU_ASSERT_EQUAL(r, 0);
 }
-- 
2.7.4

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

[PATCH 04/12] tests/amdgpu: add secure buffer allocation test for invisible VRAM

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

This patch is to add secure buffer allocation test for invisible VRAM.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 tests/amdgpu/security_tests.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
index afe79e5..a3807ee 100644
--- a/tests/amdgpu/security_tests.c
+++ b/tests/amdgpu/security_tests.c
@@ -102,4 +102,14 @@ static void amdgpu_security_alloc_buf_test(void)
 
 	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
 	CU_ASSERT_EQUAL(r, 0);
+
+	/* Test secure buffer allocation in invisible VRAM */
+	bo = gpu_mem_alloc(device_handle, 4096, 4096,
+			   AMDGPU_GEM_DOMAIN_GTT,
+			   AMDGPU_GEM_CREATE_ENCRYPTED |
+			   AMDGPU_GEM_CREATE_NO_CPU_ACCESS,
+			   &bo_mc, &va_handle);
+
+	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
+	CU_ASSERT_EQUAL(r, 0);
 }
-- 
2.7.4

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

[PATCH 05/12] tests/amdgpu: expand write linear helper for security (v3)

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

This patch expand write linear helper for security to submit the command
with secure context.

v2: refine the function implementation.
v3: remove amdgpu_cs_ctx_create3.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Aaron Liu <aaron.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 tests/amdgpu/amdgpu_test.h |  4 ++++
 tests/amdgpu/basic_tests.c | 15 +++++++++++++--
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index b7f8de2..67be437 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -262,6 +262,9 @@ CU_BOOL suite_security_tests_enable(void);
  */
 extern CU_TestInfo security_tests[];
 
+extern void
+amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
+							  bool secure);
 
 /**
  * Helper functions
@@ -452,4 +455,5 @@ static inline bool asic_is_arcturus(uint32_t asic_id)
 	}
 }
 
+
 #endif  /* #ifdef _AMDGPU_TEST_H_ */
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index a57dcbb..31c9a54 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -71,7 +71,7 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
 				       int res_cnt, amdgpu_bo_handle *resources,
 				       struct amdgpu_cs_ib_info *ib_info,
 				       struct amdgpu_cs_request *ibs_request);
- 
+
 CU_TestInfo basic_tests[] = {
 	{ "Query Info Test",  amdgpu_query_info_test },
 	{ "Userptr Test",  amdgpu_userptr_test },
@@ -1361,7 +1361,8 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
 	CU_ASSERT_EQUAL(r, 0);
 }
 
-static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
+void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
+							       bool secure)
 {
 	const int sdma_write_length = 128;
 	const int pm4_dw = 256;
@@ -1390,7 +1391,11 @@ static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
 	r = amdgpu_query_hw_ip_info(device_handle, ip_type, 0, &hw_ip_info);
 	CU_ASSERT_EQUAL(r, 0);
 
+	for (i = 0; secure && (i < 2); i++)
+		gtt_flags[i] |= AMDGPU_GEM_CREATE_ENCRYPTED;
+
 	r = amdgpu_cs_ctx_create(device_handle, &context_handle);
+
 	CU_ASSERT_EQUAL(r, 0);
 
 	/* prepare resource */
@@ -1469,6 +1474,12 @@ static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
 	CU_ASSERT_EQUAL(r, 0);
 }
 
+static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
+{
+	amdgpu_command_submission_write_linear_helper_with_secure(ip_type,
+								  false);
+}
+
 static void amdgpu_command_submission_sdma_write_linear(void)
 {
 	amdgpu_command_submission_write_linear_helper(AMDGPU_HW_IP_DMA);
-- 
2.7.4

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

[PATCH 05/12] tests/amdgpu: expand write linear helper for security (v3)

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

This patch expand write linear helper for security to submit the command
with secure context.

v2: refine the function implementation.
v3: remove amdgpu_cs_ctx_create3.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Aaron Liu <aaron.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 tests/amdgpu/amdgpu_test.h |  4 ++++
 tests/amdgpu/basic_tests.c | 15 +++++++++++++--
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index b7f8de2..67be437 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -262,6 +262,9 @@ CU_BOOL suite_security_tests_enable(void);
  */
 extern CU_TestInfo security_tests[];
 
+extern void
+amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
+							  bool secure);
 
 /**
  * Helper functions
@@ -452,4 +455,5 @@ static inline bool asic_is_arcturus(uint32_t asic_id)
 	}
 }
 
+
 #endif  /* #ifdef _AMDGPU_TEST_H_ */
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index a57dcbb..31c9a54 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -71,7 +71,7 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
 				       int res_cnt, amdgpu_bo_handle *resources,
 				       struct amdgpu_cs_ib_info *ib_info,
 				       struct amdgpu_cs_request *ibs_request);
- 
+
 CU_TestInfo basic_tests[] = {
 	{ "Query Info Test",  amdgpu_query_info_test },
 	{ "Userptr Test",  amdgpu_userptr_test },
@@ -1361,7 +1361,8 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
 	CU_ASSERT_EQUAL(r, 0);
 }
 
-static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
+void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
+							       bool secure)
 {
 	const int sdma_write_length = 128;
 	const int pm4_dw = 256;
@@ -1390,7 +1391,11 @@ static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
 	r = amdgpu_query_hw_ip_info(device_handle, ip_type, 0, &hw_ip_info);
 	CU_ASSERT_EQUAL(r, 0);
 
+	for (i = 0; secure && (i < 2); i++)
+		gtt_flags[i] |= AMDGPU_GEM_CREATE_ENCRYPTED;
+
 	r = amdgpu_cs_ctx_create(device_handle, &context_handle);
+
 	CU_ASSERT_EQUAL(r, 0);
 
 	/* prepare resource */
@@ -1469,6 +1474,12 @@ static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
 	CU_ASSERT_EQUAL(r, 0);
 }
 
+static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
+{
+	amdgpu_command_submission_write_linear_helper_with_secure(ip_type,
+								  false);
+}
+
 static void amdgpu_command_submission_sdma_write_linear(void)
 {
 	amdgpu_command_submission_write_linear_helper(AMDGPU_HW_IP_DMA);
-- 
2.7.4

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

Re: [PATCH 05/12] tests/amdgpu: expand write linear helper for security (v3)

[Luben Tuikov]

On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui <ray.huang@amd.com>
> 
> This patch expand write linear helper for security to submit the command
> with secure context.
> 
> v2: refine the function implementation.
> v3: remove amdgpu_cs_ctx_create3.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
>  tests/amdgpu/amdgpu_test.h |  4 ++++
>  tests/amdgpu/basic_tests.c | 15 +++++++++++++--
>  2 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
> index b7f8de2..67be437 100644
> --- a/tests/amdgpu/amdgpu_test.h
> +++ b/tests/amdgpu/amdgpu_test.h
> @@ -262,6 +262,9 @@ CU_BOOL suite_security_tests_enable(void);
>   */
>  extern CU_TestInfo security_tests[];
>  
> +extern void
> +amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
> +							  bool secure);
>  
>  /**
>   * Helper functions
> @@ -452,4 +455,5 @@ static inline bool asic_is_arcturus(uint32_t asic_id)
>  	}
>  }
>  
> +
>  #endif  /* #ifdef _AMDGPU_TEST_H_ */
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index a57dcbb..31c9a54 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -71,7 +71,7 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
>  				       int res_cnt, amdgpu_bo_handle *resources,
>  				       struct amdgpu_cs_ib_info *ib_info,
>  				       struct amdgpu_cs_request *ibs_request);
> - 
> +
>  CU_TestInfo basic_tests[] = {
>  	{ "Query Info Test",  amdgpu_query_info_test },
>  	{ "Userptr Test",  amdgpu_userptr_test },
> @@ -1361,7 +1361,8 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
>  	CU_ASSERT_EQUAL(r, 0);
>  }
>  
> -static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
> +void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
> +							       bool secure)
>  {

This is an example of bad naming of a function. And it is also very long. Too long.

Why does the name need to end with "_secure("? Does it mean that the write is always
secure? No! No, it doesn't! If the parameter, in this case the security state, is
parameterized, as it is via a function argument, then you don't need to add this
also to the name of the function, as you did.

amdgpu_command_submission_write_linear_helper(unsigned ip_type, bool secure)

is fine for a name. Leave it at that.

Regards,
Luben

>  	const int sdma_write_length = 128;
>  	const int pm4_dw = 256;
> @@ -1390,7 +1391,11 @@ static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
>  	r = amdgpu_query_hw_ip_info(device_handle, ip_type, 0, &hw_ip_info);
>  	CU_ASSERT_EQUAL(r, 0);
>  
> +	for (i = 0; secure && (i < 2); i++)
> +		gtt_flags[i] |= AMDGPU_GEM_CREATE_ENCRYPTED;
> +
>  	r = amdgpu_cs_ctx_create(device_handle, &context_handle);
> +
>  	CU_ASSERT_EQUAL(r, 0);
>  
>  	/* prepare resource */
> @@ -1469,6 +1474,12 @@ static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
>  	CU_ASSERT_EQUAL(r, 0);
>  }
>  
> +static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
> +{
> +	amdgpu_command_submission_write_linear_helper_with_secure(ip_type,
> +								  false);
> +}
> +
>  static void amdgpu_command_submission_sdma_write_linear(void)
>  {
>  	amdgpu_command_submission_write_linear_helper(AMDGPU_HW_IP_DMA);
> 

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

Re: [PATCH 05/12] tests/amdgpu: expand write linear helper for security (v3)

[Luben Tuikov]

On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui <ray.huang@amd.com>
> 
> This patch expand write linear helper for security to submit the command
> with secure context.
> 
> v2: refine the function implementation.
> v3: remove amdgpu_cs_ctx_create3.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
>  tests/amdgpu/amdgpu_test.h |  4 ++++
>  tests/amdgpu/basic_tests.c | 15 +++++++++++++--
>  2 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
> index b7f8de2..67be437 100644
> --- a/tests/amdgpu/amdgpu_test.h
> +++ b/tests/amdgpu/amdgpu_test.h
> @@ -262,6 +262,9 @@ CU_BOOL suite_security_tests_enable(void);
>   */
>  extern CU_TestInfo security_tests[];
>  
> +extern void
> +amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
> +							  bool secure);
>  
>  /**
>   * Helper functions
> @@ -452,4 +455,5 @@ static inline bool asic_is_arcturus(uint32_t asic_id)
>  	}
>  }
>  
> +
>  #endif  /* #ifdef _AMDGPU_TEST_H_ */
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index a57dcbb..31c9a54 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -71,7 +71,7 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
>  				       int res_cnt, amdgpu_bo_handle *resources,
>  				       struct amdgpu_cs_ib_info *ib_info,
>  				       struct amdgpu_cs_request *ibs_request);
> - 
> +
>  CU_TestInfo basic_tests[] = {
>  	{ "Query Info Test",  amdgpu_query_info_test },
>  	{ "Userptr Test",  amdgpu_userptr_test },
> @@ -1361,7 +1361,8 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
>  	CU_ASSERT_EQUAL(r, 0);
>  }
>  
> -static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
> +void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
> +							       bool secure)
>  {

This is an example of bad naming of a function. And it is also very long. Too long.

Why does the name need to end with "_secure("? Does it mean that the write is always
secure? No! No, it doesn't! If the parameter, in this case the security state, is
parameterized, as it is via a function argument, then you don't need to add this
also to the name of the function, as you did.

amdgpu_command_submission_write_linear_helper(unsigned ip_type, bool secure)

is fine for a name. Leave it at that.

Regards,
Luben

>  	const int sdma_write_length = 128;
>  	const int pm4_dw = 256;
> @@ -1390,7 +1391,11 @@ static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
>  	r = amdgpu_query_hw_ip_info(device_handle, ip_type, 0, &hw_ip_info);
>  	CU_ASSERT_EQUAL(r, 0);
>  
> +	for (i = 0; secure && (i < 2); i++)
> +		gtt_flags[i] |= AMDGPU_GEM_CREATE_ENCRYPTED;
> +
>  	r = amdgpu_cs_ctx_create(device_handle, &context_handle);
> +
>  	CU_ASSERT_EQUAL(r, 0);
>  
>  	/* prepare resource */
> @@ -1469,6 +1474,12 @@ static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
>  	CU_ASSERT_EQUAL(r, 0);
>  }
>  
> +static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
> +{
> +	amdgpu_command_submission_write_linear_helper_with_secure(ip_type,
> +								  false);
> +}
> +
>  static void amdgpu_command_submission_sdma_write_linear(void)
>  {
>  	amdgpu_command_submission_write_linear_helper(AMDGPU_HW_IP_DMA);
> 

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

[PATCH 06/12] tests/amdgpu: add device handle as input param for exec_cs_helper and write_linear_helper (v4)

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

This patch is to add add device handle as input param for exec_cs_helper
and write_linear_helper.

Because they are needed in security tests.

v2: fix typo that basic tests should be un-secure.
v3: refine the function implementation.
v4: remove amdgpu_cs_ctx_create3 calling.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Aaron Liu <aaron.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 tests/amdgpu/amdgpu_test.h |  4 +++-
 tests/amdgpu/basic_tests.c | 52 +++++++++++++++++++++++++++++++---------------
 2 files changed, 38 insertions(+), 18 deletions(-)

diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index 67be437..16c2da0 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -263,7 +263,9 @@ CU_BOOL suite_security_tests_enable(void);
 extern CU_TestInfo security_tests[];
 
 extern void
-amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
+amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
+							  device,
+							  unsigned ip_type,
 							  bool secure);
 
 /**
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 31c9a54..5154812 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -1283,12 +1283,14 @@ static void amdgpu_command_submission_compute(void)
  * pm4_src, resources, ib_info, and ibs_request
  * submit command stream described in ibs_request and wait for this IB accomplished
  */
-static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
-				       unsigned ip_type,
-				       int instance, int pm4_dw, uint32_t *pm4_src,
-				       int res_cnt, amdgpu_bo_handle *resources,
-				       struct amdgpu_cs_ib_info *ib_info,
-				       struct amdgpu_cs_request *ibs_request)
+static void
+amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
+			       amdgpu_context_handle context_handle,
+			       unsigned ip_type, int instance, int pm4_dw,
+			       uint32_t *pm4_src, int res_cnt,
+			       amdgpu_bo_handle *resources,
+			       struct amdgpu_cs_ib_info *ib_info,
+			       struct amdgpu_cs_request *ibs_request)
 {
 	int r;
 	uint32_t expired;
@@ -1361,8 +1363,24 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
 	CU_ASSERT_EQUAL(r, 0);
 }
 
-void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
-							       bool secure)
+static void
+amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
+			   unsigned ip_type, int instance, int pm4_dw,
+			   uint32_t *pm4_src, int res_cnt,
+			   amdgpu_bo_handle *resources,
+			   struct amdgpu_cs_ib_info *ib_info,
+			   struct amdgpu_cs_request *ibs_request)
+{
+	amdgpu_test_exec_cs_helper_raw(device_handle, context_handle,
+				       ip_type, instance, pm4_dw, pm4_src,
+				       res_cnt, resources, ib_info,
+				       ibs_request);
+}
+
+void
+amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
+							  device, unsigned
+							  ip_type, bool secure)
 {
 	const int sdma_write_length = 128;
 	const int pm4_dw = 256;
@@ -1388,13 +1406,13 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
 	ibs_request = calloc(1, sizeof(*ibs_request));
 	CU_ASSERT_NOT_EQUAL(ibs_request, NULL);
 
-	r = amdgpu_query_hw_ip_info(device_handle, ip_type, 0, &hw_ip_info);
+	r = amdgpu_query_hw_ip_info(device, ip_type, 0, &hw_ip_info);
 	CU_ASSERT_EQUAL(r, 0);
 
 	for (i = 0; secure && (i < 2); i++)
 		gtt_flags[i] |= AMDGPU_GEM_CREATE_ENCRYPTED;
 
-	r = amdgpu_cs_ctx_create(device_handle, &context_handle);
+	r = amdgpu_cs_ctx_create(device, &context_handle);
 
 	CU_ASSERT_EQUAL(r, 0);
 
@@ -1406,7 +1424,7 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
 		loop = 0;
 		while(loop < 2) {
 			/* allocate UC bo for sDMA use */
-			r = amdgpu_bo_alloc_and_map(device_handle,
+			r = amdgpu_bo_alloc_and_map(device,
 						    sdma_write_length * sizeof(uint32_t),
 						    4096, AMDGPU_GEM_DOMAIN_GTT,
 						    gtt_flags[loop], &bo, (void**)&bo_cpu,
@@ -1445,11 +1463,10 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
 					pm4[i++] = 0xdeadbeaf;
 			}
 
-			amdgpu_test_exec_cs_helper(context_handle,
-						   ip_type, ring_id,
-						   i, pm4,
-						   1, resources,
-						   ib_info, ibs_request);
+			amdgpu_test_exec_cs_helper_raw(device, context_handle,
+						       ip_type, ring_id, i, pm4,
+						       1, resources, ib_info,
+						       ibs_request);
 
 			/* verify if SDMA test result meets with expected */
 			i = 0;
@@ -1476,7 +1493,8 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
 
 static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
 {
-	amdgpu_command_submission_write_linear_helper_with_secure(ip_type,
+	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
+								  ip_type,
 								  false);
 }
 
-- 
2.7.4

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

[PATCH 06/12] tests/amdgpu: add device handle as input param for exec_cs_helper and write_linear_helper (v4)

[Aaron Liu]

From: Huang Rui <ray.huang@amd.com>

This patch is to add add device handle as input param for exec_cs_helper
and write_linear_helper.

Because they are needed in security tests.

v2: fix typo that basic tests should be un-secure.
v3: refine the function implementation.
v4: remove amdgpu_cs_ctx_create3 calling.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Aaron Liu <aaron.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
---
 tests/amdgpu/amdgpu_test.h |  4 +++-
 tests/amdgpu/basic_tests.c | 52 +++++++++++++++++++++++++++++++---------------
 2 files changed, 38 insertions(+), 18 deletions(-)

diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index 67be437..16c2da0 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -263,7 +263,9 @@ CU_BOOL suite_security_tests_enable(void);
 extern CU_TestInfo security_tests[];
 
 extern void
-amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
+amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
+							  device,
+							  unsigned ip_type,
 							  bool secure);
 
 /**
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 31c9a54..5154812 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -1283,12 +1283,14 @@ static void amdgpu_command_submission_compute(void)
  * pm4_src, resources, ib_info, and ibs_request
  * submit command stream described in ibs_request and wait for this IB accomplished
  */
-static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
-				       unsigned ip_type,
-				       int instance, int pm4_dw, uint32_t *pm4_src,
-				       int res_cnt, amdgpu_bo_handle *resources,
-				       struct amdgpu_cs_ib_info *ib_info,
-				       struct amdgpu_cs_request *ibs_request)
+static void
+amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
+			       amdgpu_context_handle context_handle,
+			       unsigned ip_type, int instance, int pm4_dw,
+			       uint32_t *pm4_src, int res_cnt,
+			       amdgpu_bo_handle *resources,
+			       struct amdgpu_cs_ib_info *ib_info,
+			       struct amdgpu_cs_request *ibs_request)
 {
 	int r;
 	uint32_t expired;
@@ -1361,8 +1363,24 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
 	CU_ASSERT_EQUAL(r, 0);
 }
 
-void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
-							       bool secure)
+static void
+amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
+			   unsigned ip_type, int instance, int pm4_dw,
+			   uint32_t *pm4_src, int res_cnt,
+			   amdgpu_bo_handle *resources,
+			   struct amdgpu_cs_ib_info *ib_info,
+			   struct amdgpu_cs_request *ibs_request)
+{
+	amdgpu_test_exec_cs_helper_raw(device_handle, context_handle,
+				       ip_type, instance, pm4_dw, pm4_src,
+				       res_cnt, resources, ib_info,
+				       ibs_request);
+}
+
+void
+amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
+							  device, unsigned
+							  ip_type, bool secure)
 {
 	const int sdma_write_length = 128;
 	const int pm4_dw = 256;
@@ -1388,13 +1406,13 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
 	ibs_request = calloc(1, sizeof(*ibs_request));
 	CU_ASSERT_NOT_EQUAL(ibs_request, NULL);
 
-	r = amdgpu_query_hw_ip_info(device_handle, ip_type, 0, &hw_ip_info);
+	r = amdgpu_query_hw_ip_info(device, ip_type, 0, &hw_ip_info);
 	CU_ASSERT_EQUAL(r, 0);
 
 	for (i = 0; secure && (i < 2); i++)
 		gtt_flags[i] |= AMDGPU_GEM_CREATE_ENCRYPTED;
 
-	r = amdgpu_cs_ctx_create(device_handle, &context_handle);
+	r = amdgpu_cs_ctx_create(device, &context_handle);
 
 	CU_ASSERT_EQUAL(r, 0);
 
@@ -1406,7 +1424,7 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
 		loop = 0;
 		while(loop < 2) {
 			/* allocate UC bo for sDMA use */
-			r = amdgpu_bo_alloc_and_map(device_handle,
+			r = amdgpu_bo_alloc_and_map(device,
 						    sdma_write_length * sizeof(uint32_t),
 						    4096, AMDGPU_GEM_DOMAIN_GTT,
 						    gtt_flags[loop], &bo, (void**)&bo_cpu,
@@ -1445,11 +1463,10 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
 					pm4[i++] = 0xdeadbeaf;
 			}
 
-			amdgpu_test_exec_cs_helper(context_handle,
-						   ip_type, ring_id,
-						   i, pm4,
-						   1, resources,
-						   ib_info, ibs_request);
+			amdgpu_test_exec_cs_helper_raw(device, context_handle,
+						       ip_type, ring_id, i, pm4,
+						       1, resources, ib_info,
+						       ibs_request);
 
 			/* verify if SDMA test result meets with expected */
 			i = 0;
@@ -1476,7 +1493,8 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
 
 static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
 {
-	amdgpu_command_submission_write_linear_helper_with_secure(ip_type,
+	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
+								  ip_type,
 								  false);
 }
 
-- 
2.7.4

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

Re: [PATCH 06/12] tests/amdgpu: add device handle as input param for exec_cs_helper and write_linear_helper (v4)

[Luben Tuikov]

On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui <ray.huang@amd.com>
> 
> This patch is to add add device handle as input param for exec_cs_helper
> and write_linear_helper.
> 
> Because they are needed in security tests.
> 
> v2: fix typo that basic tests should be un-secure.
> v3: refine the function implementation.
> v4: remove amdgpu_cs_ctx_create3 calling.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
>  tests/amdgpu/amdgpu_test.h |  4 +++-
>  tests/amdgpu/basic_tests.c | 52 +++++++++++++++++++++++++++++++---------------
>  2 files changed, 38 insertions(+), 18 deletions(-)
> 
> diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
> index 67be437..16c2da0 100644
> --- a/tests/amdgpu/amdgpu_test.h
> +++ b/tests/amdgpu/amdgpu_test.h
> @@ -263,7 +263,9 @@ CU_BOOL suite_security_tests_enable(void);
>  extern CU_TestInfo security_tests[];
>  
>  extern void
> -amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
> +amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
> +							  device,
> +							  unsigned ip_type,
>  							  bool secure);
>  

Wasn't this already done in patch 5?
If yes, then it shouldn't be done here and only a single header file
should contain the truth.
If no, then why are two header files declaring this extern?
Should be only one.

Regards,
Luben

>  /**
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 31c9a54..5154812 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -1283,12 +1283,14 @@ static void amdgpu_command_submission_compute(void)
>   * pm4_src, resources, ib_info, and ibs_request
>   * submit command stream described in ibs_request and wait for this IB accomplished
>   */
> -static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
> -				       unsigned ip_type,
> -				       int instance, int pm4_dw, uint32_t *pm4_src,
> -				       int res_cnt, amdgpu_bo_handle *resources,
> -				       struct amdgpu_cs_ib_info *ib_info,
> -				       struct amdgpu_cs_request *ibs_request)
> +static void
> +amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
> +			       amdgpu_context_handle context_handle,
> +			       unsigned ip_type, int instance, int pm4_dw,
> +			       uint32_t *pm4_src, int res_cnt,
> +			       amdgpu_bo_handle *resources,
> +			       struct amdgpu_cs_ib_info *ib_info,
> +			       struct amdgpu_cs_request *ibs_request)
>  {
>  	int r;
>  	uint32_t expired;
> @@ -1361,8 +1363,24 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
>  	CU_ASSERT_EQUAL(r, 0);
>  }
>  
> -void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
> -							       bool secure)
> +static void
> +amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
> +			   unsigned ip_type, int instance, int pm4_dw,
> +			   uint32_t *pm4_src, int res_cnt,
> +			   amdgpu_bo_handle *resources,
> +			   struct amdgpu_cs_ib_info *ib_info,
> +			   struct amdgpu_cs_request *ibs_request)
> +{
> +	amdgpu_test_exec_cs_helper_raw(device_handle, context_handle,
> +				       ip_type, instance, pm4_dw, pm4_src,
> +				       res_cnt, resources, ib_info,
> +				       ibs_request);
> +}
> +
> +void
> +amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
> +							  device, unsigned
> +							  ip_type, bool secure)
>  {
>  	const int sdma_write_length = 128;
>  	const int pm4_dw = 256;
> @@ -1388,13 +1406,13 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
>  	ibs_request = calloc(1, sizeof(*ibs_request));
>  	CU_ASSERT_NOT_EQUAL(ibs_request, NULL);
>  
> -	r = amdgpu_query_hw_ip_info(device_handle, ip_type, 0, &hw_ip_info);
> +	r = amdgpu_query_hw_ip_info(device, ip_type, 0, &hw_ip_info);
>  	CU_ASSERT_EQUAL(r, 0);
>  
>  	for (i = 0; secure && (i < 2); i++)
>  		gtt_flags[i] |= AMDGPU_GEM_CREATE_ENCRYPTED;
>  
> -	r = amdgpu_cs_ctx_create(device_handle, &context_handle);
> +	r = amdgpu_cs_ctx_create(device, &context_handle);
>  
>  	CU_ASSERT_EQUAL(r, 0);
>  
> @@ -1406,7 +1424,7 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
>  		loop = 0;
>  		while(loop < 2) {
>  			/* allocate UC bo for sDMA use */
> -			r = amdgpu_bo_alloc_and_map(device_handle,
> +			r = amdgpu_bo_alloc_and_map(device,
>  						    sdma_write_length * sizeof(uint32_t),
>  						    4096, AMDGPU_GEM_DOMAIN_GTT,
>  						    gtt_flags[loop], &bo, (void**)&bo_cpu,
> @@ -1445,11 +1463,10 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
>  					pm4[i++] = 0xdeadbeaf;
>  			}
>  
> -			amdgpu_test_exec_cs_helper(context_handle,
> -						   ip_type, ring_id,
> -						   i, pm4,
> -						   1, resources,
> -						   ib_info, ibs_request);
> +			amdgpu_test_exec_cs_helper_raw(device, context_handle,
> +						       ip_type, ring_id, i, pm4,
> +						       1, resources, ib_info,
> +						       ibs_request);
>  
>  			/* verify if SDMA test result meets with expected */
>  			i = 0;
> @@ -1476,7 +1493,8 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
>  
>  static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
>  {
> -	amdgpu_command_submission_write_linear_helper_with_secure(ip_type,
> +	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
> +								  ip_type,
>  								  false);
>  }
>  
> 

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

Re: [PATCH 06/12] tests/amdgpu: add device handle as input param for exec_cs_helper and write_linear_helper (v4)

[Luben Tuikov]

On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui <ray.huang@amd.com>
> 
> This patch is to add add device handle as input param for exec_cs_helper
> and write_linear_helper.
> 
> Because they are needed in security tests.
> 
> v2: fix typo that basic tests should be un-secure.
> v3: refine the function implementation.
> v4: remove amdgpu_cs_ctx_create3 calling.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
>  tests/amdgpu/amdgpu_test.h |  4 +++-
>  tests/amdgpu/basic_tests.c | 52 +++++++++++++++++++++++++++++++---------------
>  2 files changed, 38 insertions(+), 18 deletions(-)
> 
> diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
> index 67be437..16c2da0 100644
> --- a/tests/amdgpu/amdgpu_test.h
> +++ b/tests/amdgpu/amdgpu_test.h
> @@ -263,7 +263,9 @@ CU_BOOL suite_security_tests_enable(void);
>  extern CU_TestInfo security_tests[];
>  
>  extern void
> -amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
> +amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
> +							  device,
> +							  unsigned ip_type,
>  							  bool secure);
>  

Wasn't this already done in patch 5?
If yes, then it shouldn't be done here and only a single header file
should contain the truth.
If no, then why are two header files declaring this extern?
Should be only one.

Regards,
Luben

>  /**
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 31c9a54..5154812 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -1283,12 +1283,14 @@ static void amdgpu_command_submission_compute(void)
>   * pm4_src, resources, ib_info, and ibs_request
>   * submit command stream described in ibs_request and wait for this IB accomplished
>   */
> -static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
> -				       unsigned ip_type,
> -				       int instance, int pm4_dw, uint32_t *pm4_src,
> -				       int res_cnt, amdgpu_bo_handle *resources,
> -				       struct amdgpu_cs_ib_info *ib_info,
> -				       struct amdgpu_cs_request *ibs_request)
> +static void
> +amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
> +			       amdgpu_context_handle context_handle,
> +			       unsigned ip_type, int instance, int pm4_dw,
> +			       uint32_t *pm4_src, int res_cnt,
> +			       amdgpu_bo_handle *resources,
> +			       struct amdgpu_cs_ib_info *ib_info,
> +			       struct amdgpu_cs_request *ibs_request)
>  {
>  	int r;
>  	uint32_t expired;
> @@ -1361,8 +1363,24 @@ static void amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
>  	CU_ASSERT_EQUAL(r, 0);
>  }
>  
> -void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
> -							       bool secure)
> +static void
> +amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
> +			   unsigned ip_type, int instance, int pm4_dw,
> +			   uint32_t *pm4_src, int res_cnt,
> +			   amdgpu_bo_handle *resources,
> +			   struct amdgpu_cs_ib_info *ib_info,
> +			   struct amdgpu_cs_request *ibs_request)
> +{
> +	amdgpu_test_exec_cs_helper_raw(device_handle, context_handle,
> +				       ip_type, instance, pm4_dw, pm4_src,
> +				       res_cnt, resources, ib_info,
> +				       ibs_request);
> +}
> +
> +void
> +amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
> +							  device, unsigned
> +							  ip_type, bool secure)
>  {
>  	const int sdma_write_length = 128;
>  	const int pm4_dw = 256;
> @@ -1388,13 +1406,13 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
>  	ibs_request = calloc(1, sizeof(*ibs_request));
>  	CU_ASSERT_NOT_EQUAL(ibs_request, NULL);
>  
> -	r = amdgpu_query_hw_ip_info(device_handle, ip_type, 0, &hw_ip_info);
> +	r = amdgpu_query_hw_ip_info(device, ip_type, 0, &hw_ip_info);
>  	CU_ASSERT_EQUAL(r, 0);
>  
>  	for (i = 0; secure && (i < 2); i++)
>  		gtt_flags[i] |= AMDGPU_GEM_CREATE_ENCRYPTED;
>  
> -	r = amdgpu_cs_ctx_create(device_handle, &context_handle);
> +	r = amdgpu_cs_ctx_create(device, &context_handle);
>  
>  	CU_ASSERT_EQUAL(r, 0);
>  
> @@ -1406,7 +1424,7 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
>  		loop = 0;
>  		while(loop < 2) {
>  			/* allocate UC bo for sDMA use */
> -			r = amdgpu_bo_alloc_and_map(device_handle,
> +			r = amdgpu_bo_alloc_and_map(device,
>  						    sdma_write_length * sizeof(uint32_t),
>  						    4096, AMDGPU_GEM_DOMAIN_GTT,
>  						    gtt_flags[loop], &bo, (void**)&bo_cpu,
> @@ -1445,11 +1463,10 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
>  					pm4[i++] = 0xdeadbeaf;
>  			}
>  
> -			amdgpu_test_exec_cs_helper(context_handle,
> -						   ip_type, ring_id,
> -						   i, pm4,
> -						   1, resources,
> -						   ib_info, ibs_request);
> +			amdgpu_test_exec_cs_helper_raw(device, context_handle,
> +						       ip_type, ring_id, i, pm4,
> +						       1, resources, ib_info,
> +						       ibs_request);
>  
>  			/* verify if SDMA test result meets with expected */
>  			i = 0;
> @@ -1476,7 +1493,8 @@ void amdgpu_command_submission_write_linear_helper_with_secure(unsigned ip_type,
>  
>  static void amdgpu_command_submission_write_linear_helper(unsigned ip_type)
>  {
> -	amdgpu_command_submission_write_linear_helper_with_secure(ip_type,
> +	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
> +								  ip_type,
>  								  false);
>  }
>  
> 

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

[PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ

[Aaron Liu]

In kernel, cs->in.flags is used for TMZ. Hence libdrm should transfer
the flag to kernel.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 amdgpu/amdgpu.h    | 4 +++-
 amdgpu/amdgpu_cs.c | 4 ++++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index f45f9f7..aee3f3d 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -342,7 +342,9 @@ struct amdgpu_cs_fence_info {
  * \sa amdgpu_cs_submit()
 */
 struct amdgpu_cs_request {
-	/** Specify flags with additional information */
+	/** Specify flags with additional information
+	 * 0-normal, 1-tmz
+	 */
 	uint64_t flags;
 
 	/** Specify HW IP block type to which to send the IB. */
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 437c4a4..6f70771 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -254,6 +254,10 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle context,
 	memset(&cs, 0, sizeof(cs));
 	cs.in.chunks = (uint64_t)(uintptr_t)chunk_array;
 	cs.in.ctx_id = context->id;
+	/* in kernel, _pad is used as flags
+	 * #define AMDGPU_CS_FLAGS_SECURE          (1 << 0)
+	 */
+	cs.in._pad = (uint32_t)ibs_request->flags;
 	if (ibs_request->resources)
 		cs.in.bo_list_handle = ibs_request->resources->handle;
 	cs.in.num_chunks = ibs_request->number_of_ibs;
-- 
2.7.4

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

[PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ

[Aaron Liu]

In kernel, cs->in.flags is used for TMZ. Hence libdrm should transfer
the flag to kernel.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 amdgpu/amdgpu.h    | 4 +++-
 amdgpu/amdgpu_cs.c | 4 ++++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index f45f9f7..aee3f3d 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -342,7 +342,9 @@ struct amdgpu_cs_fence_info {
  * \sa amdgpu_cs_submit()
 */
 struct amdgpu_cs_request {
-	/** Specify flags with additional information */
+	/** Specify flags with additional information
+	 * 0-normal, 1-tmz
+	 */
 	uint64_t flags;
 
 	/** Specify HW IP block type to which to send the IB. */
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 437c4a4..6f70771 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -254,6 +254,10 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle context,
 	memset(&cs, 0, sizeof(cs));
 	cs.in.chunks = (uint64_t)(uintptr_t)chunk_array;
 	cs.in.ctx_id = context->id;
+	/* in kernel, _pad is used as flags
+	 * #define AMDGPU_CS_FLAGS_SECURE          (1 << 0)
+	 */
+	cs.in._pad = (uint32_t)ibs_request->flags;
 	if (ibs_request->resources)
 		cs.in.bo_list_handle = ibs_request->resources->handle;
 	cs.in.num_chunks = ibs_request->number_of_ibs;
-- 
2.7.4

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

Re: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ

[Christian König]

Am 15.11.19 um 10:32 schrieb Huang Rui:
> On Fri, Nov 15, 2019 at 11:34:50AM +0800, Liu, Aaron wrote:
>> In kernel, cs->in.flags is used for TMZ. Hence libdrm should transfer
>> the flag to kernel.
>>
>> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
>> ---
>>   amdgpu/amdgpu.h    | 4 +++-
>>   amdgpu/amdgpu_cs.c | 4 ++++
>>   2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
>> index f45f9f7..aee3f3d 100644
>> --- a/amdgpu/amdgpu.h
>> +++ b/amdgpu/amdgpu.h
>> @@ -342,7 +342,9 @@ struct amdgpu_cs_fence_info {
>>    * \sa amdgpu_cs_submit()
>>   */
>>   struct amdgpu_cs_request {
>> -	/** Specify flags with additional information */
>> +	/** Specify flags with additional information
>> +	 * 0-normal, 1-tmz
>> +	 */
>>   	uint64_t flags;
>>   
>>   	/** Specify HW IP block type to which to send the IB. */
>> diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
>> index 437c4a4..6f70771 100644
>> --- a/amdgpu/amdgpu_cs.c
>> +++ b/amdgpu/amdgpu_cs.c
>> @@ -254,6 +254,10 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle context,
>>   	memset(&cs, 0, sizeof(cs));
>>   	cs.in.chunks = (uint64_t)(uintptr_t)chunk_array;
>>   	cs.in.ctx_id = context->id;
>> +	/* in kernel, _pad is used as flags
>> +	 * #define AMDGPU_CS_FLAGS_SECURE          (1 << 0)
>> +	 */
>> +	cs.in._pad = (uint32_t)ibs_request->flags;
> _pad is not good here. Because it's used to pass the flags to input param.
>
> It's better to rename "_pad" in drm_amdgpu_cs_in as "flags" here.

Actually I don't think we need that stuff altogether, please sync up 
with Marek on this.

As far asI know the whole amdgpu_cs_submit interface was deprecated in 
favor of the new amdgpu_cs_submit_raw() interface.

Regards,
Christian.

>
> Thanks,
> Ray
>
>>   	if (ibs_request->resources)
>>   		cs.in.bo_list_handle = ibs_request->resources->handle;
>>   	cs.in.num_chunks = ibs_request->number_of_ibs;
>> -- 
>> 2.7.4
>>

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

Re: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ

[Christian König]

Am 15.11.19 um 10:32 schrieb Huang Rui:
> On Fri, Nov 15, 2019 at 11:34:50AM +0800, Liu, Aaron wrote:
>> In kernel, cs->in.flags is used for TMZ. Hence libdrm should transfer
>> the flag to kernel.
>>
>> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
>> ---
>>   amdgpu/amdgpu.h    | 4 +++-
>>   amdgpu/amdgpu_cs.c | 4 ++++
>>   2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
>> index f45f9f7..aee3f3d 100644
>> --- a/amdgpu/amdgpu.h
>> +++ b/amdgpu/amdgpu.h
>> @@ -342,7 +342,9 @@ struct amdgpu_cs_fence_info {
>>    * \sa amdgpu_cs_submit()
>>   */
>>   struct amdgpu_cs_request {
>> -	/** Specify flags with additional information */
>> +	/** Specify flags with additional information
>> +	 * 0-normal, 1-tmz
>> +	 */
>>   	uint64_t flags;
>>   
>>   	/** Specify HW IP block type to which to send the IB. */
>> diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
>> index 437c4a4..6f70771 100644
>> --- a/amdgpu/amdgpu_cs.c
>> +++ b/amdgpu/amdgpu_cs.c
>> @@ -254,6 +254,10 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle context,
>>   	memset(&cs, 0, sizeof(cs));
>>   	cs.in.chunks = (uint64_t)(uintptr_t)chunk_array;
>>   	cs.in.ctx_id = context->id;
>> +	/* in kernel, _pad is used as flags
>> +	 * #define AMDGPU_CS_FLAGS_SECURE          (1 << 0)
>> +	 */
>> +	cs.in._pad = (uint32_t)ibs_request->flags;
> _pad is not good here. Because it's used to pass the flags to input param.
>
> It's better to rename "_pad" in drm_amdgpu_cs_in as "flags" here.

Actually I don't think we need that stuff altogether, please sync up 
with Marek on this.

As far asI know the whole amdgpu_cs_submit interface was deprecated in 
favor of the new amdgpu_cs_submit_raw() interface.

Regards,
Christian.

>
> Thanks,
> Ray
>
>>   	if (ibs_request->resources)
>>   		cs.in.bo_list_handle = ibs_request->resources->handle;
>>   	cs.in.num_chunks = ibs_request->number_of_ibs;
>> -- 
>> 2.7.4
>>

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

RE: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ

[Liu, Aaron]

BR,
Aaron Liu

> -----Original Message-----
> From: Koenig, Christian <Christian.Koenig@amd.com>
> Sent: Friday, November 15, 2019 8:50 PM
> To: Huang, Ray <Ray.Huang@amd.com>; Liu, Aaron <Aaron.Liu@amd.com>
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> <Alexander.Deucher@amd.com>; Olsak, Marek <Marek.Olsak@amd.com>;
> Liu, Leo <Leo.Liu@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>
> Subject: Re: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ
> 
> Am 15.11.19 um 10:32 schrieb Huang Rui:
> > On Fri, Nov 15, 2019 at 11:34:50AM +0800, Liu, Aaron wrote:
> >> In kernel, cs->in.flags is used for TMZ. Hence libdrm should transfer
> >> the flag to kernel.
> >>
> >> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
> >> ---
> >>   amdgpu/amdgpu.h    | 4 +++-
> >>   amdgpu/amdgpu_cs.c | 4 ++++
> >>   2 files changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h index
> f45f9f7..aee3f3d
> >> 100644
> >> --- a/amdgpu/amdgpu.h
> >> +++ b/amdgpu/amdgpu.h
> >> @@ -342,7 +342,9 @@ struct amdgpu_cs_fence_info {
> >>    * \sa amdgpu_cs_submit()
> >>   */
> >>   struct amdgpu_cs_request {
> >> -	/** Specify flags with additional information */
> >> +	/** Specify flags with additional information
> >> +	 * 0-normal, 1-tmz
> >> +	 */
> >>   	uint64_t flags;
> >>
> >>   	/** Specify HW IP block type to which to send the IB. */ diff
> >> --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c index
> >> 437c4a4..6f70771 100644
> >> --- a/amdgpu/amdgpu_cs.c
> >> +++ b/amdgpu/amdgpu_cs.c
> >> @@ -254,6 +254,10 @@ static int
> amdgpu_cs_submit_one(amdgpu_context_handle context,
> >>   	memset(&cs, 0, sizeof(cs));
> >>   	cs.in.chunks = (uint64_t)(uintptr_t)chunk_array;
> >>   	cs.in.ctx_id = context->id;
> >> +	/* in kernel, _pad is used as flags
> >> +	 * #define AMDGPU_CS_FLAGS_SECURE          (1 << 0)
> >> +	 */
> >> +	cs.in._pad = (uint32_t)ibs_request->flags;
> > _pad is not good here. Because it's used to pass the flags to input param.
> >
> > It's better to rename "_pad" in drm_amdgpu_cs_in as "flags" here.
> 
> Actually I don't think we need that stuff altogether, please sync up with
> Marek on this.
> 
> As far asI know the whole amdgpu_cs_submit interface was deprecated in
> favor of the new amdgpu_cs_submit_raw() interface.

Christian, Marek,
In addition to syncobj_command_submission_helper uses amdgpu_cs_submit_raw, 
the other test suites still use older interface(amdgpu_cs_submit). We'd better to 
reorganize the relevant codes. This does not make much sense to only modify one call.


> Regards,
> Christian.
> 
> >
> > Thanks,
> > Ray
> >
> >>   	if (ibs_request->resources)
> >>   		cs.in.bo_list_handle = ibs_request->resources->handle;
> >>   	cs.in.num_chunks = ibs_request->number_of_ibs;
> >> --
> >> 2.7.4
> >>

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

RE: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ

[Liu, Aaron]

BR,
Aaron Liu

> -----Original Message-----
> From: Koenig, Christian <Christian.Koenig@amd.com>
> Sent: Friday, November 15, 2019 8:50 PM
> To: Huang, Ray <Ray.Huang@amd.com>; Liu, Aaron <Aaron.Liu@amd.com>
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> <Alexander.Deucher@amd.com>; Olsak, Marek <Marek.Olsak@amd.com>;
> Liu, Leo <Leo.Liu@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>
> Subject: Re: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ
> 
> Am 15.11.19 um 10:32 schrieb Huang Rui:
> > On Fri, Nov 15, 2019 at 11:34:50AM +0800, Liu, Aaron wrote:
> >> In kernel, cs->in.flags is used for TMZ. Hence libdrm should transfer
> >> the flag to kernel.
> >>
> >> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
> >> ---
> >>   amdgpu/amdgpu.h    | 4 +++-
> >>   amdgpu/amdgpu_cs.c | 4 ++++
> >>   2 files changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h index
> f45f9f7..aee3f3d
> >> 100644
> >> --- a/amdgpu/amdgpu.h
> >> +++ b/amdgpu/amdgpu.h
> >> @@ -342,7 +342,9 @@ struct amdgpu_cs_fence_info {
> >>    * \sa amdgpu_cs_submit()
> >>   */
> >>   struct amdgpu_cs_request {
> >> -	/** Specify flags with additional information */
> >> +	/** Specify flags with additional information
> >> +	 * 0-normal, 1-tmz
> >> +	 */
> >>   	uint64_t flags;
> >>
> >>   	/** Specify HW IP block type to which to send the IB. */ diff
> >> --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c index
> >> 437c4a4..6f70771 100644
> >> --- a/amdgpu/amdgpu_cs.c
> >> +++ b/amdgpu/amdgpu_cs.c
> >> @@ -254,6 +254,10 @@ static int
> amdgpu_cs_submit_one(amdgpu_context_handle context,
> >>   	memset(&cs, 0, sizeof(cs));
> >>   	cs.in.chunks = (uint64_t)(uintptr_t)chunk_array;
> >>   	cs.in.ctx_id = context->id;
> >> +	/* in kernel, _pad is used as flags
> >> +	 * #define AMDGPU_CS_FLAGS_SECURE          (1 << 0)
> >> +	 */
> >> +	cs.in._pad = (uint32_t)ibs_request->flags;
> > _pad is not good here. Because it's used to pass the flags to input param.
> >
> > It's better to rename "_pad" in drm_amdgpu_cs_in as "flags" here.
> 
> Actually I don't think we need that stuff altogether, please sync up with
> Marek on this.
> 
> As far asI know the whole amdgpu_cs_submit interface was deprecated in
> favor of the new amdgpu_cs_submit_raw() interface.

Christian, Marek,
In addition to syncobj_command_submission_helper uses amdgpu_cs_submit_raw, 
the other test suites still use older interface(amdgpu_cs_submit). We'd better to 
reorganize the relevant codes. This does not make much sense to only modify one call.


> Regards,
> Christian.
> 
> >
> > Thanks,
> > Ray
> >
> >>   	if (ibs_request->resources)
> >>   		cs.in.bo_list_handle = ibs_request->resources->handle;
> >>   	cs.in.num_chunks = ibs_request->number_of_ibs;
> >> --
> >> 2.7.4
> >>

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

Re: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ

[Christian König]

Am 18.11.19 um 10:19 schrieb Liu, Aaron:
>
> BR,
> Aaron Liu
>
>> -----Original Message-----
>> From: Koenig, Christian <Christian.Koenig@amd.com>
>> Sent: Friday, November 15, 2019 8:50 PM
>> To: Huang, Ray <Ray.Huang@amd.com>; Liu, Aaron <Aaron.Liu@amd.com>
>> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
>> <Alexander.Deucher@amd.com>; Olsak, Marek <Marek.Olsak@amd.com>;
>> Liu, Leo <Leo.Liu@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>
>> Subject: Re: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ
>>
>> Am 15.11.19 um 10:32 schrieb Huang Rui:
>>> On Fri, Nov 15, 2019 at 11:34:50AM +0800, Liu, Aaron wrote:
>>>> In kernel, cs->in.flags is used for TMZ. Hence libdrm should transfer
>>>> the flag to kernel.
>>>>
>>>> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
>>>> ---
>>>>    amdgpu/amdgpu.h    | 4 +++-
>>>>    amdgpu/amdgpu_cs.c | 4 ++++
>>>>    2 files changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h index
>> f45f9f7..aee3f3d
>>>> 100644
>>>> --- a/amdgpu/amdgpu.h
>>>> +++ b/amdgpu/amdgpu.h
>>>> @@ -342,7 +342,9 @@ struct amdgpu_cs_fence_info {
>>>>     * \sa amdgpu_cs_submit()
>>>>    */
>>>>    struct amdgpu_cs_request {
>>>> -	/** Specify flags with additional information */
>>>> +	/** Specify flags with additional information
>>>> +	 * 0-normal, 1-tmz
>>>> +	 */
>>>>    	uint64_t flags;
>>>>
>>>>    	/** Specify HW IP block type to which to send the IB. */ diff
>>>> --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c index
>>>> 437c4a4..6f70771 100644
>>>> --- a/amdgpu/amdgpu_cs.c
>>>> +++ b/amdgpu/amdgpu_cs.c
>>>> @@ -254,6 +254,10 @@ static int
>> amdgpu_cs_submit_one(amdgpu_context_handle context,
>>>>    	memset(&cs, 0, sizeof(cs));
>>>>    	cs.in.chunks = (uint64_t)(uintptr_t)chunk_array;
>>>>    	cs.in.ctx_id = context->id;
>>>> +	/* in kernel, _pad is used as flags
>>>> +	 * #define AMDGPU_CS_FLAGS_SECURE          (1 << 0)
>>>> +	 */
>>>> +	cs.in._pad = (uint32_t)ibs_request->flags;
>>> _pad is not good here. Because it's used to pass the flags to input param.
>>>
>>> It's better to rename "_pad" in drm_amdgpu_cs_in as "flags" here.
>> Actually I don't think we need that stuff altogether, please sync up with
>> Marek on this.
>>
>> As far asI know the whole amdgpu_cs_submit interface was deprecated in
>> favor of the new amdgpu_cs_submit_raw() interface.
> Christian, Marek,
> In addition to syncobj_command_submission_helper uses amdgpu_cs_submit_raw,
> the other test suites still use older interface(amdgpu_cs_submit). We'd better to
> reorganize the relevant codes. This does not make much sense to only modify one call.

Well in this case you need to change all other test cases to use 
amdgpu_cs_submit_raw as well.

I will certainly reject any changes to the deprecated command submission 
interface.

That has just way to much potential to break older versions of the 
userspace stack in unforeseen ways.

Regards,
Christian.

>
>
>> Regards,
>> Christian.
>>
>>> Thanks,
>>> Ray
>>>
>>>>    	if (ibs_request->resources)
>>>>    		cs.in.bo_list_handle = ibs_request->resources->handle;
>>>>    	cs.in.num_chunks = ibs_request->number_of_ibs;
>>>> --
>>>> 2.7.4
>>>>

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

Re: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ

[Christian König]

Am 18.11.19 um 10:19 schrieb Liu, Aaron:
>
> BR,
> Aaron Liu
>
>> -----Original Message-----
>> From: Koenig, Christian <Christian.Koenig@amd.com>
>> Sent: Friday, November 15, 2019 8:50 PM
>> To: Huang, Ray <Ray.Huang@amd.com>; Liu, Aaron <Aaron.Liu@amd.com>
>> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
>> <Alexander.Deucher@amd.com>; Olsak, Marek <Marek.Olsak@amd.com>;
>> Liu, Leo <Leo.Liu@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>
>> Subject: Re: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ
>>
>> Am 15.11.19 um 10:32 schrieb Huang Rui:
>>> On Fri, Nov 15, 2019 at 11:34:50AM +0800, Liu, Aaron wrote:
>>>> In kernel, cs->in.flags is used for TMZ. Hence libdrm should transfer
>>>> the flag to kernel.
>>>>
>>>> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
>>>> ---
>>>>    amdgpu/amdgpu.h    | 4 +++-
>>>>    amdgpu/amdgpu_cs.c | 4 ++++
>>>>    2 files changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h index
>> f45f9f7..aee3f3d
>>>> 100644
>>>> --- a/amdgpu/amdgpu.h
>>>> +++ b/amdgpu/amdgpu.h
>>>> @@ -342,7 +342,9 @@ struct amdgpu_cs_fence_info {
>>>>     * \sa amdgpu_cs_submit()
>>>>    */
>>>>    struct amdgpu_cs_request {
>>>> -	/** Specify flags with additional information */
>>>> +	/** Specify flags with additional information
>>>> +	 * 0-normal, 1-tmz
>>>> +	 */
>>>>    	uint64_t flags;
>>>>
>>>>    	/** Specify HW IP block type to which to send the IB. */ diff
>>>> --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c index
>>>> 437c4a4..6f70771 100644
>>>> --- a/amdgpu/amdgpu_cs.c
>>>> +++ b/amdgpu/amdgpu_cs.c
>>>> @@ -254,6 +254,10 @@ static int
>> amdgpu_cs_submit_one(amdgpu_context_handle context,
>>>>    	memset(&cs, 0, sizeof(cs));
>>>>    	cs.in.chunks = (uint64_t)(uintptr_t)chunk_array;
>>>>    	cs.in.ctx_id = context->id;
>>>> +	/* in kernel, _pad is used as flags
>>>> +	 * #define AMDGPU_CS_FLAGS_SECURE          (1 << 0)
>>>> +	 */
>>>> +	cs.in._pad = (uint32_t)ibs_request->flags;
>>> _pad is not good here. Because it's used to pass the flags to input param.
>>>
>>> It's better to rename "_pad" in drm_amdgpu_cs_in as "flags" here.
>> Actually I don't think we need that stuff altogether, please sync up with
>> Marek on this.
>>
>> As far asI know the whole amdgpu_cs_submit interface was deprecated in
>> favor of the new amdgpu_cs_submit_raw() interface.
> Christian, Marek,
> In addition to syncobj_command_submission_helper uses amdgpu_cs_submit_raw,
> the other test suites still use older interface(amdgpu_cs_submit). We'd better to
> reorganize the relevant codes. This does not make much sense to only modify one call.

Well in this case you need to change all other test cases to use 
amdgpu_cs_submit_raw as well.

I will certainly reject any changes to the deprecated command submission 
interface.

That has just way to much potential to break older versions of the 
userspace stack in unforeseen ways.

Regards,
Christian.

>
>
>> Regards,
>> Christian.
>>
>>> Thanks,
>>> Ray
>>>
>>>>    	if (ibs_request->resources)
>>>>    		cs.in.bo_list_handle = ibs_request->resources->handle;
>>>>    	cs.in.num_chunks = ibs_request->number_of_ibs;
>>>> --
>>>> 2.7.4
>>>>

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

[PATCH 08/12] tests/amdgpu: expand secure param for exec_cs_helper

[Aaron Liu]

This patch expands secure param for amdgpu_test_exec_cs_helper_raw.
The flag is transfered to kernel with cs.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 tests/amdgpu/basic_tests.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 5154812..956be93 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -1290,7 +1290,8 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
 			       uint32_t *pm4_src, int res_cnt,
 			       amdgpu_bo_handle *resources,
 			       struct amdgpu_cs_ib_info *ib_info,
-			       struct amdgpu_cs_request *ibs_request)
+			       struct amdgpu_cs_request *ibs_request,
+			       bool secure)
 {
 	int r;
 	uint32_t expired;
@@ -1324,6 +1325,7 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
 	ib_info->size = pm4_dw;
 
 	ibs_request->ip_type = ip_type;
+	ibs_request->flags = secure ? 1 : 0;
 	ibs_request->ring = instance;
 	ibs_request->number_of_ibs = 1;
 	ibs_request->ibs = ib_info;
@@ -1374,7 +1376,7 @@ amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
 	amdgpu_test_exec_cs_helper_raw(device_handle, context_handle,
 				       ip_type, instance, pm4_dw, pm4_src,
 				       res_cnt, resources, ib_info,
-				       ibs_request);
+				       ibs_request, false);
 }
 
 void
@@ -1466,7 +1468,7 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
 			amdgpu_test_exec_cs_helper_raw(device, context_handle,
 						       ip_type, ring_id, i, pm4,
 						       1, resources, ib_info,
-						       ibs_request);
+						       ibs_request, secure);
 
 			/* verify if SDMA test result meets with expected */
 			i = 0;
-- 
2.7.4

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

[PATCH 08/12] tests/amdgpu: expand secure param for exec_cs_helper

[Aaron Liu]

This patch expands secure param for amdgpu_test_exec_cs_helper_raw.
The flag is transfered to kernel with cs.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 tests/amdgpu/basic_tests.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 5154812..956be93 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -1290,7 +1290,8 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
 			       uint32_t *pm4_src, int res_cnt,
 			       amdgpu_bo_handle *resources,
 			       struct amdgpu_cs_ib_info *ib_info,
-			       struct amdgpu_cs_request *ibs_request)
+			       struct amdgpu_cs_request *ibs_request,
+			       bool secure)
 {
 	int r;
 	uint32_t expired;
@@ -1324,6 +1325,7 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
 	ib_info->size = pm4_dw;
 
 	ibs_request->ip_type = ip_type;
+	ibs_request->flags = secure ? 1 : 0;
 	ibs_request->ring = instance;
 	ibs_request->number_of_ibs = 1;
 	ibs_request->ibs = ib_info;
@@ -1374,7 +1376,7 @@ amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
 	amdgpu_test_exec_cs_helper_raw(device_handle, context_handle,
 				       ip_type, instance, pm4_dw, pm4_src,
 				       res_cnt, resources, ib_info,
-				       ibs_request);
+				       ibs_request, false);
 }
 
 void
@@ -1466,7 +1468,7 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
 			amdgpu_test_exec_cs_helper_raw(device, context_handle,
 						       ip_type, ring_id, i, pm4,
 						       1, resources, ib_info,
-						       ibs_request);
+						       ibs_request, secure);
 
 			/* verify if SDMA test result meets with expected */
 			i = 0;
-- 
2.7.4

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

Re: [PATCH 08/12] tests/amdgpu: expand secure param for exec_cs_helper

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:51AM +0800, Liu, Aaron wrote:
> This patch expands secure param for amdgpu_test_exec_cs_helper_raw.
> The flag is transfered to kernel with cs.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Acked-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/basic_tests.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 5154812..956be93 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -1290,7 +1290,8 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
>  			       uint32_t *pm4_src, int res_cnt,
>  			       amdgpu_bo_handle *resources,
>  			       struct amdgpu_cs_ib_info *ib_info,
> -			       struct amdgpu_cs_request *ibs_request)
> +			       struct amdgpu_cs_request *ibs_request,
> +			       bool secure)
>  {
>  	int r;
>  	uint32_t expired;
> @@ -1324,6 +1325,7 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
>  	ib_info->size = pm4_dw;
>  
>  	ibs_request->ip_type = ip_type;
> +	ibs_request->flags = secure ? 1 : 0;
>  	ibs_request->ring = instance;
>  	ibs_request->number_of_ibs = 1;
>  	ibs_request->ibs = ib_info;
> @@ -1374,7 +1376,7 @@ amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
>  	amdgpu_test_exec_cs_helper_raw(device_handle, context_handle,
>  				       ip_type, instance, pm4_dw, pm4_src,
>  				       res_cnt, resources, ib_info,
> -				       ibs_request);
> +				       ibs_request, false);
>  }
>  
>  void
> @@ -1466,7 +1468,7 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  			amdgpu_test_exec_cs_helper_raw(device, context_handle,
>  						       ip_type, ring_id, i, pm4,
>  						       1, resources, ib_info,
> -						       ibs_request);
> +						       ibs_request, secure);
>  
>  			/* verify if SDMA test result meets with expected */
>  			i = 0;
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 08/12] tests/amdgpu: expand secure param for exec_cs_helper

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:51AM +0800, Liu, Aaron wrote:
> This patch expands secure param for amdgpu_test_exec_cs_helper_raw.
> The flag is transfered to kernel with cs.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Acked-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/basic_tests.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 5154812..956be93 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -1290,7 +1290,8 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
>  			       uint32_t *pm4_src, int res_cnt,
>  			       amdgpu_bo_handle *resources,
>  			       struct amdgpu_cs_ib_info *ib_info,
> -			       struct amdgpu_cs_request *ibs_request)
> +			       struct amdgpu_cs_request *ibs_request,
> +			       bool secure)
>  {
>  	int r;
>  	uint32_t expired;
> @@ -1324,6 +1325,7 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
>  	ib_info->size = pm4_dw;
>  
>  	ibs_request->ip_type = ip_type;
> +	ibs_request->flags = secure ? 1 : 0;
>  	ibs_request->ring = instance;
>  	ibs_request->number_of_ibs = 1;
>  	ibs_request->ibs = ib_info;
> @@ -1374,7 +1376,7 @@ amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
>  	amdgpu_test_exec_cs_helper_raw(device_handle, context_handle,
>  				       ip_type, instance, pm4_dw, pm4_src,
>  				       res_cnt, resources, ib_info,
> -				       ibs_request);
> +				       ibs_request, false);
>  }
>  
>  void
> @@ -1466,7 +1468,7 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  			amdgpu_test_exec_cs_helper_raw(device, context_handle,
>  						       ip_type, ring_id, i, pm4,
>  						       1, resources, ib_info,
> -						       ibs_request);
> +						       ibs_request, secure);
>  
>  			/* verify if SDMA test result meets with expected */
>  			i = 0;
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 08/12] tests/amdgpu: expand secure param for exec_cs_helper

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:51AM +0800, Liu, Aaron wrote:
> This patch expands secure param for amdgpu_test_exec_cs_helper_raw.
> The flag is transfered to kernel with cs.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Acked-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/basic_tests.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 5154812..956be93 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -1290,7 +1290,8 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
>  			       uint32_t *pm4_src, int res_cnt,
>  			       amdgpu_bo_handle *resources,
>  			       struct amdgpu_cs_ib_info *ib_info,
> -			       struct amdgpu_cs_request *ibs_request)
> +			       struct amdgpu_cs_request *ibs_request,
> +			       bool secure)
>  {
>  	int r;
>  	uint32_t expired;
> @@ -1324,6 +1325,7 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
>  	ib_info->size = pm4_dw;
>  
>  	ibs_request->ip_type = ip_type;
> +	ibs_request->flags = secure ? 1 : 0;
>  	ibs_request->ring = instance;
>  	ibs_request->number_of_ibs = 1;
>  	ibs_request->ibs = ib_info;
> @@ -1374,7 +1376,7 @@ amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
>  	amdgpu_test_exec_cs_helper_raw(device_handle, context_handle,
>  				       ip_type, instance, pm4_dw, pm4_src,
>  				       res_cnt, resources, ib_info,
> -				       ibs_request);
> +				       ibs_request, false);
>  }
>  
>  void
> @@ -1466,7 +1468,7 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  			amdgpu_test_exec_cs_helper_raw(device, context_handle,
>  						       ip_type, ring_id, i, pm4,
>  						       1, resources, ib_info,
> -						       ibs_request);
> +						       ibs_request, secure);
>  
>  			/* verify if SDMA test result meets with expected */
>  			i = 0;
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 08/12] tests/amdgpu: expand secure param for exec_cs_helper

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:51AM +0800, Liu, Aaron wrote:
> This patch expands secure param for amdgpu_test_exec_cs_helper_raw.
> The flag is transfered to kernel with cs.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Acked-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/basic_tests.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 5154812..956be93 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -1290,7 +1290,8 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
>  			       uint32_t *pm4_src, int res_cnt,
>  			       amdgpu_bo_handle *resources,
>  			       struct amdgpu_cs_ib_info *ib_info,
> -			       struct amdgpu_cs_request *ibs_request)
> +			       struct amdgpu_cs_request *ibs_request,
> +			       bool secure)
>  {
>  	int r;
>  	uint32_t expired;
> @@ -1324,6 +1325,7 @@ amdgpu_test_exec_cs_helper_raw(amdgpu_device_handle device_handle,
>  	ib_info->size = pm4_dw;
>  
>  	ibs_request->ip_type = ip_type;
> +	ibs_request->flags = secure ? 1 : 0;
>  	ibs_request->ring = instance;
>  	ibs_request->number_of_ibs = 1;
>  	ibs_request->ibs = ib_info;
> @@ -1374,7 +1376,7 @@ amdgpu_test_exec_cs_helper(amdgpu_context_handle context_handle,
>  	amdgpu_test_exec_cs_helper_raw(device_handle, context_handle,
>  				       ip_type, instance, pm4_dw, pm4_src,
>  				       res_cnt, resources, ib_info,
> -				       ibs_request);
> +				       ibs_request, false);
>  }
>  
>  void
> @@ -1466,7 +1468,7 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  			amdgpu_test_exec_cs_helper_raw(device, context_handle,
>  						       ip_type, ring_id, i, pm4,
>  						       1, resources, ib_info,
> -						       ibs_request);
> +						       ibs_request, secure);
>  
>  			/* verify if SDMA test result meets with expected */
>  			i = 0;
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 09/12] tests/amdgpu: add atomic_mem cp_packet to verify the secure buffer

[Aaron Liu]

Secure buffer is only able to be read with trusted ip block.
So we need use GFX ip to read it back instead of CPU.
Steps:
1. use write_data packet to write 0xdeadbeaf to secure buffer,
2. use atmoic_mem packet and ATOMIC_CMPSWAP_RTN_32 opcode to compare
the cmp_data(0xdeadbeaf) to the written data which has been encrypted.
If the result is equal, then overwrite the src_data(0x12345678) to the
secure buffer and return directly. Otherwise loop again until gfx timeout
and the secure buffer data unchanged.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 tests/amdgpu/basic_tests.c | 43 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 956be93..907237e 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -160,6 +160,20 @@ CU_TestInfo basic_tests[] = {
 		 * 2 - ce
 		 */
 
+#define	PACKET3_ATOMIC_MEM				0x1E
+#define     TC_OP_ATOMIC_CMPSWAP_RTN_32          0x00000008
+#define     ATOMIC_MEM_COMMAND(x)               ((x) << 8)
+            /* 0 - single_pass_atomic.
+             * 1 - loop_until_compare_satisfied.
+             */
+#define     ATOMIC_MEM_CACHEPOLICAY(x)          ((x) << 25)
+            /* 0 - lru.
+             * 1 - stream.
+             */
+#define     ATOMIC_MEM_ENGINESEL(x)             ((x) << 30)
+            /* 0 - micro_engine.
+			 */
+
 #define	PACKET3_DMA_DATA				0x50
 /* 1. header
  * 2. CONTROL
@@ -1472,8 +1486,33 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
 
 			/* verify if SDMA test result meets with expected */
 			i = 0;
-			while(i < sdma_write_length) {
-				CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
+			if (!secure) {
+				while(i < sdma_write_length) {
+					CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
+				}
+			} else if (ip_type == AMDGPU_HW_IP_GFX) {
+				memset((void*)pm4, 0, pm4_dw * sizeof(uint32_t));
+				pm4[i++] = PACKET3(PACKET3_ATOMIC_MEM, 7);
+				/* atomic opcode for 32b w/ RTN and ATOMIC_SWAPCMP_RTN
+				 * command, 1-loop_until_compare_satisfied.
+				 * single_pass_atomic, 0-lru
+				 * engine_sel, 0-micro_engine
+				 */
+				pm4[i++] = (TC_OP_ATOMIC_CMPSWAP_RTN_32 |
+							ATOMIC_MEM_COMMAND(1) |
+							ATOMIC_MEM_CACHEPOLICAY(0) |
+							ATOMIC_MEM_ENGINESEL(0));
+				pm4[i++] = 0xfffffffc & bo_mc;
+				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
+				pm4[i++] = 0x12345678;
+				pm4[i++] = 0x0;
+				pm4[i++] = 0xdeadbeaf;
+				pm4[i++] = 0x0;
+				pm4[i++] = 0x100;
+				amdgpu_test_exec_cs_helper_raw(device, context_handle,
+							ip_type, ring_id, i, pm4,
+							1, resources, ib_info,
+							ibs_request, true);
 			}
 
 			r = amdgpu_bo_unmap_and_free(bo, va_handle, bo_mc,
-- 
2.7.4

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

[PATCH 09/12] tests/amdgpu: add atomic_mem cp_packet to verify the secure buffer

[Aaron Liu]

Secure buffer is only able to be read with trusted ip block.
So we need use GFX ip to read it back instead of CPU.
Steps:
1. use write_data packet to write 0xdeadbeaf to secure buffer,
2. use atmoic_mem packet and ATOMIC_CMPSWAP_RTN_32 opcode to compare
the cmp_data(0xdeadbeaf) to the written data which has been encrypted.
If the result is equal, then overwrite the src_data(0x12345678) to the
secure buffer and return directly. Otherwise loop again until gfx timeout
and the secure buffer data unchanged.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 tests/amdgpu/basic_tests.c | 43 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 956be93..907237e 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -160,6 +160,20 @@ CU_TestInfo basic_tests[] = {
 		 * 2 - ce
 		 */
 
+#define	PACKET3_ATOMIC_MEM				0x1E
+#define     TC_OP_ATOMIC_CMPSWAP_RTN_32          0x00000008
+#define     ATOMIC_MEM_COMMAND(x)               ((x) << 8)
+            /* 0 - single_pass_atomic.
+             * 1 - loop_until_compare_satisfied.
+             */
+#define     ATOMIC_MEM_CACHEPOLICAY(x)          ((x) << 25)
+            /* 0 - lru.
+             * 1 - stream.
+             */
+#define     ATOMIC_MEM_ENGINESEL(x)             ((x) << 30)
+            /* 0 - micro_engine.
+			 */
+
 #define	PACKET3_DMA_DATA				0x50
 /* 1. header
  * 2. CONTROL
@@ -1472,8 +1486,33 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
 
 			/* verify if SDMA test result meets with expected */
 			i = 0;
-			while(i < sdma_write_length) {
-				CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
+			if (!secure) {
+				while(i < sdma_write_length) {
+					CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
+				}
+			} else if (ip_type == AMDGPU_HW_IP_GFX) {
+				memset((void*)pm4, 0, pm4_dw * sizeof(uint32_t));
+				pm4[i++] = PACKET3(PACKET3_ATOMIC_MEM, 7);
+				/* atomic opcode for 32b w/ RTN and ATOMIC_SWAPCMP_RTN
+				 * command, 1-loop_until_compare_satisfied.
+				 * single_pass_atomic, 0-lru
+				 * engine_sel, 0-micro_engine
+				 */
+				pm4[i++] = (TC_OP_ATOMIC_CMPSWAP_RTN_32 |
+							ATOMIC_MEM_COMMAND(1) |
+							ATOMIC_MEM_CACHEPOLICAY(0) |
+							ATOMIC_MEM_ENGINESEL(0));
+				pm4[i++] = 0xfffffffc & bo_mc;
+				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
+				pm4[i++] = 0x12345678;
+				pm4[i++] = 0x0;
+				pm4[i++] = 0xdeadbeaf;
+				pm4[i++] = 0x0;
+				pm4[i++] = 0x100;
+				amdgpu_test_exec_cs_helper_raw(device, context_handle,
+							ip_type, ring_id, i, pm4,
+							1, resources, ib_info,
+							ibs_request, true);
 			}
 
 			r = amdgpu_bo_unmap_and_free(bo, va_handle, bo_mc,
-- 
2.7.4

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

Re: [PATCH 09/12] tests/amdgpu: add atomic_mem cp_packet to verify the secure buffer

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:52AM +0800, Liu, Aaron wrote:
> Secure buffer is only able to be read with trusted ip block.
> So we need use GFX ip to read it back instead of CPU.
> Steps:
> 1. use write_data packet to write 0xdeadbeaf to secure buffer,
> 2. use atmoic_mem packet and ATOMIC_CMPSWAP_RTN_32 opcode to compare
> the cmp_data(0xdeadbeaf) to the written data which has been encrypted.
> If the result is equal, then overwrite the src_data(0x12345678) to the
> secure buffer and return directly. Otherwise loop again until gfx timeout
> and the secure buffer data unchanged.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Reviewed-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/basic_tests.c | 43 +++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 956be93..907237e 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -160,6 +160,20 @@ CU_TestInfo basic_tests[] = {
>  		 * 2 - ce
>  		 */
>  
> +#define	PACKET3_ATOMIC_MEM				0x1E
> +#define     TC_OP_ATOMIC_CMPSWAP_RTN_32          0x00000008
> +#define     ATOMIC_MEM_COMMAND(x)               ((x) << 8)
> +            /* 0 - single_pass_atomic.
> +             * 1 - loop_until_compare_satisfied.
> +             */
> +#define     ATOMIC_MEM_CACHEPOLICAY(x)          ((x) << 25)
> +            /* 0 - lru.
> +             * 1 - stream.
> +             */
> +#define     ATOMIC_MEM_ENGINESEL(x)             ((x) << 30)
> +            /* 0 - micro_engine.
> +			 */
> +
>  #define	PACKET3_DMA_DATA				0x50
>  /* 1. header
>   * 2. CONTROL
> @@ -1472,8 +1486,33 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  
>  			/* verify if SDMA test result meets with expected */
>  			i = 0;
> -			while(i < sdma_write_length) {
> -				CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
> +			if (!secure) {
> +				while(i < sdma_write_length) {
> +					CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
> +				}
> +			} else if (ip_type == AMDGPU_HW_IP_GFX) {
> +				memset((void*)pm4, 0, pm4_dw * sizeof(uint32_t));
> +				pm4[i++] = PACKET3(PACKET3_ATOMIC_MEM, 7);
> +				/* atomic opcode for 32b w/ RTN and ATOMIC_SWAPCMP_RTN
> +				 * command, 1-loop_until_compare_satisfied.
> +				 * single_pass_atomic, 0-lru
> +				 * engine_sel, 0-micro_engine
> +				 */
> +				pm4[i++] = (TC_OP_ATOMIC_CMPSWAP_RTN_32 |
> +							ATOMIC_MEM_COMMAND(1) |
> +							ATOMIC_MEM_CACHEPOLICAY(0) |
> +							ATOMIC_MEM_ENGINESEL(0));
> +				pm4[i++] = 0xfffffffc & bo_mc;
> +				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
> +				pm4[i++] = 0x12345678;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0xdeadbeaf;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0x100;
> +				amdgpu_test_exec_cs_helper_raw(device, context_handle,
> +							ip_type, ring_id, i, pm4,
> +							1, resources, ib_info,
> +							ibs_request, true);
>  			}
>  
>  			r = amdgpu_bo_unmap_and_free(bo, va_handle, bo_mc,
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 09/12] tests/amdgpu: add atomic_mem cp_packet to verify the secure buffer

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:52AM +0800, Liu, Aaron wrote:
> Secure buffer is only able to be read with trusted ip block.
> So we need use GFX ip to read it back instead of CPU.
> Steps:
> 1. use write_data packet to write 0xdeadbeaf to secure buffer,
> 2. use atmoic_mem packet and ATOMIC_CMPSWAP_RTN_32 opcode to compare
> the cmp_data(0xdeadbeaf) to the written data which has been encrypted.
> If the result is equal, then overwrite the src_data(0x12345678) to the
> secure buffer and return directly. Otherwise loop again until gfx timeout
> and the secure buffer data unchanged.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Reviewed-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/basic_tests.c | 43 +++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 956be93..907237e 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -160,6 +160,20 @@ CU_TestInfo basic_tests[] = {
>  		 * 2 - ce
>  		 */
>  
> +#define	PACKET3_ATOMIC_MEM				0x1E
> +#define     TC_OP_ATOMIC_CMPSWAP_RTN_32          0x00000008
> +#define     ATOMIC_MEM_COMMAND(x)               ((x) << 8)
> +            /* 0 - single_pass_atomic.
> +             * 1 - loop_until_compare_satisfied.
> +             */
> +#define     ATOMIC_MEM_CACHEPOLICAY(x)          ((x) << 25)
> +            /* 0 - lru.
> +             * 1 - stream.
> +             */
> +#define     ATOMIC_MEM_ENGINESEL(x)             ((x) << 30)
> +            /* 0 - micro_engine.
> +			 */
> +
>  #define	PACKET3_DMA_DATA				0x50
>  /* 1. header
>   * 2. CONTROL
> @@ -1472,8 +1486,33 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  
>  			/* verify if SDMA test result meets with expected */
>  			i = 0;
> -			while(i < sdma_write_length) {
> -				CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
> +			if (!secure) {
> +				while(i < sdma_write_length) {
> +					CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
> +				}
> +			} else if (ip_type == AMDGPU_HW_IP_GFX) {
> +				memset((void*)pm4, 0, pm4_dw * sizeof(uint32_t));
> +				pm4[i++] = PACKET3(PACKET3_ATOMIC_MEM, 7);
> +				/* atomic opcode for 32b w/ RTN and ATOMIC_SWAPCMP_RTN
> +				 * command, 1-loop_until_compare_satisfied.
> +				 * single_pass_atomic, 0-lru
> +				 * engine_sel, 0-micro_engine
> +				 */
> +				pm4[i++] = (TC_OP_ATOMIC_CMPSWAP_RTN_32 |
> +							ATOMIC_MEM_COMMAND(1) |
> +							ATOMIC_MEM_CACHEPOLICAY(0) |
> +							ATOMIC_MEM_ENGINESEL(0));
> +				pm4[i++] = 0xfffffffc & bo_mc;
> +				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
> +				pm4[i++] = 0x12345678;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0xdeadbeaf;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0x100;
> +				amdgpu_test_exec_cs_helper_raw(device, context_handle,
> +							ip_type, ring_id, i, pm4,
> +							1, resources, ib_info,
> +							ibs_request, true);
>  			}
>  
>  			r = amdgpu_bo_unmap_and_free(bo, va_handle, bo_mc,
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 09/12] tests/amdgpu: add atomic_mem cp_packet to verify the secure buffer

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:52AM +0800, Liu, Aaron wrote:
> Secure buffer is only able to be read with trusted ip block.
> So we need use GFX ip to read it back instead of CPU.
> Steps:
> 1. use write_data packet to write 0xdeadbeaf to secure buffer,
> 2. use atmoic_mem packet and ATOMIC_CMPSWAP_RTN_32 opcode to compare
> the cmp_data(0xdeadbeaf) to the written data which has been encrypted.
> If the result is equal, then overwrite the src_data(0x12345678) to the
> secure buffer and return directly. Otherwise loop again until gfx timeout
> and the secure buffer data unchanged.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Reviewed-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/basic_tests.c | 43 +++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 956be93..907237e 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -160,6 +160,20 @@ CU_TestInfo basic_tests[] = {
>  		 * 2 - ce
>  		 */
>  
> +#define	PACKET3_ATOMIC_MEM				0x1E
> +#define     TC_OP_ATOMIC_CMPSWAP_RTN_32          0x00000008
> +#define     ATOMIC_MEM_COMMAND(x)               ((x) << 8)
> +            /* 0 - single_pass_atomic.
> +             * 1 - loop_until_compare_satisfied.
> +             */
> +#define     ATOMIC_MEM_CACHEPOLICAY(x)          ((x) << 25)
> +            /* 0 - lru.
> +             * 1 - stream.
> +             */
> +#define     ATOMIC_MEM_ENGINESEL(x)             ((x) << 30)
> +            /* 0 - micro_engine.
> +			 */
> +
>  #define	PACKET3_DMA_DATA				0x50
>  /* 1. header
>   * 2. CONTROL
> @@ -1472,8 +1486,33 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  
>  			/* verify if SDMA test result meets with expected */
>  			i = 0;
> -			while(i < sdma_write_length) {
> -				CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
> +			if (!secure) {
> +				while(i < sdma_write_length) {
> +					CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
> +				}
> +			} else if (ip_type == AMDGPU_HW_IP_GFX) {
> +				memset((void*)pm4, 0, pm4_dw * sizeof(uint32_t));
> +				pm4[i++] = PACKET3(PACKET3_ATOMIC_MEM, 7);
> +				/* atomic opcode for 32b w/ RTN and ATOMIC_SWAPCMP_RTN
> +				 * command, 1-loop_until_compare_satisfied.
> +				 * single_pass_atomic, 0-lru
> +				 * engine_sel, 0-micro_engine
> +				 */
> +				pm4[i++] = (TC_OP_ATOMIC_CMPSWAP_RTN_32 |
> +							ATOMIC_MEM_COMMAND(1) |
> +							ATOMIC_MEM_CACHEPOLICAY(0) |
> +							ATOMIC_MEM_ENGINESEL(0));
> +				pm4[i++] = 0xfffffffc & bo_mc;
> +				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
> +				pm4[i++] = 0x12345678;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0xdeadbeaf;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0x100;
> +				amdgpu_test_exec_cs_helper_raw(device, context_handle,
> +							ip_type, ring_id, i, pm4,
> +							1, resources, ib_info,
> +							ibs_request, true);
>  			}
>  
>  			r = amdgpu_bo_unmap_and_free(bo, va_handle, bo_mc,
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 09/12] tests/amdgpu: add atomic_mem cp_packet to verify the secure buffer

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:52AM +0800, Liu, Aaron wrote:
> Secure buffer is only able to be read with trusted ip block.
> So we need use GFX ip to read it back instead of CPU.
> Steps:
> 1. use write_data packet to write 0xdeadbeaf to secure buffer,
> 2. use atmoic_mem packet and ATOMIC_CMPSWAP_RTN_32 opcode to compare
> the cmp_data(0xdeadbeaf) to the written data which has been encrypted.
> If the result is equal, then overwrite the src_data(0x12345678) to the
> secure buffer and return directly. Otherwise loop again until gfx timeout
> and the secure buffer data unchanged.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Reviewed-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/basic_tests.c | 43 +++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 956be93..907237e 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -160,6 +160,20 @@ CU_TestInfo basic_tests[] = {
>  		 * 2 - ce
>  		 */
>  
> +#define	PACKET3_ATOMIC_MEM				0x1E
> +#define     TC_OP_ATOMIC_CMPSWAP_RTN_32          0x00000008
> +#define     ATOMIC_MEM_COMMAND(x)               ((x) << 8)
> +            /* 0 - single_pass_atomic.
> +             * 1 - loop_until_compare_satisfied.
> +             */
> +#define     ATOMIC_MEM_CACHEPOLICAY(x)          ((x) << 25)
> +            /* 0 - lru.
> +             * 1 - stream.
> +             */
> +#define     ATOMIC_MEM_ENGINESEL(x)             ((x) << 30)
> +            /* 0 - micro_engine.
> +			 */
> +
>  #define	PACKET3_DMA_DATA				0x50
>  /* 1. header
>   * 2. CONTROL
> @@ -1472,8 +1486,33 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  
>  			/* verify if SDMA test result meets with expected */
>  			i = 0;
> -			while(i < sdma_write_length) {
> -				CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
> +			if (!secure) {
> +				while(i < sdma_write_length) {
> +					CU_ASSERT_EQUAL(bo_cpu[i++], 0xdeadbeaf);
> +				}
> +			} else if (ip_type == AMDGPU_HW_IP_GFX) {
> +				memset((void*)pm4, 0, pm4_dw * sizeof(uint32_t));
> +				pm4[i++] = PACKET3(PACKET3_ATOMIC_MEM, 7);
> +				/* atomic opcode for 32b w/ RTN and ATOMIC_SWAPCMP_RTN
> +				 * command, 1-loop_until_compare_satisfied.
> +				 * single_pass_atomic, 0-lru
> +				 * engine_sel, 0-micro_engine
> +				 */
> +				pm4[i++] = (TC_OP_ATOMIC_CMPSWAP_RTN_32 |
> +							ATOMIC_MEM_COMMAND(1) |
> +							ATOMIC_MEM_CACHEPOLICAY(0) |
> +							ATOMIC_MEM_ENGINESEL(0));
> +				pm4[i++] = 0xfffffffc & bo_mc;
> +				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
> +				pm4[i++] = 0x12345678;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0xdeadbeaf;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0x100;
> +				amdgpu_test_exec_cs_helper_raw(device, context_handle,
> +							ip_type, ring_id, i, pm4,
> +							1, resources, ib_info,
> +							ibs_request, true);
>  			}
>  
>  			r = amdgpu_bo_unmap_and_free(bo, va_handle, bo_mc,
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 10/12] tests/amdgpu: add test to submit a gfx command with secure context

[Aaron Liu]

This patch is to test the command submission with secure context.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 tests/amdgpu/security_tests.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
index a3807ee..0bb4ad2 100644
--- a/tests/amdgpu/security_tests.c
+++ b/tests/amdgpu/security_tests.c
@@ -32,6 +32,7 @@ static uint32_t major_version;
 static uint32_t minor_version;
 
 static void amdgpu_security_alloc_buf_test(void);
+static void amdgpu_security_gfx_submission_test(void);
 
 CU_BOOL suite_security_tests_enable(void)
 {
@@ -75,6 +76,7 @@ int suite_security_tests_clean(void)
 
 CU_TestInfo security_tests[] = {
 	{ "allocate secure buffer test", amdgpu_security_alloc_buf_test },
+	{ "graphics secure command submission", amdgpu_security_gfx_submission_test },
 	CU_TEST_INFO_NULL,
 };
 
@@ -113,3 +115,10 @@ static void amdgpu_security_alloc_buf_test(void)
 	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
 	CU_ASSERT_EQUAL(r, 0);
 }
+
+static void amdgpu_security_gfx_submission_test(void)
+{
+	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
+								  AMDGPU_HW_IP_GFX,
+								  true);
+}
-- 
2.7.4

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

[PATCH 10/12] tests/amdgpu: add test to submit a gfx command with secure context

[Aaron Liu]

This patch is to test the command submission with secure context.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 tests/amdgpu/security_tests.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
index a3807ee..0bb4ad2 100644
--- a/tests/amdgpu/security_tests.c
+++ b/tests/amdgpu/security_tests.c
@@ -32,6 +32,7 @@ static uint32_t major_version;
 static uint32_t minor_version;
 
 static void amdgpu_security_alloc_buf_test(void);
+static void amdgpu_security_gfx_submission_test(void);
 
 CU_BOOL suite_security_tests_enable(void)
 {
@@ -75,6 +76,7 @@ int suite_security_tests_clean(void)
 
 CU_TestInfo security_tests[] = {
 	{ "allocate secure buffer test", amdgpu_security_alloc_buf_test },
+	{ "graphics secure command submission", amdgpu_security_gfx_submission_test },
 	CU_TEST_INFO_NULL,
 };
 
@@ -113,3 +115,10 @@ static void amdgpu_security_alloc_buf_test(void)
 	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
 	CU_ASSERT_EQUAL(r, 0);
 }
+
+static void amdgpu_security_gfx_submission_test(void)
+{
+	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
+								  AMDGPU_HW_IP_GFX,
+								  true);
+}
-- 
2.7.4

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

Re: [PATCH 10/12] tests/amdgpu: add test to submit a gfx command with secure context

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:53AM +0800, Liu, Aaron wrote:
> This patch is to test the command submission with secure context.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Reviewed-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/security_tests.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
> index a3807ee..0bb4ad2 100644
> --- a/tests/amdgpu/security_tests.c
> +++ b/tests/amdgpu/security_tests.c
> @@ -32,6 +32,7 @@ static uint32_t major_version;
>  static uint32_t minor_version;
>  
>  static void amdgpu_security_alloc_buf_test(void);
> +static void amdgpu_security_gfx_submission_test(void);
>  
>  CU_BOOL suite_security_tests_enable(void)
>  {
> @@ -75,6 +76,7 @@ int suite_security_tests_clean(void)
>  
>  CU_TestInfo security_tests[] = {
>  	{ "allocate secure buffer test", amdgpu_security_alloc_buf_test },
> +	{ "graphics secure command submission", amdgpu_security_gfx_submission_test },
>  	CU_TEST_INFO_NULL,
>  };
>  
> @@ -113,3 +115,10 @@ static void amdgpu_security_alloc_buf_test(void)
>  	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
>  	CU_ASSERT_EQUAL(r, 0);
>  }
> +
> +static void amdgpu_security_gfx_submission_test(void)
> +{
> +	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
> +								  AMDGPU_HW_IP_GFX,
> +								  true);
> +}
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 10/12] tests/amdgpu: add test to submit a gfx command with secure context

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:53AM +0800, Liu, Aaron wrote:
> This patch is to test the command submission with secure context.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Reviewed-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/security_tests.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
> index a3807ee..0bb4ad2 100644
> --- a/tests/amdgpu/security_tests.c
> +++ b/tests/amdgpu/security_tests.c
> @@ -32,6 +32,7 @@ static uint32_t major_version;
>  static uint32_t minor_version;
>  
>  static void amdgpu_security_alloc_buf_test(void);
> +static void amdgpu_security_gfx_submission_test(void);
>  
>  CU_BOOL suite_security_tests_enable(void)
>  {
> @@ -75,6 +76,7 @@ int suite_security_tests_clean(void)
>  
>  CU_TestInfo security_tests[] = {
>  	{ "allocate secure buffer test", amdgpu_security_alloc_buf_test },
> +	{ "graphics secure command submission", amdgpu_security_gfx_submission_test },
>  	CU_TEST_INFO_NULL,
>  };
>  
> @@ -113,3 +115,10 @@ static void amdgpu_security_alloc_buf_test(void)
>  	r = gpu_mem_free(bo, va_handle, bo_mc, 4096);
>  	CU_ASSERT_EQUAL(r, 0);
>  }
> +
> +static void amdgpu_security_gfx_submission_test(void)
> +{
> +	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
> +								  AMDGPU_HW_IP_GFX,
> +								  true);
> +}
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 11/12] tests/amdgpu: add atomic dma command to verify the secure buffer

[Aaron Liu]

DMA's atomic behavir is unlike GFX,If the comparing data is not
equal to destination data,
For GFX, loop again till gfx timeout(system hang).
For DMA, loop again till timer expired and then send interrupt.
So testcase can't use interrupt mechanism.
We take another way to verify. When the comparing data is not
equal to destination data, overwrite the source data to the destination
buffer. Otherwise, original destination data unchanged.
So if the bo_cpu data is overwritten, the result is passed.

Steps:
1. use linear write packet to write 0xdeadbeaf to secure buffer,
2. use atmoic packet and ATOMIC_CMPSWAP_RTN_32 opcode to compare
the cmp_data(0xdeadbeaf) to the written data which has been encrypted.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 tests/amdgpu/basic_tests.c | 55 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 907237e..5e687e3 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -109,6 +109,20 @@ CU_TestInfo basic_tests[] = {
 #define	SDMA_OPCODE_COPY				  1
 #       define SDMA_COPY_SUB_OPCODE_LINEAR                0
 
+#define	SDMA_OPCODE_ATOMIC				  10
+#		define SDMA_ATOMIC_LOOP(x)               ((x) << 0)
+        /* 0 - single_pass_atomic.
+         * 1 - loop_until_compare_satisfied.
+         */
+#		define SDMA_ATOMIC_TMZ(x)                ((x) << 2)
+		/* 0 - non-TMZ.
+		 * 1 - TMZ.
+	     */
+#		define SDMA_ATOMIC_OPCODE(x)             ((x) << 9)
+		/* TC_OP_ATOMIC_CMPSWAP_RTN_32 0x00000008
+		 * same as Packet 3
+		 */
+
 #define GFX_COMPUTE_NOP  0xffff1000
 #define SDMA_NOP  0x0
 
@@ -1408,6 +1422,7 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
 	struct amdgpu_cs_request *ibs_request;
 	uint64_t bo_mc;
 	volatile uint32_t *bo_cpu;
+	uint32_t bo_cpu_origin;
 	int i, j, r, loop, ring_id;
 	uint64_t gtt_flags[2] = {0, AMDGPU_GEM_CREATE_CPU_GTT_USWC};
 	amdgpu_va_handle va_handle;
@@ -1460,8 +1475,9 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
 								  sdma_write_length);
 				else
 					pm4[i++] = SDMA_PACKET(SDMA_OPCODE_WRITE,
-							       SDMA_WRITE_SUB_OPCODE_LINEAR, 0);
-				pm4[i++] = 0xffffffff & bo_mc;
+							       SDMA_WRITE_SUB_OPCODE_LINEAR,
+							       secure ? SDMA_ATOMIC_TMZ(1) : 0);
+				pm4[i++] = 0xfffffffc & bo_mc;
 				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
 				if (family_id >= AMDGPU_FAMILY_AI)
 					pm4[i++] = sdma_write_length - 1;
@@ -1513,6 +1529,41 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
 							ip_type, ring_id, i, pm4,
 							1, resources, ib_info,
 							ibs_request, true);
+			} else if (ip_type == AMDGPU_HW_IP_DMA) {
+				/* restore the bo_cpu to compare */
+				bo_cpu_origin = bo_cpu[0];
+				memset((void*)pm4, 0, pm4_dw * sizeof(uint32_t));
+				/* atomic opcode for 32b w/ RTN and ATOMIC_SWAPCMP_RTN
+				 * loop, 1-loop_until_compare_satisfied.
+				 * single_pass_atomic, 0-lru
+				 */
+				pm4[i++] = SDMA_PACKET(SDMA_OPCODE_ATOMIC,
+							       0,
+							       SDMA_ATOMIC_LOOP(1) |
+							       SDMA_ATOMIC_TMZ(1) |
+							       SDMA_ATOMIC_OPCODE(TC_OP_ATOMIC_CMPSWAP_RTN_32));
+				pm4[i++] = 0xfffffffc & bo_mc;
+				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
+				pm4[i++] = 0x12345678;
+				pm4[i++] = 0x0;
+				pm4[i++] = 0xdeadbeaf;
+				pm4[i++] = 0x0;
+				pm4[i++] = 0x100;
+				amdgpu_test_exec_cs_helper_raw(device, context_handle,
+							ip_type, ring_id, i, pm4,
+							1, resources, ib_info,
+							ibs_request, true);
+				/* DMA's atomic behavir is unlike GFX
+				 * If the comparing data is not equal to destination data,
+				 * For GFX, loop again till gfx timeout(system hang).
+				 * For DMA, loop again till timer expired and then send interrupt.
+				 * So testcase can't use interrupt mechanism.
+				 * We take another way to verify. When the comparing data is not
+				 * equal to destination data, overwrite the source data to the destination
+				 * buffer. Otherwise, original destination data unchanged.
+				 * So if the bo_cpu data is overwritten, the result is passed.
+				 */
+				CU_ASSERT_NOT_EQUAL(bo_cpu[0], bo_cpu_origin);
 			}
 
 			r = amdgpu_bo_unmap_and_free(bo, va_handle, bo_mc,
-- 
2.7.4

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

[PATCH 11/12] tests/amdgpu: add atomic dma command to verify the secure buffer

[Aaron Liu]

DMA's atomic behavir is unlike GFX,If the comparing data is not
equal to destination data,
For GFX, loop again till gfx timeout(system hang).
For DMA, loop again till timer expired and then send interrupt.
So testcase can't use interrupt mechanism.
We take another way to verify. When the comparing data is not
equal to destination data, overwrite the source data to the destination
buffer. Otherwise, original destination data unchanged.
So if the bo_cpu data is overwritten, the result is passed.

Steps:
1. use linear write packet to write 0xdeadbeaf to secure buffer,
2. use atmoic packet and ATOMIC_CMPSWAP_RTN_32 opcode to compare
the cmp_data(0xdeadbeaf) to the written data which has been encrypted.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 tests/amdgpu/basic_tests.c | 55 ++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 907237e..5e687e3 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -109,6 +109,20 @@ CU_TestInfo basic_tests[] = {
 #define	SDMA_OPCODE_COPY				  1
 #       define SDMA_COPY_SUB_OPCODE_LINEAR                0
 
+#define	SDMA_OPCODE_ATOMIC				  10
+#		define SDMA_ATOMIC_LOOP(x)               ((x) << 0)
+        /* 0 - single_pass_atomic.
+         * 1 - loop_until_compare_satisfied.
+         */
+#		define SDMA_ATOMIC_TMZ(x)                ((x) << 2)
+		/* 0 - non-TMZ.
+		 * 1 - TMZ.
+	     */
+#		define SDMA_ATOMIC_OPCODE(x)             ((x) << 9)
+		/* TC_OP_ATOMIC_CMPSWAP_RTN_32 0x00000008
+		 * same as Packet 3
+		 */
+
 #define GFX_COMPUTE_NOP  0xffff1000
 #define SDMA_NOP  0x0
 
@@ -1408,6 +1422,7 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
 	struct amdgpu_cs_request *ibs_request;
 	uint64_t bo_mc;
 	volatile uint32_t *bo_cpu;
+	uint32_t bo_cpu_origin;
 	int i, j, r, loop, ring_id;
 	uint64_t gtt_flags[2] = {0, AMDGPU_GEM_CREATE_CPU_GTT_USWC};
 	amdgpu_va_handle va_handle;
@@ -1460,8 +1475,9 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
 								  sdma_write_length);
 				else
 					pm4[i++] = SDMA_PACKET(SDMA_OPCODE_WRITE,
-							       SDMA_WRITE_SUB_OPCODE_LINEAR, 0);
-				pm4[i++] = 0xffffffff & bo_mc;
+							       SDMA_WRITE_SUB_OPCODE_LINEAR,
+							       secure ? SDMA_ATOMIC_TMZ(1) : 0);
+				pm4[i++] = 0xfffffffc & bo_mc;
 				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
 				if (family_id >= AMDGPU_FAMILY_AI)
 					pm4[i++] = sdma_write_length - 1;
@@ -1513,6 +1529,41 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
 							ip_type, ring_id, i, pm4,
 							1, resources, ib_info,
 							ibs_request, true);
+			} else if (ip_type == AMDGPU_HW_IP_DMA) {
+				/* restore the bo_cpu to compare */
+				bo_cpu_origin = bo_cpu[0];
+				memset((void*)pm4, 0, pm4_dw * sizeof(uint32_t));
+				/* atomic opcode for 32b w/ RTN and ATOMIC_SWAPCMP_RTN
+				 * loop, 1-loop_until_compare_satisfied.
+				 * single_pass_atomic, 0-lru
+				 */
+				pm4[i++] = SDMA_PACKET(SDMA_OPCODE_ATOMIC,
+							       0,
+							       SDMA_ATOMIC_LOOP(1) |
+							       SDMA_ATOMIC_TMZ(1) |
+							       SDMA_ATOMIC_OPCODE(TC_OP_ATOMIC_CMPSWAP_RTN_32));
+				pm4[i++] = 0xfffffffc & bo_mc;
+				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
+				pm4[i++] = 0x12345678;
+				pm4[i++] = 0x0;
+				pm4[i++] = 0xdeadbeaf;
+				pm4[i++] = 0x0;
+				pm4[i++] = 0x100;
+				amdgpu_test_exec_cs_helper_raw(device, context_handle,
+							ip_type, ring_id, i, pm4,
+							1, resources, ib_info,
+							ibs_request, true);
+				/* DMA's atomic behavir is unlike GFX
+				 * If the comparing data is not equal to destination data,
+				 * For GFX, loop again till gfx timeout(system hang).
+				 * For DMA, loop again till timer expired and then send interrupt.
+				 * So testcase can't use interrupt mechanism.
+				 * We take another way to verify. When the comparing data is not
+				 * equal to destination data, overwrite the source data to the destination
+				 * buffer. Otherwise, original destination data unchanged.
+				 * So if the bo_cpu data is overwritten, the result is passed.
+				 */
+				CU_ASSERT_NOT_EQUAL(bo_cpu[0], bo_cpu_origin);
 			}
 
 			r = amdgpu_bo_unmap_and_free(bo, va_handle, bo_mc,
-- 
2.7.4

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

Re: [PATCH 11/12] tests/amdgpu: add atomic dma command to verify the secure buffer

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:54AM +0800, Liu, Aaron wrote:
> DMA's atomic behavir is unlike GFX,If the comparing data is not
> equal to destination data,
> For GFX, loop again till gfx timeout(system hang).
> For DMA, loop again till timer expired and then send interrupt.
> So testcase can't use interrupt mechanism.
> We take another way to verify. When the comparing data is not
> equal to destination data, overwrite the source data to the destination
> buffer. Otherwise, original destination data unchanged.
> So if the bo_cpu data is overwritten, the result is passed.
> 
> Steps:
> 1. use linear write packet to write 0xdeadbeaf to secure buffer,
> 2. use atmoic packet and ATOMIC_CMPSWAP_RTN_32 opcode to compare
> the cmp_data(0xdeadbeaf) to the written data which has been encrypted.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
> ---
>  tests/amdgpu/basic_tests.c | 55 ++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 907237e..5e687e3 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -109,6 +109,20 @@ CU_TestInfo basic_tests[] = {
>  #define	SDMA_OPCODE_COPY				  1
>  #       define SDMA_COPY_SUB_OPCODE_LINEAR                0
>  
> +#define	SDMA_OPCODE_ATOMIC				  10
> +#		define SDMA_ATOMIC_LOOP(x)               ((x) << 0)
> +        /* 0 - single_pass_atomic.
> +         * 1 - loop_until_compare_satisfied.
> +         */
> +#		define SDMA_ATOMIC_TMZ(x)                ((x) << 2)
> +		/* 0 - non-TMZ.
> +		 * 1 - TMZ.
> +	     */
> +#		define SDMA_ATOMIC_OPCODE(x)             ((x) << 9)
> +		/* TC_OP_ATOMIC_CMPSWAP_RTN_32 0x00000008
> +		 * same as Packet 3
> +		 */
> +
>  #define GFX_COMPUTE_NOP  0xffff1000
>  #define SDMA_NOP  0x0
>  
> @@ -1408,6 +1422,7 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  	struct amdgpu_cs_request *ibs_request;
>  	uint64_t bo_mc;
>  	volatile uint32_t *bo_cpu;
> +	uint32_t bo_cpu_origin;
>  	int i, j, r, loop, ring_id;
>  	uint64_t gtt_flags[2] = {0, AMDGPU_GEM_CREATE_CPU_GTT_USWC};
>  	amdgpu_va_handle va_handle;
> @@ -1460,8 +1475,9 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  								  sdma_write_length);
>  				else
>  					pm4[i++] = SDMA_PACKET(SDMA_OPCODE_WRITE,
> -							       SDMA_WRITE_SUB_OPCODE_LINEAR, 0);
> -				pm4[i++] = 0xffffffff & bo_mc;
> +							       SDMA_WRITE_SUB_OPCODE_LINEAR,
> +							       secure ? SDMA_ATOMIC_TMZ(1) : 0);
> +				pm4[i++] = 0xfffffffc & bo_mc;
>  				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
>  				if (family_id >= AMDGPU_FAMILY_AI)
>  					pm4[i++] = sdma_write_length - 1;
> @@ -1513,6 +1529,41 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  							ip_type, ring_id, i, pm4,
>  							1, resources, ib_info,
>  							ibs_request, true);
> +			} else if (ip_type == AMDGPU_HW_IP_DMA) {
> +				/* restore the bo_cpu to compare */
> +				bo_cpu_origin = bo_cpu[0];
> +				memset((void*)pm4, 0, pm4_dw * sizeof(uint32_t));
> +				/* atomic opcode for 32b w/ RTN and ATOMIC_SWAPCMP_RTN
> +				 * loop, 1-loop_until_compare_satisfied.
> +				 * single_pass_atomic, 0-lru
> +				 */
> +				pm4[i++] = SDMA_PACKET(SDMA_OPCODE_ATOMIC,
> +							       0,
> +							       SDMA_ATOMIC_LOOP(1) |
> +							       SDMA_ATOMIC_TMZ(1) |
> +							       SDMA_ATOMIC_OPCODE(TC_OP_ATOMIC_CMPSWAP_RTN_32));
> +				pm4[i++] = 0xfffffffc & bo_mc;
> +				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
> +				pm4[i++] = 0x12345678;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0xdeadbeaf;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0x100;
> +				amdgpu_test_exec_cs_helper_raw(device, context_handle,
> +							ip_type, ring_id, i, pm4,
> +							1, resources, ib_info,
> +							ibs_request, true);
> +				/* DMA's atomic behavir is unlike GFX
> +				 * If the comparing data is not equal to destination data,
> +				 * For GFX, loop again till gfx timeout(system hang).
> +				 * For DMA, loop again till timer expired and then send interrupt.
> +				 * So testcase can't use interrupt mechanism.
> +				 * We take another way to verify. When the comparing data is not
> +				 * equal to destination data, overwrite the source data to the destination
> +				 * buffer. Otherwise, original destination data unchanged.
> +				 * So if the bo_cpu data is overwritten, the result is passed.
> +				 */
> +				CU_ASSERT_NOT_EQUAL(bo_cpu[0], bo_cpu_origin);

I think we can add one more test for the case that overwrite the source
data to the destination buffer.

Thanks,
Ray

>  			}
>  
>  			r = amdgpu_bo_unmap_and_free(bo, va_handle, bo_mc,
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 11/12] tests/amdgpu: add atomic dma command to verify the secure buffer

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:54AM +0800, Liu, Aaron wrote:
> DMA's atomic behavir is unlike GFX,If the comparing data is not
> equal to destination data,
> For GFX, loop again till gfx timeout(system hang).
> For DMA, loop again till timer expired and then send interrupt.
> So testcase can't use interrupt mechanism.
> We take another way to verify. When the comparing data is not
> equal to destination data, overwrite the source data to the destination
> buffer. Otherwise, original destination data unchanged.
> So if the bo_cpu data is overwritten, the result is passed.
> 
> Steps:
> 1. use linear write packet to write 0xdeadbeaf to secure buffer,
> 2. use atmoic packet and ATOMIC_CMPSWAP_RTN_32 opcode to compare
> the cmp_data(0xdeadbeaf) to the written data which has been encrypted.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
> ---
>  tests/amdgpu/basic_tests.c | 55 ++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 907237e..5e687e3 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -109,6 +109,20 @@ CU_TestInfo basic_tests[] = {
>  #define	SDMA_OPCODE_COPY				  1
>  #       define SDMA_COPY_SUB_OPCODE_LINEAR                0
>  
> +#define	SDMA_OPCODE_ATOMIC				  10
> +#		define SDMA_ATOMIC_LOOP(x)               ((x) << 0)
> +        /* 0 - single_pass_atomic.
> +         * 1 - loop_until_compare_satisfied.
> +         */
> +#		define SDMA_ATOMIC_TMZ(x)                ((x) << 2)
> +		/* 0 - non-TMZ.
> +		 * 1 - TMZ.
> +	     */
> +#		define SDMA_ATOMIC_OPCODE(x)             ((x) << 9)
> +		/* TC_OP_ATOMIC_CMPSWAP_RTN_32 0x00000008
> +		 * same as Packet 3
> +		 */
> +
>  #define GFX_COMPUTE_NOP  0xffff1000
>  #define SDMA_NOP  0x0
>  
> @@ -1408,6 +1422,7 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  	struct amdgpu_cs_request *ibs_request;
>  	uint64_t bo_mc;
>  	volatile uint32_t *bo_cpu;
> +	uint32_t bo_cpu_origin;
>  	int i, j, r, loop, ring_id;
>  	uint64_t gtt_flags[2] = {0, AMDGPU_GEM_CREATE_CPU_GTT_USWC};
>  	amdgpu_va_handle va_handle;
> @@ -1460,8 +1475,9 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  								  sdma_write_length);
>  				else
>  					pm4[i++] = SDMA_PACKET(SDMA_OPCODE_WRITE,
> -							       SDMA_WRITE_SUB_OPCODE_LINEAR, 0);
> -				pm4[i++] = 0xffffffff & bo_mc;
> +							       SDMA_WRITE_SUB_OPCODE_LINEAR,
> +							       secure ? SDMA_ATOMIC_TMZ(1) : 0);
> +				pm4[i++] = 0xfffffffc & bo_mc;
>  				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
>  				if (family_id >= AMDGPU_FAMILY_AI)
>  					pm4[i++] = sdma_write_length - 1;
> @@ -1513,6 +1529,41 @@ amdgpu_command_submission_write_linear_helper_with_secure(amdgpu_device_handle
>  							ip_type, ring_id, i, pm4,
>  							1, resources, ib_info,
>  							ibs_request, true);
> +			} else if (ip_type == AMDGPU_HW_IP_DMA) {
> +				/* restore the bo_cpu to compare */
> +				bo_cpu_origin = bo_cpu[0];
> +				memset((void*)pm4, 0, pm4_dw * sizeof(uint32_t));
> +				/* atomic opcode for 32b w/ RTN and ATOMIC_SWAPCMP_RTN
> +				 * loop, 1-loop_until_compare_satisfied.
> +				 * single_pass_atomic, 0-lru
> +				 */
> +				pm4[i++] = SDMA_PACKET(SDMA_OPCODE_ATOMIC,
> +							       0,
> +							       SDMA_ATOMIC_LOOP(1) |
> +							       SDMA_ATOMIC_TMZ(1) |
> +							       SDMA_ATOMIC_OPCODE(TC_OP_ATOMIC_CMPSWAP_RTN_32));
> +				pm4[i++] = 0xfffffffc & bo_mc;
> +				pm4[i++] = (0xffffffff00000000 & bo_mc) >> 32;
> +				pm4[i++] = 0x12345678;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0xdeadbeaf;
> +				pm4[i++] = 0x0;
> +				pm4[i++] = 0x100;
> +				amdgpu_test_exec_cs_helper_raw(device, context_handle,
> +							ip_type, ring_id, i, pm4,
> +							1, resources, ib_info,
> +							ibs_request, true);
> +				/* DMA's atomic behavir is unlike GFX
> +				 * If the comparing data is not equal to destination data,
> +				 * For GFX, loop again till gfx timeout(system hang).
> +				 * For DMA, loop again till timer expired and then send interrupt.
> +				 * So testcase can't use interrupt mechanism.
> +				 * We take another way to verify. When the comparing data is not
> +				 * equal to destination data, overwrite the source data to the destination
> +				 * buffer. Otherwise, original destination data unchanged.
> +				 * So if the bo_cpu data is overwritten, the result is passed.
> +				 */
> +				CU_ASSERT_NOT_EQUAL(bo_cpu[0], bo_cpu_origin);

I think we can add one more test for the case that overwrite the source
data to the destination buffer.

Thanks,
Ray

>  			}
>  
>  			r = amdgpu_bo_unmap_and_free(bo, va_handle, bo_mc,
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 12/12] tests/amdgpu: add test to submit a sdma command with secure context

[Aaron Liu]

This patch add test to submit a sdma command with secure context.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 tests/amdgpu/security_tests.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
index 0bb4ad2..eb239f4 100644
--- a/tests/amdgpu/security_tests.c
+++ b/tests/amdgpu/security_tests.c
@@ -33,6 +33,8 @@ static uint32_t minor_version;
 
 static void amdgpu_security_alloc_buf_test(void);
 static void amdgpu_security_gfx_submission_test(void);
+static void amdgpu_security_sdma_submission_test(void);
+
 
 CU_BOOL suite_security_tests_enable(void)
 {
@@ -77,6 +79,7 @@ int suite_security_tests_clean(void)
 CU_TestInfo security_tests[] = {
 	{ "allocate secure buffer test", amdgpu_security_alloc_buf_test },
 	{ "graphics secure command submission", amdgpu_security_gfx_submission_test },
+	{ "sdma secure command submission", amdgpu_security_sdma_submission_test },
 	CU_TEST_INFO_NULL,
 };
 
@@ -122,3 +125,10 @@ static void amdgpu_security_gfx_submission_test(void)
 								  AMDGPU_HW_IP_GFX,
 								  true);
 }
+
+static void amdgpu_security_sdma_submission_test(void)
+{
+	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
+								  AMDGPU_HW_IP_DMA,
+								  true);
+}
-- 
2.7.4

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

[PATCH 12/12] tests/amdgpu: add test to submit a sdma command with secure context

[Aaron Liu]

This patch add test to submit a sdma command with secure context.

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
---
 tests/amdgpu/security_tests.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
index 0bb4ad2..eb239f4 100644
--- a/tests/amdgpu/security_tests.c
+++ b/tests/amdgpu/security_tests.c
@@ -33,6 +33,8 @@ static uint32_t minor_version;
 
 static void amdgpu_security_alloc_buf_test(void);
 static void amdgpu_security_gfx_submission_test(void);
+static void amdgpu_security_sdma_submission_test(void);
+
 
 CU_BOOL suite_security_tests_enable(void)
 {
@@ -77,6 +79,7 @@ int suite_security_tests_clean(void)
 CU_TestInfo security_tests[] = {
 	{ "allocate secure buffer test", amdgpu_security_alloc_buf_test },
 	{ "graphics secure command submission", amdgpu_security_gfx_submission_test },
+	{ "sdma secure command submission", amdgpu_security_sdma_submission_test },
 	CU_TEST_INFO_NULL,
 };
 
@@ -122,3 +125,10 @@ static void amdgpu_security_gfx_submission_test(void)
 								  AMDGPU_HW_IP_GFX,
 								  true);
 }
+
+static void amdgpu_security_sdma_submission_test(void)
+{
+	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
+								  AMDGPU_HW_IP_DMA,
+								  true);
+}
-- 
2.7.4

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

Re: [PATCH 12/12] tests/amdgpu: add test to submit a sdma command with secure context

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:55AM +0800, Liu, Aaron wrote:
> This patch add test to submit a sdma command with secure context.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Reviewed-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/security_tests.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
> index 0bb4ad2..eb239f4 100644
> --- a/tests/amdgpu/security_tests.c
> +++ b/tests/amdgpu/security_tests.c
> @@ -33,6 +33,8 @@ static uint32_t minor_version;
>  
>  static void amdgpu_security_alloc_buf_test(void);
>  static void amdgpu_security_gfx_submission_test(void);
> +static void amdgpu_security_sdma_submission_test(void);
> +
>  
>  CU_BOOL suite_security_tests_enable(void)
>  {
> @@ -77,6 +79,7 @@ int suite_security_tests_clean(void)
>  CU_TestInfo security_tests[] = {
>  	{ "allocate secure buffer test", amdgpu_security_alloc_buf_test },
>  	{ "graphics secure command submission", amdgpu_security_gfx_submission_test },
> +	{ "sdma secure command submission", amdgpu_security_sdma_submission_test },
>  	CU_TEST_INFO_NULL,
>  };
>  
> @@ -122,3 +125,10 @@ static void amdgpu_security_gfx_submission_test(void)
>  								  AMDGPU_HW_IP_GFX,
>  								  true);
>  }
> +
> +static void amdgpu_security_sdma_submission_test(void)
> +{
> +	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
> +								  AMDGPU_HW_IP_DMA,
> +								  true);
> +}
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 12/12] tests/amdgpu: add test to submit a sdma command with secure context

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:55AM +0800, Liu, Aaron wrote:
> This patch add test to submit a sdma command with secure context.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>

Reviewed-by: Huang Rui <ray.huang@amd.com>

> ---
>  tests/amdgpu/security_tests.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/tests/amdgpu/security_tests.c b/tests/amdgpu/security_tests.c
> index 0bb4ad2..eb239f4 100644
> --- a/tests/amdgpu/security_tests.c
> +++ b/tests/amdgpu/security_tests.c
> @@ -33,6 +33,8 @@ static uint32_t minor_version;
>  
>  static void amdgpu_security_alloc_buf_test(void);
>  static void amdgpu_security_gfx_submission_test(void);
> +static void amdgpu_security_sdma_submission_test(void);
> +
>  
>  CU_BOOL suite_security_tests_enable(void)
>  {
> @@ -77,6 +79,7 @@ int suite_security_tests_clean(void)
>  CU_TestInfo security_tests[] = {
>  	{ "allocate secure buffer test", amdgpu_security_alloc_buf_test },
>  	{ "graphics secure command submission", amdgpu_security_gfx_submission_test },
> +	{ "sdma secure command submission", amdgpu_security_sdma_submission_test },
>  	CU_TEST_INFO_NULL,
>  };
>  
> @@ -122,3 +125,10 @@ static void amdgpu_security_gfx_submission_test(void)
>  								  AMDGPU_HW_IP_GFX,
>  								  true);
>  }
> +
> +static void amdgpu_security_sdma_submission_test(void)
> +{
> +	amdgpu_command_submission_write_linear_helper_with_secure(device_handle,
> +								  AMDGPU_HW_IP_DMA,
> +								  true);
> +}
> -- 
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Christian König]

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang@amd.com>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

Please read up on how amdpu_drm.h is updated. The change must first land 
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE	(1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED		(1 << 10)
>   
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Christian König]

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang@amd.com>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

Please read up on how amdpu_drm.h is updated. The change must first land 
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE	(1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED		(1 << 10)
>   
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Deucher, Alexander]

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

We can't land the kernel side until we have real userspace (e.g., Mesa) that uses the TMZ interfaces.  The unit tests are not enough.

Alex


________________________________
From: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Friday, November 15, 2019 7:56 AM
To: Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org>; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org <amd-gfx@lists.freedesktop.org>
Cc: Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org>; Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>; Deucher, Alexander <Alexander.Deucher@amd.com>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
> Reviewed-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>

Please read up on how amdpu_drm.h is updated. The change must first land
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE      (1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */


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

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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Deucher, Alexander]

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

We can't land the kernel side until we have real userspace (e.g., Mesa) that uses the TMZ interfaces.  The unit tests are not enough.

Alex


________________________________
From: Christian König <ckoenig.leichtzumerken@gmail.com>
Sent: Friday, November 15, 2019 7:56 AM
To: Liu, Aaron <Aaron.Liu@amd.com>; amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>
Cc: Olsak, Marek <Marek.Olsak@amd.com>; Huang, Ray <Ray.Huang@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>; Deucher, Alexander <Alexander.Deucher@amd.com>; Liu, Leo <Leo.Liu@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang@amd.com>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

Please read up on how amdpu_drm.h is updated. The change must first land
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE      (1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */


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

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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Koenig, Christian]

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

I know, that's the usual chicken and egg problem with updating libdrm.

But we should update the file with the kernel version and not pick all changes line by line.

Christian.

Am 15.11.2019 15:49 schrieb "Deucher, Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>:
We can't land the kernel side until we have real userspace (e.g., Mesa) that uses the TMZ interfaces.  The unit tests are not enough.

Alex


________________________________
From: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Friday, November 15, 2019 7:56 AM
To: Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org>; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org <amd-gfx@lists.freedesktop.org>
Cc: Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org>; Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>; Deucher, Alexander <Alexander.Deucher@amd.com>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
> Reviewed-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>

Please read up on how amdpu_drm.h is updated. The change must first land
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE      (1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */


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

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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Koenig, Christian]

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

I know, that's the usual chicken and egg problem with updating libdrm.

But we should update the file with the kernel version and not pick all changes line by line.

Christian.

Am 15.11.2019 15:49 schrieb "Deucher, Alexander" <Alexander.Deucher@amd.com>:
We can't land the kernel side until we have real userspace (e.g., Mesa) that uses the TMZ interfaces.  The unit tests are not enough.

Alex


________________________________
From: Christian König <ckoenig.leichtzumerken@gmail.com>
Sent: Friday, November 15, 2019 7:56 AM
To: Liu, Aaron <Aaron.Liu@amd.com>; amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>
Cc: Olsak, Marek <Marek.Olsak@amd.com>; Huang, Ray <Ray.Huang@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>; Deucher, Alexander <Alexander.Deucher@amd.com>; Liu, Leo <Leo.Liu@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang@amd.com>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

Please read up on how amdpu_drm.h is updated. The change must first land
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE      (1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */


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

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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Olsak, Marek]

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

In the kernel tree, you need to do "make headers_install". Then copy amdgpu_drm.h from ./usr/ to the libdrm tree and discard parts that we can't upstream (freesync).

Marek
________________________________
From: Koenig, Christian <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
Sent: November 15, 2019 10:08
To: Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>
Cc: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org>; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>; Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org>; Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

I know, that's the usual chicken and egg problem with updating libdrm.

But we should update the file with the kernel version and not pick all changes line by line.

Christian.

Am 15.11.2019 15:49 schrieb "Deucher, Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>:
We can't land the kernel side until we have real userspace (e.g., Mesa) that uses the TMZ interfaces.  The unit tests are not enough.

Alex


________________________________
From: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Friday, November 15, 2019 7:56 AM
To: Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org>; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org <amd-gfx@lists.freedesktop.org>
Cc: Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org>; Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>; Deucher, Alexander <Alexander.Deucher@amd.com>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
> Reviewed-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>

Please read up on how amdpu_drm.h is updated. The change must first land
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE      (1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */


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

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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Olsak, Marek]

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

In the kernel tree, you need to do "make headers_install". Then copy amdgpu_drm.h from ./usr/ to the libdrm tree and discard parts that we can't upstream (freesync).

Marek
________________________________
From: Koenig, Christian <Christian.Koenig@amd.com>
Sent: November 15, 2019 10:08
To: Deucher, Alexander <Alexander.Deucher@amd.com>
Cc: Christian König <ckoenig.leichtzumerken@gmail.com>; Liu, Aaron <Aaron.Liu@amd.com>; amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>; Olsak, Marek <Marek.Olsak@amd.com>; Huang, Ray <Ray.Huang@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>; Liu, Leo <Leo.Liu@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

I know, that's the usual chicken and egg problem with updating libdrm.

But we should update the file with the kernel version and not pick all changes line by line.

Christian.

Am 15.11.2019 15:49 schrieb "Deucher, Alexander" <Alexander.Deucher@amd.com>:
We can't land the kernel side until we have real userspace (e.g., Mesa) that uses the TMZ interfaces.  The unit tests are not enough.

Alex


________________________________
From: Christian König <ckoenig.leichtzumerken@gmail.com>
Sent: Friday, November 15, 2019 7:56 AM
To: Liu, Aaron <Aaron.Liu@amd.com>; amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>
Cc: Olsak, Marek <Marek.Olsak@amd.com>; Huang, Ray <Ray.Huang@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>; Deucher, Alexander <Alexander.Deucher@amd.com>; Liu, Leo <Leo.Liu@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang@amd.com>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

Please read up on how amdpu_drm.h is updated. The change must first land
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE      (1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */


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

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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Olsak, Marek]

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

The way this is upstreamed is that you submit the kernel and userspace patches for review at the same time. When they see the userspace patches, the kernel patches will be accepted. When the kernel patches land in the Dave's or Linus's tree, the userspace patches can be pushed.

Marek
________________________________
From: Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>
Sent: November 15, 2019 14:34
To: Koenig, Christian <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>; Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>
Cc: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org>; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org>; Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

In the kernel tree, you need to do "make headers_install". Then copy amdgpu_drm.h from ./usr/ to the libdrm tree and discard parts that we can't upstream (freesync).

Marek
________________________________
From: Koenig, Christian <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
Sent: November 15, 2019 10:08
To: Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>
Cc: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org>; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>; Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org>; Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

I know, that's the usual chicken and egg problem with updating libdrm.

But we should update the file with the kernel version and not pick all changes line by line.

Christian.

Am 15.11.2019 15:49 schrieb "Deucher, Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>:
We can't land the kernel side until we have real userspace (e.g., Mesa) that uses the TMZ interfaces.  The unit tests are not enough.

Alex


________________________________
From: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Friday, November 15, 2019 7:56 AM
To: Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org>; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org <amd-gfx@lists.freedesktop.org>
Cc: Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org>; Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>; Deucher, Alexander <Alexander.Deucher@amd.com>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
> Reviewed-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>

Please read up on how amdpu_drm.h is updated. The change must first land
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE      (1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */


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

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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Olsak, Marek]

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

The way this is upstreamed is that you submit the kernel and userspace patches for review at the same time. When they see the userspace patches, the kernel patches will be accepted. When the kernel patches land in the Dave's or Linus's tree, the userspace patches can be pushed.

Marek
________________________________
From: Olsak, Marek <Marek.Olsak@amd.com>
Sent: November 15, 2019 14:34
To: Koenig, Christian <Christian.Koenig@amd.com>; Deucher, Alexander <Alexander.Deucher@amd.com>
Cc: Christian König <ckoenig.leichtzumerken@gmail.com>; Liu, Aaron <Aaron.Liu@amd.com>; amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>; Huang, Ray <Ray.Huang@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>; Liu, Leo <Leo.Liu@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

In the kernel tree, you need to do "make headers_install". Then copy amdgpu_drm.h from ./usr/ to the libdrm tree and discard parts that we can't upstream (freesync).

Marek
________________________________
From: Koenig, Christian <Christian.Koenig@amd.com>
Sent: November 15, 2019 10:08
To: Deucher, Alexander <Alexander.Deucher@amd.com>
Cc: Christian König <ckoenig.leichtzumerken@gmail.com>; Liu, Aaron <Aaron.Liu@amd.com>; amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>; Olsak, Marek <Marek.Olsak@amd.com>; Huang, Ray <Ray.Huang@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>; Liu, Leo <Leo.Liu@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

I know, that's the usual chicken and egg problem with updating libdrm.

But we should update the file with the kernel version and not pick all changes line by line.

Christian.

Am 15.11.2019 15:49 schrieb "Deucher, Alexander" <Alexander.Deucher@amd.com>:
We can't land the kernel side until we have real userspace (e.g., Mesa) that uses the TMZ interfaces.  The unit tests are not enough.

Alex


________________________________
From: Christian König <ckoenig.leichtzumerken@gmail.com>
Sent: Friday, November 15, 2019 7:56 AM
To: Liu, Aaron <Aaron.Liu@amd.com>; amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>
Cc: Olsak, Marek <Marek.Olsak@amd.com>; Huang, Ray <Ray.Huang@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>; Deucher, Alexander <Alexander.Deucher@amd.com>; Liu, Leo <Leo.Liu@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang@amd.com>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

Please read up on how amdpu_drm.h is updated. The change must first land
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE      (1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */


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

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

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

RE: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Liu, Aaron]

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

Thanks for reviews.

As Christian's suggestion, I added drm_version checking, for the older driver, security test suites are disabled.
I create a remote branch for libdrm: remotes/origin/aaliu/for-tmz-support

BR,
Aaron Liu

From: Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org>
Sent: Saturday, November 16, 2019 3:53 AM
To: Koenig, Christian <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>; Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>
Cc: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org>; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org>; Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

The way this is upstreamed is that you submit the kernel and userspace patches for review at the same time. When they see the userspace patches, the kernel patches will be accepted. When the kernel patches land in the Dave's or Linus's tree, the userspace patches can be pushed.

Marek
________________________________
From: Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org<mailto:Marek.Olsak-5C7GfCeVMHo@public.gmane.org>>
Sent: November 15, 2019 14:34
To: Koenig, Christian <Christian.Koenig-5C7GfCeVMHo@public.gmane.org<mailto:Christian.Koenig@amd.com>>; Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org<mailto:Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>>
Cc: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org<mailto:ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>; Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org<mailto:Aaron.Liu@amd.com>>; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org<mailto:amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org<mailto:amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>>; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org<mailto:Ray.Huang-5C7GfCeVMHo@public.gmane.org>>; Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org<mailto:Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org<mailto:Leo.Liu-5C7GfCeVMHo@public.gmane.org>>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

In the kernel tree, you need to do "make headers_install". Then copy amdgpu_drm.h from ./usr/ to the libdrm tree and discard parts that we can't upstream (freesync).

Marek
________________________________
From: Koenig, Christian <Christian.Koenig-5C7GfCeVMHo@public.gmane.org<mailto:Christian.Koenig@amd.com>>
Sent: November 15, 2019 10:08
To: Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org<mailto:Alexander.Deucher@amd.com>>
Cc: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org<mailto:ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>; Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org<mailto:Aaron.Liu@amd.com>>; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org<mailto:amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> <amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org<mailto:amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>>; Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org<mailto:Marek.Olsak-5C7GfCeVMHo@public.gmane.org>>; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org<mailto:Ray.Huang-5C7GfCeVMHo@public.gmane.org>>; Tuikov, Luben <Luben.Tuikov@amd.com<mailto:Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org<mailto:Leo.Liu@amd.com>>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

I know, that's the usual chicken and egg problem with updating libdrm.

But we should update the file with the kernel version and not pick all changes line by line.

Christian.

Am 15.11.2019 15:49 schrieb "Deucher, Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org<mailto:Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>>:
We can't land the kernel side until we have real userspace (e.g., Mesa) that uses the TMZ interfaces.  The unit tests are not enough.

Alex


________________________________
From: Christian König <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org<mailto:ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
Sent: Friday, November 15, 2019 7:56 AM
To: Liu, Aaron <Aaron.Liu-5C7GfCeVMHo@public.gmane.org<mailto:Aaron.Liu-5C7GfCeVMHo@public.gmane.org>>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org> <amd-gfx-PD4FTy7X32mMSPqsTGOZug@public.gmane.orgesktop.org<mailto:amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>>
Cc: Olsak, Marek <Marek.Olsak-5C7GfCeVMHo@public.gmane.org<mailto:Marek.Olsak-5C7GfCeVMHo@public.gmane.org>>; Huang, Ray <Ray.Huang-5C7GfCeVMHo@public.gmane.org<mailto:Ray.Huang-5C7GfCeVMHo@public.gmane.org>>; Tuikov, Luben <Luben.Tuikov-5C7GfCeVMHo@public.gmane.org<mailto:Luben.Tuikov-5C7GfCeVMHo@public.gmane.org>>; Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org<mailto:Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>>; Liu, Leo <Leo.Liu-5C7GfCeVMHo@public.gmane.org<mailto:Leo.Liu-5C7GfCeVMHo@public.gmane.org>>; Koenig, Christian <Christian.Koenig-5C7GfCeVMHo@public.gmane.org<mailto:Christian.Koenig-5C7GfCeVMHo@public.gmane.org>>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org<mailto:ray.huang-5C7GfCeVMHo@public.gmane.org>>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org<mailto:ray.huang-5C7GfCeVMHo@public.gmane.org>>
> Reviewed-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org<mailto:alexander.deucher-5C7GfCeVMHo@public.gmane.org>>

Please read up on how amdpu_drm.h is updated. The change must first land
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE      (1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */

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

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

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

RE: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Liu, Aaron]

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

Thanks for reviews.

As Christian's suggestion, I added drm_version checking, for the older driver, security test suites are disabled.
I create a remote branch for libdrm: remotes/origin/aaliu/for-tmz-support

BR,
Aaron Liu

From: Olsak, Marek <Marek.Olsak@amd.com>
Sent: Saturday, November 16, 2019 3:53 AM
To: Koenig, Christian <Christian.Koenig@amd.com>; Deucher, Alexander <Alexander.Deucher@amd.com>
Cc: Christian König <ckoenig.leichtzumerken@gmail.com>; Liu, Aaron <Aaron.Liu@amd.com>; amd-gfx@lists.freedesktop.org; Huang, Ray <Ray.Huang@amd.com>; Tuikov, Luben <Luben.Tuikov@amd.com>; Liu, Leo <Leo.Liu@amd.com>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

The way this is upstreamed is that you submit the kernel and userspace patches for review at the same time. When they see the userspace patches, the kernel patches will be accepted. When the kernel patches land in the Dave's or Linus's tree, the userspace patches can be pushed.

Marek
________________________________
From: Olsak, Marek <Marek.Olsak@amd.com<mailto:Marek.Olsak@amd.com>>
Sent: November 15, 2019 14:34
To: Koenig, Christian <Christian.Koenig@amd.com<mailto:Christian.Koenig@amd.com>>; Deucher, Alexander <Alexander.Deucher@amd.com<mailto:Alexander.Deucher@amd.com>>
Cc: Christian König <ckoenig.leichtzumerken@gmail.com<mailto:ckoenig.leichtzumerken@gmail.com>>; Liu, Aaron <Aaron.Liu@amd.com<mailto:Aaron.Liu@amd.com>>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> <amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>>; Huang, Ray <Ray.Huang@amd.com<mailto:Ray.Huang@amd.com>>; Tuikov, Luben <Luben.Tuikov@amd.com<mailto:Luben.Tuikov@amd.com>>; Liu, Leo <Leo.Liu@amd.com<mailto:Leo.Liu@amd.com>>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

In the kernel tree, you need to do "make headers_install". Then copy amdgpu_drm.h from ./usr/ to the libdrm tree and discard parts that we can't upstream (freesync).

Marek
________________________________
From: Koenig, Christian <Christian.Koenig@amd.com<mailto:Christian.Koenig@amd.com>>
Sent: November 15, 2019 10:08
To: Deucher, Alexander <Alexander.Deucher@amd.com<mailto:Alexander.Deucher@amd.com>>
Cc: Christian König <ckoenig.leichtzumerken@gmail.com<mailto:ckoenig.leichtzumerken@gmail.com>>; Liu, Aaron <Aaron.Liu@amd.com<mailto:Aaron.Liu@amd.com>>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> <amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>>; Olsak, Marek <Marek.Olsak@amd.com<mailto:Marek.Olsak@amd.com>>; Huang, Ray <Ray.Huang@amd.com<mailto:Ray.Huang@amd.com>>; Tuikov, Luben <Luben.Tuikov@amd.com<mailto:Luben.Tuikov@amd.com>>; Liu, Leo <Leo.Liu@amd.com<mailto:Leo.Liu@amd.com>>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

I know, that's the usual chicken and egg problem with updating libdrm.

But we should update the file with the kernel version and not pick all changes line by line.

Christian.

Am 15.11.2019 15:49 schrieb "Deucher, Alexander" <Alexander.Deucher@amd.com<mailto:Alexander.Deucher@amd.com>>:
We can't land the kernel side until we have real userspace (e.g., Mesa) that uses the TMZ interfaces.  The unit tests are not enough.

Alex


________________________________
From: Christian König <ckoenig.leichtzumerken@gmail.com<mailto:ckoenig.leichtzumerken@gmail.com>>
Sent: Friday, November 15, 2019 7:56 AM
To: Liu, Aaron <Aaron.Liu@amd.com<mailto:Aaron.Liu@amd.com>>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> <amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>>
Cc: Olsak, Marek <Marek.Olsak@amd.com<mailto:Marek.Olsak@amd.com>>; Huang, Ray <Ray.Huang@amd.com<mailto:Ray.Huang@amd.com>>; Tuikov, Luben <Luben.Tuikov@amd.com<mailto:Luben.Tuikov@amd.com>>; Deucher, Alexander <Alexander.Deucher@amd.com<mailto:Alexander.Deucher@amd.com>>; Liu, Leo <Leo.Liu@amd.com<mailto:Leo.Liu@amd.com>>; Koenig, Christian <Christian.Koenig@amd.com<mailto:Christian.Koenig@amd.com>>
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui <ray.huang@amd.com<mailto:ray.huang@amd.com>>
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
>
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com<mailto:ray.huang@amd.com>>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com<mailto:alexander.deucher@amd.com>>

Please read up on how amdpu_drm.h is updated. The change must first land
upstream and then the file is synced up somehow semi-automatic.

Christian.

> ---
>   include/drm/amdgpu_drm.h | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>    * releasing the memory
>    */
>   #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE      (1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
>   /* Hybrid specific */
>   /* Flag that the memory allocation should be from top of domain */

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

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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Luben Tuikov]

On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui <ray.huang@amd.com>
> 
> To align the kernel uapi change from Alex:
> 
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
> 
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
>  include/drm/amdgpu_drm.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>   * releasing the memory
>   */
>  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE	(1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED		(1 << 10)

Style!
TAB char?!

You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
Do NOT add/insert TAB chars instead of space to align colunmns!
If when you press Tab key a tab is inserted, as opposed to the line
indented, then DO NOT use this editor.
The Tab key should "indent according to mode" by inserting TAB chars.
If the line is already indented, as this one is, then it should do nothing.

Don't bunch up definitions together, nor their comments.
You need an empty line after #define and before /* Flag that ... */

In comments please use present tense, not future tense!

The comment can be improved like:

/* Indicates that the BO is encrypted. This will set the TMZ
 * bit in PTEs when mapping this buffer.
 */
#define AMDGPU_GEM_CREATE_ENCRYPTED

Regards,
Luben

>  
>  /* Hybrid specific */
>  /* Flag that the memory allocation should be from top of domain */
> 

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Luben Tuikov]

On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui <ray.huang@amd.com>
> 
> To align the kernel uapi change from Alex:
> 
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is required in order to properly access the data from the
> engines."
> 
> We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
>  include/drm/amdgpu_drm.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index 5c28aa7..1a95e37 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -141,6 +141,11 @@ extern "C" {
>   * releasing the memory
>   */
>  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE	(1 << 9)
> +/* Flag that BO will be encrypted and that the TMZ bit should be
> + * set in the PTEs when mapping this buffer via GPUVM or
> + * accessing it with various hw blocks
> + */
> +#define AMDGPU_GEM_CREATE_ENCRYPTED		(1 << 10)

Style!
TAB char?!

You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
Do NOT add/insert TAB chars instead of space to align colunmns!
If when you press Tab key a tab is inserted, as opposed to the line
indented, then DO NOT use this editor.
The Tab key should "indent according to mode" by inserting TAB chars.
If the line is already indented, as this one is, then it should do nothing.

Don't bunch up definitions together, nor their comments.
You need an empty line after #define and before /* Flag that ... */

In comments please use present tense, not future tense!

The comment can be improved like:

/* Indicates that the BO is encrypted. This will set the TMZ
 * bit in PTEs when mapping this buffer.
 */
#define AMDGPU_GEM_CREATE_ENCRYPTED

Regards,
Luben

>  
>  /* Hybrid specific */
>  /* Flag that the memory allocation should be from top of domain */
> 

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Marek Olšák]

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

On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov-5C7GfCeVMHo@public.gmane.org> wrote:

> On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> > From: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
> >
> > To align the kernel uapi change from Alex:
> >
> > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers
> with
> > this flag set will be created with the TMZ bit set in the PTEs or engines
> > accessing them. This is required in order to properly access the data
> from the
> > engines."
> >
> > We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
> >
> > Signed-off-by: Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>
> > Reviewed-by: Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>
> > ---
> >  include/drm/amdgpu_drm.h | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> > index 5c28aa7..1a95e37 100644
> > --- a/include/drm/amdgpu_drm.h
> > +++ b/include/drm/amdgpu_drm.h
> > @@ -141,6 +141,11 @@ extern "C" {
> >   * releasing the memory
> >   */
> >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE       (1 << 9)
> > +/* Flag that BO will be encrypted and that the TMZ bit should be
> > + * set in the PTEs when mapping this buffer via GPUVM or
> > + * accessing it with various hw blocks
> > + */
> > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
> Style!
> TAB char?!
>
> You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
> Do NOT add/insert TAB chars instead of space to align colunmns!
> If when you press Tab key a tab is inserted, as opposed to the line
> indented, then DO NOT use this editor.
> The Tab key should "indent according to mode" by inserting TAB chars.
> If the line is already indented, as this one is, then it should do nothing.
>

I disagree with this 100%. Tabs or spaces don't matter here from my
perspective. I also disagree with your language. It's overly impolite.

Marek

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

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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Marek Olšák]

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

On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com> wrote:

> On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> > From: Huang Rui <ray.huang@amd.com>
> >
> > To align the kernel uapi change from Alex:
> >
> > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers
> with
> > this flag set will be created with the TMZ bit set in the PTEs or engines
> > accessing them. This is required in order to properly access the data
> from the
> > engines."
> >
> > We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
> >
> > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> > ---
> >  include/drm/amdgpu_drm.h | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> > index 5c28aa7..1a95e37 100644
> > --- a/include/drm/amdgpu_drm.h
> > +++ b/include/drm/amdgpu_drm.h
> > @@ -141,6 +141,11 @@ extern "C" {
> >   * releasing the memory
> >   */
> >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE       (1 << 9)
> > +/* Flag that BO will be encrypted and that the TMZ bit should be
> > + * set in the PTEs when mapping this buffer via GPUVM or
> > + * accessing it with various hw blocks
> > + */
> > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>
> Style!
> TAB char?!
>
> You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
> Do NOT add/insert TAB chars instead of space to align colunmns!
> If when you press Tab key a tab is inserted, as opposed to the line
> indented, then DO NOT use this editor.
> The Tab key should "indent according to mode" by inserting TAB chars.
> If the line is already indented, as this one is, then it should do nothing.
>

I disagree with this 100%. Tabs or spaces don't matter here from my
perspective. I also disagree with your language. It's overly impolite.

Marek

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

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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Luben Tuikov]

On 2019-11-19 21:41, Marek Olšák wrote:
> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com <mailto:luben.tuikov@amd.com>> wrote:
> 
>     On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>     > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>     >
>     > To align the kernel uapi change from Alex:
>     >
>     > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
>     > this flag set will be created with the TMZ bit set in the PTEs or engines
>     > accessing them. This is required in order to properly access the data from the
>     > engines."
>     >
>     > We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>     >
>     > Signed-off-by: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>     > Reviewed-by: Alex Deucher <alexander.deucher@amd.com <mailto:alexander.deucher@amd.com>>
>     > ---
>     >  include/drm/amdgpu_drm.h | 5 +++++
>     >  1 file changed, 5 insertions(+)
>     >
>     > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>     > index 5c28aa7..1a95e37 100644
>     > --- a/include/drm/amdgpu_drm.h
>     > +++ b/include/drm/amdgpu_drm.h
>     > @@ -141,6 +141,11 @@ extern "C" {
>     >   * releasing the memory
>     >   */
>     >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE       (1 << 9)
>     > +/* Flag that BO will be encrypted and that the TMZ bit should be
>     > + * set in the PTEs when mapping this buffer via GPUVM or
>     > + * accessing it with various hw blocks
>     > + */
>     > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
> 
>     Style!
>     TAB char?!
> 
>     You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>     Do NOT add/insert TAB chars instead of space to align colunmns!
>     If when you press Tab key a tab is inserted, as opposed to the line
>     indented, then DO NOT use this editor.
>     The Tab key should "indent according to mode" by inserting TAB chars.
>     If the line is already indented, as this one is, then it should do nothing.
> 
> 
> I disagree with this 100%. Tabs or spaces don't matter here from my perspective. I also disagree with your language. It's overly impolite.

But it's the coding style of Linux: leading tabs only. Try it with Emacs as described and given in

linux/Documentation/process/coding-style.rst

starting at line 589. And press the Tab key on an already indented line--nothing will happen. Linux has traditionally
shunned from loose TAB chars in already indented lines: leading tabs only mode. In a proper code editor
pressing the Tab key only indents according to buffer mode, it shouldn't insert a Tab char willy-nilly.
People may set their tab stops differently for different tab positions and inserting a tab char may display
incorrectly. The most portable way to align columns in an already indented-according-to-mode line, is
using spaces. (Of course this doesn't matter when using spaces to indent, but Linux uses hard TAB chars
to indent: linux/Documentation/process/coding-style.rst. (which also seem to be set to 8 chars))

It's a code review, there is no "language".

Regards,
Luben

> 
> Marek

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Luben Tuikov]

On 2019-11-19 21:41, Marek Olšák wrote:
> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com <mailto:luben.tuikov@amd.com>> wrote:
> 
>     On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>     > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>     >
>     > To align the kernel uapi change from Alex:
>     >
>     > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
>     > this flag set will be created with the TMZ bit set in the PTEs or engines
>     > accessing them. This is required in order to properly access the data from the
>     > engines."
>     >
>     > We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>     >
>     > Signed-off-by: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>     > Reviewed-by: Alex Deucher <alexander.deucher@amd.com <mailto:alexander.deucher@amd.com>>
>     > ---
>     >  include/drm/amdgpu_drm.h | 5 +++++
>     >  1 file changed, 5 insertions(+)
>     >
>     > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>     > index 5c28aa7..1a95e37 100644
>     > --- a/include/drm/amdgpu_drm.h
>     > +++ b/include/drm/amdgpu_drm.h
>     > @@ -141,6 +141,11 @@ extern "C" {
>     >   * releasing the memory
>     >   */
>     >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE       (1 << 9)
>     > +/* Flag that BO will be encrypted and that the TMZ bit should be
>     > + * set in the PTEs when mapping this buffer via GPUVM or
>     > + * accessing it with various hw blocks
>     > + */
>     > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
> 
>     Style!
>     TAB char?!
> 
>     You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>     Do NOT add/insert TAB chars instead of space to align colunmns!
>     If when you press Tab key a tab is inserted, as opposed to the line
>     indented, then DO NOT use this editor.
>     The Tab key should "indent according to mode" by inserting TAB chars.
>     If the line is already indented, as this one is, then it should do nothing.
> 
> 
> I disagree with this 100%. Tabs or spaces don't matter here from my perspective. I also disagree with your language. It's overly impolite.

But it's the coding style of Linux: leading tabs only. Try it with Emacs as described and given in

linux/Documentation/process/coding-style.rst

starting at line 589. And press the Tab key on an already indented line--nothing will happen. Linux has traditionally
shunned from loose TAB chars in already indented lines: leading tabs only mode. In a proper code editor
pressing the Tab key only indents according to buffer mode, it shouldn't insert a Tab char willy-nilly.
People may set their tab stops differently for different tab positions and inserting a tab char may display
incorrectly. The most portable way to align columns in an already indented-according-to-mode line, is
using spaces. (Of course this doesn't matter when using spaces to indent, but Linux uses hard TAB chars
to indent: linux/Documentation/process/coding-style.rst. (which also seem to be set to 8 chars))

It's a code review, there is no "language".

Regards,
Luben

> 
> Marek

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Harry Wentland]

On 2019-11-20 11:49 a.m., Luben Tuikov wrote:
> On 2019-11-19 21:41, Marek Olšák wrote:
>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com <mailto:luben.tuikov@amd.com>> wrote:
>>
>>     On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>     > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>     >
>>     > To align the kernel uapi change from Alex:
>>     >
>>     > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
>>     > this flag set will be created with the TMZ bit set in the PTEs or engines
>>     > accessing them. This is required in order to properly access the data from the
>>     > engines."
>>     >
>>     > We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>>     >
>>     > Signed-off-by: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>     > Reviewed-by: Alex Deucher <alexander.deucher@amd.com <mailto:alexander.deucher@amd.com>>
>>     > ---
>>     >  include/drm/amdgpu_drm.h | 5 +++++
>>     >  1 file changed, 5 insertions(+)
>>     >
>>     > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>     > index 5c28aa7..1a95e37 100644
>>     > --- a/include/drm/amdgpu_drm.h
>>     > +++ b/include/drm/amdgpu_drm.h
>>     > @@ -141,6 +141,11 @@ extern "C" {
>>     >   * releasing the memory
>>     >   */
>>     >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE       (1 << 9)
>>     > +/* Flag that BO will be encrypted and that the TMZ bit should be
>>     > + * set in the PTEs when mapping this buffer via GPUVM or
>>     > + * accessing it with various hw blocks
>>     > + */
>>     > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>
>>     Style!
>>     TAB char?!
>>
>>     You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>     Do NOT add/insert TAB chars instead of space to align colunmns!
>>     If when you press Tab key a tab is inserted, as opposed to the line
>>     indented, then DO NOT use this editor.
>>     The Tab key should "indent according to mode" by inserting TAB chars.
>>     If the line is already indented, as this one is, then it should do nothing.
>>
>>
>> I disagree with this 100%. Tabs or spaces don't matter here from my perspective. I also disagree with your language. It's overly impolite.
> 
> But it's the coding style of Linux: leading tabs only. Try it with Emacs as described and given in
> 
> linux/Documentation/process/coding-style.rst
> 
> starting at line 589. And press the Tab key on an already indented line--nothing will happen. Linux has traditionally
> shunned from loose TAB chars in already indented lines: leading tabs only mode. In a proper code editor
> pressing the Tab key only indents according to buffer mode, it shouldn't insert a Tab char willy-nilly.
> People may set their tab stops differently for different tab positions and inserting a tab char may display
> incorrectly. The most portable way to align columns in an already indented-according-to-mode line, is
> using spaces. (Of course this doesn't matter when using spaces to indent, but Linux uses hard TAB chars
> to indent: linux/Documentation/process/coding-style.rst. (which also seem to be set to 8 chars))
> 
> It's a code review, there is no "language".

May I remind you that freedesktop.org hosted projects follow a code of
conduct [1]. This applies whether the interaction is a code review or
any other interaction.

I don't think your language was overly impolite but it did come across a
bit strong. Please consider how your statements might be perceived by
the person they're addressed to.

[1] https://www.freedesktop.org/wiki/CodeOfConduct/

Harry

> 
> Regards,
> Luben
> 
>>
>> Marek
> 
> _______________________________________________
> 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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Harry Wentland]

On 2019-11-20 11:49 a.m., Luben Tuikov wrote:
> On 2019-11-19 21:41, Marek Olšák wrote:
>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com <mailto:luben.tuikov@amd.com>> wrote:
>>
>>     On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>     > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>     >
>>     > To align the kernel uapi change from Alex:
>>     >
>>     > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
>>     > this flag set will be created with the TMZ bit set in the PTEs or engines
>>     > accessing them. This is required in order to properly access the data from the
>>     > engines."
>>     >
>>     > We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>>     >
>>     > Signed-off-by: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>     > Reviewed-by: Alex Deucher <alexander.deucher@amd.com <mailto:alexander.deucher@amd.com>>
>>     > ---
>>     >  include/drm/amdgpu_drm.h | 5 +++++
>>     >  1 file changed, 5 insertions(+)
>>     >
>>     > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>     > index 5c28aa7..1a95e37 100644
>>     > --- a/include/drm/amdgpu_drm.h
>>     > +++ b/include/drm/amdgpu_drm.h
>>     > @@ -141,6 +141,11 @@ extern "C" {
>>     >   * releasing the memory
>>     >   */
>>     >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE       (1 << 9)
>>     > +/* Flag that BO will be encrypted and that the TMZ bit should be
>>     > + * set in the PTEs when mapping this buffer via GPUVM or
>>     > + * accessing it with various hw blocks
>>     > + */
>>     > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>
>>     Style!
>>     TAB char?!
>>
>>     You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>     Do NOT add/insert TAB chars instead of space to align colunmns!
>>     If when you press Tab key a tab is inserted, as opposed to the line
>>     indented, then DO NOT use this editor.
>>     The Tab key should "indent according to mode" by inserting TAB chars.
>>     If the line is already indented, as this one is, then it should do nothing.
>>
>>
>> I disagree with this 100%. Tabs or spaces don't matter here from my perspective. I also disagree with your language. It's overly impolite.
> 
> But it's the coding style of Linux: leading tabs only. Try it with Emacs as described and given in
> 
> linux/Documentation/process/coding-style.rst
> 
> starting at line 589. And press the Tab key on an already indented line--nothing will happen. Linux has traditionally
> shunned from loose TAB chars in already indented lines: leading tabs only mode. In a proper code editor
> pressing the Tab key only indents according to buffer mode, it shouldn't insert a Tab char willy-nilly.
> People may set their tab stops differently for different tab positions and inserting a tab char may display
> incorrectly. The most portable way to align columns in an already indented-according-to-mode line, is
> using spaces. (Of course this doesn't matter when using spaces to indent, but Linux uses hard TAB chars
> to indent: linux/Documentation/process/coding-style.rst. (which also seem to be set to 8 chars))
> 
> It's a code review, there is no "language".

May I remind you that freedesktop.org hosted projects follow a code of
conduct [1]. This applies whether the interaction is a code review or
any other interaction.

I don't think your language was overly impolite but it did come across a
bit strong. Please consider how your statements might be perceived by
the person they're addressed to.

[1] https://www.freedesktop.org/wiki/CodeOfConduct/

Harry

> 
> Regards,
> Luben
> 
>>
>> Marek
> 
> _______________________________________________
> 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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Harry Wentland]

On 2019-11-20 12:05 p.m., Harry Wentland wrote:
> On 2019-11-20 11:49 a.m., Luben Tuikov wrote:
>> On 2019-11-19 21:41, Marek Olšák wrote:
>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com <mailto:luben.tuikov@amd.com>> wrote:
>>>
>>>     On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>     > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>     >
>>>     > To align the kernel uapi change from Alex:
>>>     >
>>>     > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
>>>     > this flag set will be created with the TMZ bit set in the PTEs or engines
>>>     > accessing them. This is required in order to properly access the data from the
>>>     > engines."
>>>     >
>>>     > We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>>>     >
>>>     > Signed-off-by: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>     > Reviewed-by: Alex Deucher <alexander.deucher@amd.com <mailto:alexander.deucher@amd.com>>
>>>     > ---
>>>     >  include/drm/amdgpu_drm.h | 5 +++++
>>>     >  1 file changed, 5 insertions(+)
>>>     >
>>>     > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>     > index 5c28aa7..1a95e37 100644
>>>     > --- a/include/drm/amdgpu_drm.h
>>>     > +++ b/include/drm/amdgpu_drm.h
>>>     > @@ -141,6 +141,11 @@ extern "C" {
>>>     >   * releasing the memory
>>>     >   */
>>>     >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE       (1 << 9)
>>>     > +/* Flag that BO will be encrypted and that the TMZ bit should be
>>>     > + * set in the PTEs when mapping this buffer via GPUVM or
>>>     > + * accessing it with various hw blocks
>>>     > + */
>>>     > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>
>>>     Style!
>>>     TAB char?!
>>>
>>>     You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>     Do NOT add/insert TAB chars instead of space to align colunmns!
>>>     If when you press Tab key a tab is inserted, as opposed to the line
>>>     indented, then DO NOT use this editor.
>>>     The Tab key should "indent according to mode" by inserting TAB chars.
>>>     If the line is already indented, as this one is, then it should do nothing.
>>>
>>>
>>> I disagree with this 100%. Tabs or spaces don't matter here from my perspective. I also disagree with your language. It's overly impolite.
>>
>> But it's the coding style of Linux: leading tabs only. Try it with Emacs as described and given in
>>
>> linux/Documentation/process/coding-style.rst
>>
>> starting at line 589. And press the Tab key on an already indented line--nothing will happen. Linux has traditionally
>> shunned from loose TAB chars in already indented lines: leading tabs only mode. In a proper code editor
>> pressing the Tab key only indents according to buffer mode, it shouldn't insert a Tab char willy-nilly.
>> People may set their tab stops differently for different tab positions and inserting a tab char may display
>> incorrectly. The most portable way to align columns in an already indented-according-to-mode line, is
>> using spaces. (Of course this doesn't matter when using spaces to indent, but Linux uses hard TAB chars
>> to indent: linux/Documentation/process/coding-style.rst. (which also seem to be set to 8 chars))
>>
>> It's a code review, there is no "language".
> 
> May I remind you that freedesktop.org hosted projects follow a code of
> conduct [1]. This applies whether the interaction is a code review or
> any other interaction.
> 
> I don't think your language was overly impolite but it did come across a
> bit strong. Please consider how your statements might be perceived by

Just to clarify, and I did intend to highlight this in the previous
sentence, I don't think there is any violation of the CoC here. I am
merely trying to say that language matters, even for code reviews.

Harry

> the person they're addressed to.
> 
> [1] https://www.freedesktop.org/wiki/CodeOfConduct/
> 
> Harry
> 
>>
>> Regards,
>> Luben
>>
>>>
>>> Marek
>>
>> _______________________________________________
>> 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
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Harry Wentland]

On 2019-11-20 12:05 p.m., Harry Wentland wrote:
> On 2019-11-20 11:49 a.m., Luben Tuikov wrote:
>> On 2019-11-19 21:41, Marek Olšák wrote:
>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com <mailto:luben.tuikov@amd.com>> wrote:
>>>
>>>     On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>     > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>     >
>>>     > To align the kernel uapi change from Alex:
>>>     >
>>>     > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
>>>     > this flag set will be created with the TMZ bit set in the PTEs or engines
>>>     > accessing them. This is required in order to properly access the data from the
>>>     > engines."
>>>     >
>>>     > We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>>>     >
>>>     > Signed-off-by: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>     > Reviewed-by: Alex Deucher <alexander.deucher@amd.com <mailto:alexander.deucher@amd.com>>
>>>     > ---
>>>     >  include/drm/amdgpu_drm.h | 5 +++++
>>>     >  1 file changed, 5 insertions(+)
>>>     >
>>>     > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>     > index 5c28aa7..1a95e37 100644
>>>     > --- a/include/drm/amdgpu_drm.h
>>>     > +++ b/include/drm/amdgpu_drm.h
>>>     > @@ -141,6 +141,11 @@ extern "C" {
>>>     >   * releasing the memory
>>>     >   */
>>>     >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE       (1 << 9)
>>>     > +/* Flag that BO will be encrypted and that the TMZ bit should be
>>>     > + * set in the PTEs when mapping this buffer via GPUVM or
>>>     > + * accessing it with various hw blocks
>>>     > + */
>>>     > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>
>>>     Style!
>>>     TAB char?!
>>>
>>>     You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>     Do NOT add/insert TAB chars instead of space to align colunmns!
>>>     If when you press Tab key a tab is inserted, as opposed to the line
>>>     indented, then DO NOT use this editor.
>>>     The Tab key should "indent according to mode" by inserting TAB chars.
>>>     If the line is already indented, as this one is, then it should do nothing.
>>>
>>>
>>> I disagree with this 100%. Tabs or spaces don't matter here from my perspective. I also disagree with your language. It's overly impolite.
>>
>> But it's the coding style of Linux: leading tabs only. Try it with Emacs as described and given in
>>
>> linux/Documentation/process/coding-style.rst
>>
>> starting at line 589. And press the Tab key on an already indented line--nothing will happen. Linux has traditionally
>> shunned from loose TAB chars in already indented lines: leading tabs only mode. In a proper code editor
>> pressing the Tab key only indents according to buffer mode, it shouldn't insert a Tab char willy-nilly.
>> People may set their tab stops differently for different tab positions and inserting a tab char may display
>> incorrectly. The most portable way to align columns in an already indented-according-to-mode line, is
>> using spaces. (Of course this doesn't matter when using spaces to indent, but Linux uses hard TAB chars
>> to indent: linux/Documentation/process/coding-style.rst. (which also seem to be set to 8 chars))
>>
>> It's a code review, there is no "language".
> 
> May I remind you that freedesktop.org hosted projects follow a code of
> conduct [1]. This applies whether the interaction is a code review or
> any other interaction.
> 
> I don't think your language was overly impolite but it did come across a
> bit strong. Please consider how your statements might be perceived by

Just to clarify, and I did intend to highlight this in the previous
sentence, I don't think there is any violation of the CoC here. I am
merely trying to say that language matters, even for code reviews.

Harry

> the person they're addressed to.
> 
> [1] https://www.freedesktop.org/wiki/CodeOfConduct/
> 
> Harry
> 
>>
>> Regards,
>> Luben
>>
>>>
>>> Marek
>>
>> _______________________________________________
>> 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
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Christian König]

Am 20.11.19 um 17:49 schrieb Luben Tuikov:
> On 2019-11-19 21:41, Marek Olšák wrote:
>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com <mailto:luben.tuikov@amd.com>> wrote:
>>
>>      On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>      > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>      >
>>      > To align the kernel uapi change from Alex:
>>      >
>>      > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
>>      > this flag set will be created with the TMZ bit set in the PTEs or engines
>>      > accessing them. This is required in order to properly access the data from the
>>      > engines."
>>      >
>>      > We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>>      >
>>      > Signed-off-by: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>      > Reviewed-by: Alex Deucher <alexander.deucher@amd.com <mailto:alexander.deucher@amd.com>>
>>      > ---
>>      >  include/drm/amdgpu_drm.h | 5 +++++
>>      >  1 file changed, 5 insertions(+)
>>      >
>>      > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>      > index 5c28aa7..1a95e37 100644
>>      > --- a/include/drm/amdgpu_drm.h
>>      > +++ b/include/drm/amdgpu_drm.h
>>      > @@ -141,6 +141,11 @@ extern "C" {
>>      >   * releasing the memory
>>      >   */
>>      >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE       (1 << 9)
>>      > +/* Flag that BO will be encrypted and that the TMZ bit should be
>>      > + * set in the PTEs when mapping this buffer via GPUVM or
>>      > + * accessing it with various hw blocks
>>      > + */
>>      > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>
>>      Style!
>>      TAB char?!
>>
>>      You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>      Do NOT add/insert TAB chars instead of space to align colunmns!
>>      If when you press Tab key a tab is inserted, as opposed to the line
>>      indented, then DO NOT use this editor.
>>      The Tab key should "indent according to mode" by inserting TAB chars.
>>      If the line is already indented, as this one is, then it should do nothing.
>>
>>
>> I disagree with this 100%. Tabs or spaces don't matter here from my perspective. I also disagree with your language. It's overly impolite.
> But it's the coding style of Linux: leading tabs only. Try it with Emacs as described and given in
>
> linux/Documentation/process/coding-style.rst
>
> starting at line 589. And press the Tab key on an already indented line--nothing will happen. Linux has traditionally
> shunned from loose TAB chars in already indented lines: leading tabs only mode. In a proper code editor
> pressing the Tab key only indents according to buffer mode, it shouldn't insert a Tab char willy-nilly.
> People may set their tab stops differently for different tab positions and inserting a tab char may display
> incorrectly. The most portable way to align columns in an already indented-according-to-mode line, is
> using spaces. (Of course this doesn't matter when using spaces to indent, but Linux uses hard TAB chars
> to indent: linux/Documentation/process/coding-style.rst. (which also seem to be set to 8 chars))
>
> It's a code review, there is no "language".

Well the section you noted also suggest to either get rid of emacs or 
change it to use some saner default values. We just got rid of emacs.

Regarding tabs after the initial indentation, I've just done a quick 
grep and around 14% of all defines under include/ uses that so I would 
say that this is perfectly fine.

Regards,
Christian.

>
> Regards,
> Luben
>
>> Marek
> _______________________________________________
> 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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Christian König]

Am 20.11.19 um 17:49 schrieb Luben Tuikov:
> On 2019-11-19 21:41, Marek Olšák wrote:
>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com <mailto:luben.tuikov@amd.com>> wrote:
>>
>>      On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>      > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>      >
>>      > To align the kernel uapi change from Alex:
>>      >
>>      > "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
>>      > this flag set will be created with the TMZ bit set in the PTEs or engines
>>      > accessing them. This is required in order to properly access the data from the
>>      > engines."
>>      >
>>      > We will use GEM_CREATE_ENCRYPTED flag for secure buffer allocation.
>>      >
>>      > Signed-off-by: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>      > Reviewed-by: Alex Deucher <alexander.deucher@amd.com <mailto:alexander.deucher@amd.com>>
>>      > ---
>>      >  include/drm/amdgpu_drm.h | 5 +++++
>>      >  1 file changed, 5 insertions(+)
>>      >
>>      > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>      > index 5c28aa7..1a95e37 100644
>>      > --- a/include/drm/amdgpu_drm.h
>>      > +++ b/include/drm/amdgpu_drm.h
>>      > @@ -141,6 +141,11 @@ extern "C" {
>>      >   * releasing the memory
>>      >   */
>>      >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE       (1 << 9)
>>      > +/* Flag that BO will be encrypted and that the TMZ bit should be
>>      > + * set in the PTEs when mapping this buffer via GPUVM or
>>      > + * accessing it with various hw blocks
>>      > + */
>>      > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>
>>      Style!
>>      TAB char?!
>>
>>      You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>      Do NOT add/insert TAB chars instead of space to align colunmns!
>>      If when you press Tab key a tab is inserted, as opposed to the line
>>      indented, then DO NOT use this editor.
>>      The Tab key should "indent according to mode" by inserting TAB chars.
>>      If the line is already indented, as this one is, then it should do nothing.
>>
>>
>> I disagree with this 100%. Tabs or spaces don't matter here from my perspective. I also disagree with your language. It's overly impolite.
> But it's the coding style of Linux: leading tabs only. Try it with Emacs as described and given in
>
> linux/Documentation/process/coding-style.rst
>
> starting at line 589. And press the Tab key on an already indented line--nothing will happen. Linux has traditionally
> shunned from loose TAB chars in already indented lines: leading tabs only mode. In a proper code editor
> pressing the Tab key only indents according to buffer mode, it shouldn't insert a Tab char willy-nilly.
> People may set their tab stops differently for different tab positions and inserting a tab char may display
> incorrectly. The most portable way to align columns in an already indented-according-to-mode line, is
> using spaces. (Of course this doesn't matter when using spaces to indent, but Linux uses hard TAB chars
> to indent: linux/Documentation/process/coding-style.rst. (which also seem to be set to 8 chars))
>
> It's a code review, there is no "language".

Well the section you noted also suggest to either get rid of emacs or 
change it to use some saner default values. We just got rid of emacs.

Regarding tabs after the initial indentation, I've just done a quick 
grep and around 14% of all defines under include/ uses that so I would 
say that this is perfectly fine.

Regards,
Christian.

>
> Regards,
> Luben
>
>> Marek
> _______________________________________________
> 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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Christian König]

Am 20.11.19 um 18:16 schrieb Christian König:
> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>> On 2019-11-19 21:41, Marek Olšák wrote:
>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com 
>>> <mailto:luben.tuikov@amd.com>> wrote:
>>>
>>>      On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>      > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>      >
>>>      > To align the kernel uapi change from Alex:
>>>      >
>>>      > "Add a flag to the GEM_CREATE ioctl to create encrypted 
>>> buffers. Buffers with
>>>      > this flag set will be created with the TMZ bit set in the 
>>> PTEs or engines
>>>      > accessing them. This is required in order to properly access 
>>> the data from the
>>>      > engines."
>>>      >
>>>      > We will use GEM_CREATE_ENCRYPTED flag for secure buffer 
>>> allocation.
>>>      >
>>>      > Signed-off-by: Huang Rui <ray.huang@amd.com 
>>> <mailto:ray.huang@amd.com>>
>>>      > Reviewed-by: Alex Deucher <alexander.deucher@amd.com 
>>> <mailto:alexander.deucher@amd.com>>
>>>      > ---
>>>      >  include/drm/amdgpu_drm.h | 5 +++++
>>>      >  1 file changed, 5 insertions(+)
>>>      >
>>>      > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>      > index 5c28aa7..1a95e37 100644
>>>      > --- a/include/drm/amdgpu_drm.h
>>>      > +++ b/include/drm/amdgpu_drm.h
>>>      > @@ -141,6 +141,11 @@ extern "C" {
>>>      >   * releasing the memory
>>>      >   */
>>>      >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE  (1 << 9)
>>>      > +/* Flag that BO will be encrypted and that the TMZ bit 
>>> should be
>>>      > + * set in the PTEs when mapping this buffer via GPUVM or
>>>      > + * accessing it with various hw blocks
>>>      > + */
>>>      > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>
>>>      Style!
>>>      TAB char?!
>>>
>>>      You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>      Do NOT add/insert TAB chars instead of space to align colunmns!
>>>      If when you press Tab key a tab is inserted, as opposed to the 
>>> line
>>>      indented, then DO NOT use this editor.
>>>      The Tab key should "indent according to mode" by inserting TAB 
>>> chars.
>>>      If the line is already indented, as this one is, then it should 
>>> do nothing.
>>>
>>>
>>> I disagree with this 100%. Tabs or spaces don't matter here from my 
>>> perspective. I also disagree with your language. It's overly impolite.
>> But it's the coding style of Linux: leading tabs only. Try it with 
>> Emacs as described and given in
>>
>> linux/Documentation/process/coding-style.rst
>>
>> starting at line 589. And press the Tab key on an already indented 
>> line--nothing will happen. Linux has traditionally
>> shunned from loose TAB chars in already indented lines: leading tabs 
>> only mode. In a proper code editor
>> pressing the Tab key only indents according to buffer mode, it 
>> shouldn't insert a Tab char willy-nilly.
>> People may set their tab stops differently for different tab 
>> positions and inserting a tab char may display
>> incorrectly. The most portable way to align columns in an already 
>> indented-according-to-mode line, is
>> using spaces. (Of course this doesn't matter when using spaces to 
>> indent, but Linux uses hard TAB chars
>> to indent: linux/Documentation/process/coding-style.rst. (which also 
>> seem to be set to 8 chars))
>>
>> It's a code review, there is no "language".
>
> Well the section you noted also suggest to either get rid of emacs or 
> change it to use some saner default values. We just got rid of emacs.
>
> Regarding tabs after the initial indentation, I've just done a quick 
> grep and around 14% of all defines under include/ uses that so I would 
> say that this is perfectly fine.

Fast typing with lazy eyes, that should read "around 71% of all defines".

Sorry,
Christian.

>
> Regards,
> Christian.
>
>>
>> Regards,
>> Luben
>>
>>> Marek
>> _______________________________________________
>> 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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Christian König]

Am 20.11.19 um 18:16 schrieb Christian König:
> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>> On 2019-11-19 21:41, Marek Olšák wrote:
>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com 
>>> <mailto:luben.tuikov@amd.com>> wrote:
>>>
>>>      On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>      > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>      >
>>>      > To align the kernel uapi change from Alex:
>>>      >
>>>      > "Add a flag to the GEM_CREATE ioctl to create encrypted 
>>> buffers. Buffers with
>>>      > this flag set will be created with the TMZ bit set in the 
>>> PTEs or engines
>>>      > accessing them. This is required in order to properly access 
>>> the data from the
>>>      > engines."
>>>      >
>>>      > We will use GEM_CREATE_ENCRYPTED flag for secure buffer 
>>> allocation.
>>>      >
>>>      > Signed-off-by: Huang Rui <ray.huang@amd.com 
>>> <mailto:ray.huang@amd.com>>
>>>      > Reviewed-by: Alex Deucher <alexander.deucher@amd.com 
>>> <mailto:alexander.deucher@amd.com>>
>>>      > ---
>>>      >  include/drm/amdgpu_drm.h | 5 +++++
>>>      >  1 file changed, 5 insertions(+)
>>>      >
>>>      > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>      > index 5c28aa7..1a95e37 100644
>>>      > --- a/include/drm/amdgpu_drm.h
>>>      > +++ b/include/drm/amdgpu_drm.h
>>>      > @@ -141,6 +141,11 @@ extern "C" {
>>>      >   * releasing the memory
>>>      >   */
>>>      >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE  (1 << 9)
>>>      > +/* Flag that BO will be encrypted and that the TMZ bit 
>>> should be
>>>      > + * set in the PTEs when mapping this buffer via GPUVM or
>>>      > + * accessing it with various hw blocks
>>>      > + */
>>>      > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>
>>>      Style!
>>>      TAB char?!
>>>
>>>      You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>      Do NOT add/insert TAB chars instead of space to align colunmns!
>>>      If when you press Tab key a tab is inserted, as opposed to the 
>>> line
>>>      indented, then DO NOT use this editor.
>>>      The Tab key should "indent according to mode" by inserting TAB 
>>> chars.
>>>      If the line is already indented, as this one is, then it should 
>>> do nothing.
>>>
>>>
>>> I disagree with this 100%. Tabs or spaces don't matter here from my 
>>> perspective. I also disagree with your language. It's overly impolite.
>> But it's the coding style of Linux: leading tabs only. Try it with 
>> Emacs as described and given in
>>
>> linux/Documentation/process/coding-style.rst
>>
>> starting at line 589. And press the Tab key on an already indented 
>> line--nothing will happen. Linux has traditionally
>> shunned from loose TAB chars in already indented lines: leading tabs 
>> only mode. In a proper code editor
>> pressing the Tab key only indents according to buffer mode, it 
>> shouldn't insert a Tab char willy-nilly.
>> People may set their tab stops differently for different tab 
>> positions and inserting a tab char may display
>> incorrectly. The most portable way to align columns in an already 
>> indented-according-to-mode line, is
>> using spaces. (Of course this doesn't matter when using spaces to 
>> indent, but Linux uses hard TAB chars
>> to indent: linux/Documentation/process/coding-style.rst. (which also 
>> seem to be set to 8 chars))
>>
>> It's a code review, there is no "language".
>
> Well the section you noted also suggest to either get rid of emacs or 
> change it to use some saner default values. We just got rid of emacs.
>
> Regarding tabs after the initial indentation, I've just done a quick 
> grep and around 14% of all defines under include/ uses that so I would 
> say that this is perfectly fine.

Fast typing with lazy eyes, that should read "around 71% of all defines".

Sorry,
Christian.

>
> Regards,
> Christian.
>
>>
>> Regards,
>> Luben
>>
>>> Marek
>> _______________________________________________
>> 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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Luben Tuikov]

On 2019-11-20 12:24, Christian König wrote:
> Am 20.11.19 um 18:16 schrieb Christian König:
>> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>>> On 2019-11-19 21:41, Marek Olšák wrote:
>>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com 
>>>> <mailto:luben.tuikov@amd.com>> wrote:
>>>>
>>>>      On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>>      > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>>      >
>>>>      > To align the kernel uapi change from Alex:
>>>>      >
>>>>      > "Add a flag to the GEM_CREATE ioctl to create encrypted 
>>>> buffers. Buffers with
>>>>      > this flag set will be created with the TMZ bit set in the 
>>>> PTEs or engines
>>>>      > accessing them. This is required in order to properly access 
>>>> the data from the
>>>>      > engines."
>>>>      >
>>>>      > We will use GEM_CREATE_ENCRYPTED flag for secure buffer 
>>>> allocation.
>>>>      >
>>>>      > Signed-off-by: Huang Rui <ray.huang@amd.com 
>>>> <mailto:ray.huang@amd.com>>
>>>>      > Reviewed-by: Alex Deucher <alexander.deucher@amd.com 
>>>> <mailto:alexander.deucher@amd.com>>
>>>>      > ---
>>>>      >  include/drm/amdgpu_drm.h | 5 +++++
>>>>      >  1 file changed, 5 insertions(+)
>>>>      >
>>>>      > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>>      > index 5c28aa7..1a95e37 100644
>>>>      > --- a/include/drm/amdgpu_drm.h
>>>>      > +++ b/include/drm/amdgpu_drm.h
>>>>      > @@ -141,6 +141,11 @@ extern "C" {
>>>>      >   * releasing the memory
>>>>      >   */
>>>>      >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE  (1 << 9)
>>>>      > +/* Flag that BO will be encrypted and that the TMZ bit 
>>>> should be
>>>>      > + * set in the PTEs when mapping this buffer via GPUVM or
>>>>      > + * accessing it with various hw blocks
>>>>      > + */
>>>>      > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>>
>>>>      Style!
>>>>      TAB char?!
>>>>
>>>>      You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>>      Do NOT add/insert TAB chars instead of space to align colunmns!
>>>>      If when you press Tab key a tab is inserted, as opposed to the 
>>>> line
>>>>      indented, then DO NOT use this editor.
>>>>      The Tab key should "indent according to mode" by inserting TAB 
>>>> chars.
>>>>      If the line is already indented, as this one is, then it should 
>>>> do nothing.
>>>>
>>>>
>>>> I disagree with this 100%. Tabs or spaces don't matter here from my 
>>>> perspective. I also disagree with your language. It's overly impolite.
>>> But it's the coding style of Linux: leading tabs only. Try it with 
>>> Emacs as described and given in
>>>
>>> linux/Documentation/process/coding-style.rst
>>>
>>> starting at line 589. And press the Tab key on an already indented 
>>> line--nothing will happen. Linux has traditionally
>>> shunned from loose TAB chars in already indented lines: leading tabs 
>>> only mode. In a proper code editor
>>> pressing the Tab key only indents according to buffer mode, it 
>>> shouldn't insert a Tab char willy-nilly.
>>> People may set their tab stops differently for different tab 
>>> positions and inserting a tab char may display
>>> incorrectly. The most portable way to align columns in an already 
>>> indented-according-to-mode line, is
>>> using spaces. (Of course this doesn't matter when using spaces to 
>>> indent, but Linux uses hard TAB chars
>>> to indent: linux/Documentation/process/coding-style.rst. (which also 
>>> seem to be set to 8 chars))
>>>
>>> It's a code review, there is no "language".
>>
>> Well the section you noted also suggest to either get rid of emacs or 
>> change it to use some saner default values. We just got rid of emacs.

Yes, it says this, quote (for those who didn't open the file):

--8<---------------------------------------------------------------------

That's OK, we all do.  You've probably been told by your long-time Unix
user helper that ``GNU emacs`` automatically formats the C sources for
you, and you've noticed that yes, it does do that, but the defaults it
uses are less than desirable (in fact, they are worse than random
typing - an infinite number of monkeys typing into GNU emacs would never
make a good program).

So, you can either get rid of GNU emacs, or change it to use saner
values.  To do the latter, you can stick the following in your .emacs file:

--8<--------------------------------------------------------------------

>>
>> Regarding tabs after the initial indentation, I've just done a quick 
>> grep and around 14% of all defines under include/ uses that so I would 
>> say that this is perfectly fine.
> 
> Fast typing with lazy eyes, that should read "around 71% of all defines".

Hmm, that's interesting. Is that in linux/include or amdgpu/include?

I've been meaning to do my own extended regex to catch those, although
I'm using Emacs and pressing Tab key only indents and would not insert
a Tab char if already indented. (So applying this regex into the pre-commit
hook of all of my Git repos would never trigger.)

I remember of olden days, circa 2000 when I first got involved with Linux,
LKML didn't like loose tabs. Also lead kernel developers are using Emacs,
so it's been my choice of editor since circa 1994 (switched from vi to Emacs
largely due to the influence of a graphics prof I had in my seniour year of uni,
and part due to LKML.)

Thanks for chiming in Christian!

Regards,
Luben

> 
> Sorry,
> Christian.
> 
>>
>> Regards,
>> Christian.
>>
>>>
>>> Regards,
>>> Luben
>>>
>>>> Marek
>>> _______________________________________________
>>> 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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Luben Tuikov]

On 2019-11-20 12:24, Christian König wrote:
> Am 20.11.19 um 18:16 schrieb Christian König:
>> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>>> On 2019-11-19 21:41, Marek Olšák wrote:
>>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com 
>>>> <mailto:luben.tuikov@amd.com>> wrote:
>>>>
>>>>      On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>>      > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>>      >
>>>>      > To align the kernel uapi change from Alex:
>>>>      >
>>>>      > "Add a flag to the GEM_CREATE ioctl to create encrypted 
>>>> buffers. Buffers with
>>>>      > this flag set will be created with the TMZ bit set in the 
>>>> PTEs or engines
>>>>      > accessing them. This is required in order to properly access 
>>>> the data from the
>>>>      > engines."
>>>>      >
>>>>      > We will use GEM_CREATE_ENCRYPTED flag for secure buffer 
>>>> allocation.
>>>>      >
>>>>      > Signed-off-by: Huang Rui <ray.huang@amd.com 
>>>> <mailto:ray.huang@amd.com>>
>>>>      > Reviewed-by: Alex Deucher <alexander.deucher@amd.com 
>>>> <mailto:alexander.deucher@amd.com>>
>>>>      > ---
>>>>      >  include/drm/amdgpu_drm.h | 5 +++++
>>>>      >  1 file changed, 5 insertions(+)
>>>>      >
>>>>      > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>>      > index 5c28aa7..1a95e37 100644
>>>>      > --- a/include/drm/amdgpu_drm.h
>>>>      > +++ b/include/drm/amdgpu_drm.h
>>>>      > @@ -141,6 +141,11 @@ extern "C" {
>>>>      >   * releasing the memory
>>>>      >   */
>>>>      >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE  (1 << 9)
>>>>      > +/* Flag that BO will be encrypted and that the TMZ bit 
>>>> should be
>>>>      > + * set in the PTEs when mapping this buffer via GPUVM or
>>>>      > + * accessing it with various hw blocks
>>>>      > + */
>>>>      > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>>
>>>>      Style!
>>>>      TAB char?!
>>>>
>>>>      You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>>      Do NOT add/insert TAB chars instead of space to align colunmns!
>>>>      If when you press Tab key a tab is inserted, as opposed to the 
>>>> line
>>>>      indented, then DO NOT use this editor.
>>>>      The Tab key should "indent according to mode" by inserting TAB 
>>>> chars.
>>>>      If the line is already indented, as this one is, then it should 
>>>> do nothing.
>>>>
>>>>
>>>> I disagree with this 100%. Tabs or spaces don't matter here from my 
>>>> perspective. I also disagree with your language. It's overly impolite.
>>> But it's the coding style of Linux: leading tabs only. Try it with 
>>> Emacs as described and given in
>>>
>>> linux/Documentation/process/coding-style.rst
>>>
>>> starting at line 589. And press the Tab key on an already indented 
>>> line--nothing will happen. Linux has traditionally
>>> shunned from loose TAB chars in already indented lines: leading tabs 
>>> only mode. In a proper code editor
>>> pressing the Tab key only indents according to buffer mode, it 
>>> shouldn't insert a Tab char willy-nilly.
>>> People may set their tab stops differently for different tab 
>>> positions and inserting a tab char may display
>>> incorrectly. The most portable way to align columns in an already 
>>> indented-according-to-mode line, is
>>> using spaces. (Of course this doesn't matter when using spaces to 
>>> indent, but Linux uses hard TAB chars
>>> to indent: linux/Documentation/process/coding-style.rst. (which also 
>>> seem to be set to 8 chars))
>>>
>>> It's a code review, there is no "language".
>>
>> Well the section you noted also suggest to either get rid of emacs or 
>> change it to use some saner default values. We just got rid of emacs.

Yes, it says this, quote (for those who didn't open the file):

--8<---------------------------------------------------------------------

That's OK, we all do.  You've probably been told by your long-time Unix
user helper that ``GNU emacs`` automatically formats the C sources for
you, and you've noticed that yes, it does do that, but the defaults it
uses are less than desirable (in fact, they are worse than random
typing - an infinite number of monkeys typing into GNU emacs would never
make a good program).

So, you can either get rid of GNU emacs, or change it to use saner
values.  To do the latter, you can stick the following in your .emacs file:

--8<--------------------------------------------------------------------

>>
>> Regarding tabs after the initial indentation, I've just done a quick 
>> grep and around 14% of all defines under include/ uses that so I would 
>> say that this is perfectly fine.
> 
> Fast typing with lazy eyes, that should read "around 71% of all defines".

Hmm, that's interesting. Is that in linux/include or amdgpu/include?

I've been meaning to do my own extended regex to catch those, although
I'm using Emacs and pressing Tab key only indents and would not insert
a Tab char if already indented. (So applying this regex into the pre-commit
hook of all of my Git repos would never trigger.)

I remember of olden days, circa 2000 when I first got involved with Linux,
LKML didn't like loose tabs. Also lead kernel developers are using Emacs,
so it's been my choice of editor since circa 1994 (switched from vi to Emacs
largely due to the influence of a graphics prof I had in my seniour year of uni,
and part due to LKML.)

Thanks for chiming in Christian!

Regards,
Luben

> 
> Sorry,
> Christian.
> 
>>
>> Regards,
>> Christian.
>>
>>>
>>> Regards,
>>> Luben
>>>
>>>> Marek
>>> _______________________________________________
>>> 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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Christian König]

Am 20.11.19 um 18:50 schrieb Luben Tuikov:
> On 2019-11-20 12:24, Christian König wrote:
>> Am 20.11.19 um 18:16 schrieb Christian König:
>>> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>>>> On 2019-11-19 21:41, Marek Olšák wrote:
>>>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com
>>>>> <mailto:luben.tuikov@amd.com>> wrote:
>>>>>
>>>>>       On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>>>       > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>>>       >
>>>>>       > To align the kernel uapi change from Alex:
>>>>>       >
>>>>>       > "Add a flag to the GEM_CREATE ioctl to create encrypted
>>>>> buffers. Buffers with
>>>>>       > this flag set will be created with the TMZ bit set in the
>>>>> PTEs or engines
>>>>>       > accessing them. This is required in order to properly access
>>>>> the data from the
>>>>>       > engines."
>>>>>       >
>>>>>       > We will use GEM_CREATE_ENCRYPTED flag for secure buffer
>>>>> allocation.
>>>>>       >
>>>>>       > Signed-off-by: Huang Rui <ray.huang@amd.com
>>>>> <mailto:ray.huang@amd.com>>
>>>>>       > Reviewed-by: Alex Deucher <alexander.deucher@amd.com
>>>>> <mailto:alexander.deucher@amd.com>>
>>>>>       > ---
>>>>>       >  include/drm/amdgpu_drm.h | 5 +++++
>>>>>       >  1 file changed, 5 insertions(+)
>>>>>       >
>>>>>       > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>>>       > index 5c28aa7..1a95e37 100644
>>>>>       > --- a/include/drm/amdgpu_drm.h
>>>>>       > +++ b/include/drm/amdgpu_drm.h
>>>>>       > @@ -141,6 +141,11 @@ extern "C" {
>>>>>       >   * releasing the memory
>>>>>       >   */
>>>>>       >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE  (1 << 9)
>>>>>       > +/* Flag that BO will be encrypted and that the TMZ bit
>>>>> should be
>>>>>       > + * set in the PTEs when mapping this buffer via GPUVM or
>>>>>       > + * accessing it with various hw blocks
>>>>>       > + */
>>>>>       > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>>>
>>>>>       Style!
>>>>>       TAB char?!
>>>>>
>>>>>       You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>>>       Do NOT add/insert TAB chars instead of space to align colunmns!
>>>>>       If when you press Tab key a tab is inserted, as opposed to the
>>>>> line
>>>>>       indented, then DO NOT use this editor.
>>>>>       The Tab key should "indent according to mode" by inserting TAB
>>>>> chars.
>>>>>       If the line is already indented, as this one is, then it should
>>>>> do nothing.
>>>>>
>>>>>
>>>>> I disagree with this 100%. Tabs or spaces don't matter here from my
>>>>> perspective. I also disagree with your language. It's overly impolite.
>>>> But it's the coding style of Linux: leading tabs only. Try it with
>>>> Emacs as described and given in
>>>>
>>>> linux/Documentation/process/coding-style.rst
>>>>
>>>> starting at line 589. And press the Tab key on an already indented
>>>> line--nothing will happen. Linux has traditionally
>>>> shunned from loose TAB chars in already indented lines: leading tabs
>>>> only mode. In a proper code editor
>>>> pressing the Tab key only indents according to buffer mode, it
>>>> shouldn't insert a Tab char willy-nilly.
>>>> People may set their tab stops differently for different tab
>>>> positions and inserting a tab char may display
>>>> incorrectly. The most portable way to align columns in an already
>>>> indented-according-to-mode line, is
>>>> using spaces. (Of course this doesn't matter when using spaces to
>>>> indent, but Linux uses hard TAB chars
>>>> to indent: linux/Documentation/process/coding-style.rst. (which also
>>>> seem to be set to 8 chars))
>>>>
>>>> It's a code review, there is no "language".
>>> Well the section you noted also suggest to either get rid of emacs or
>>> change it to use some saner default values. We just got rid of emacs.
> Yes, it says this, quote (for those who didn't open the file):
>
> --8<---------------------------------------------------------------------
>
> That's OK, we all do.  You've probably been told by your long-time Unix
> user helper that ``GNU emacs`` automatically formats the C sources for
> you, and you've noticed that yes, it does do that, but the defaults it
> uses are less than desirable (in fact, they are worse than random
> typing - an infinite number of monkeys typing into GNU emacs would never
> make a good program).
>
> So, you can either get rid of GNU emacs, or change it to use saner
> values.  To do the latter, you can stick the following in your .emacs file:
>
> --8<--------------------------------------------------------------------
>
>>> Regarding tabs after the initial indentation, I've just done a quick
>>> grep and around 14% of all defines under include/ uses that so I would
>>> say that this is perfectly fine.
>> Fast typing with lazy eyes, that should read "around 71% of all defines".
> Hmm, that's interesting. Is that in linux/include or amdgpu/include?

linux/include

>
> I've been meaning to do my own extended regex to catch those, although
> I'm using Emacs and pressing Tab key only indents and would not insert
> a Tab char if already indented. (So applying this regex into the pre-commit
> hook of all of my Git repos would never trigger.)
>
> I remember of olden days, circa 2000 when I first got involved with Linux,
> LKML didn't like loose tabs. Also lead kernel developers are using Emacs,
> so it's been my choice of editor since circa 1994 (switched from vi to Emacs
> largely due to the influence of a graphics prof I had in my seniour year of uni,
> and part due to LKML.)

Well I've been working with the Linux kernel since the mid 90ths and 
never ever heard of that.

Christian.

>
> Thanks for chiming in Christian!
>
> Regards,
> Luben
>
>> Sorry,
>> Christian.
>>
>>> Regards,
>>> Christian.
>>>
>>>> Regards,
>>>> Luben
>>>>
>>>>> Marek
>>>> _______________________________________________
>>>> 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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Christian König]

Am 20.11.19 um 18:50 schrieb Luben Tuikov:
> On 2019-11-20 12:24, Christian König wrote:
>> Am 20.11.19 um 18:16 schrieb Christian König:
>>> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>>>> On 2019-11-19 21:41, Marek Olšák wrote:
>>>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com
>>>>> <mailto:luben.tuikov@amd.com>> wrote:
>>>>>
>>>>>       On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>>>       > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>>>       >
>>>>>       > To align the kernel uapi change from Alex:
>>>>>       >
>>>>>       > "Add a flag to the GEM_CREATE ioctl to create encrypted
>>>>> buffers. Buffers with
>>>>>       > this flag set will be created with the TMZ bit set in the
>>>>> PTEs or engines
>>>>>       > accessing them. This is required in order to properly access
>>>>> the data from the
>>>>>       > engines."
>>>>>       >
>>>>>       > We will use GEM_CREATE_ENCRYPTED flag for secure buffer
>>>>> allocation.
>>>>>       >
>>>>>       > Signed-off-by: Huang Rui <ray.huang@amd.com
>>>>> <mailto:ray.huang@amd.com>>
>>>>>       > Reviewed-by: Alex Deucher <alexander.deucher@amd.com
>>>>> <mailto:alexander.deucher@amd.com>>
>>>>>       > ---
>>>>>       >  include/drm/amdgpu_drm.h | 5 +++++
>>>>>       >  1 file changed, 5 insertions(+)
>>>>>       >
>>>>>       > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>>>       > index 5c28aa7..1a95e37 100644
>>>>>       > --- a/include/drm/amdgpu_drm.h
>>>>>       > +++ b/include/drm/amdgpu_drm.h
>>>>>       > @@ -141,6 +141,11 @@ extern "C" {
>>>>>       >   * releasing the memory
>>>>>       >   */
>>>>>       >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE  (1 << 9)
>>>>>       > +/* Flag that BO will be encrypted and that the TMZ bit
>>>>> should be
>>>>>       > + * set in the PTEs when mapping this buffer via GPUVM or
>>>>>       > + * accessing it with various hw blocks
>>>>>       > + */
>>>>>       > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>>>
>>>>>       Style!
>>>>>       TAB char?!
>>>>>
>>>>>       You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>>>       Do NOT add/insert TAB chars instead of space to align colunmns!
>>>>>       If when you press Tab key a tab is inserted, as opposed to the
>>>>> line
>>>>>       indented, then DO NOT use this editor.
>>>>>       The Tab key should "indent according to mode" by inserting TAB
>>>>> chars.
>>>>>       If the line is already indented, as this one is, then it should
>>>>> do nothing.
>>>>>
>>>>>
>>>>> I disagree with this 100%. Tabs or spaces don't matter here from my
>>>>> perspective. I also disagree with your language. It's overly impolite.
>>>> But it's the coding style of Linux: leading tabs only. Try it with
>>>> Emacs as described and given in
>>>>
>>>> linux/Documentation/process/coding-style.rst
>>>>
>>>> starting at line 589. And press the Tab key on an already indented
>>>> line--nothing will happen. Linux has traditionally
>>>> shunned from loose TAB chars in already indented lines: leading tabs
>>>> only mode. In a proper code editor
>>>> pressing the Tab key only indents according to buffer mode, it
>>>> shouldn't insert a Tab char willy-nilly.
>>>> People may set their tab stops differently for different tab
>>>> positions and inserting a tab char may display
>>>> incorrectly. The most portable way to align columns in an already
>>>> indented-according-to-mode line, is
>>>> using spaces. (Of course this doesn't matter when using spaces to
>>>> indent, but Linux uses hard TAB chars
>>>> to indent: linux/Documentation/process/coding-style.rst. (which also
>>>> seem to be set to 8 chars))
>>>>
>>>> It's a code review, there is no "language".
>>> Well the section you noted also suggest to either get rid of emacs or
>>> change it to use some saner default values. We just got rid of emacs.
> Yes, it says this, quote (for those who didn't open the file):
>
> --8<---------------------------------------------------------------------
>
> That's OK, we all do.  You've probably been told by your long-time Unix
> user helper that ``GNU emacs`` automatically formats the C sources for
> you, and you've noticed that yes, it does do that, but the defaults it
> uses are less than desirable (in fact, they are worse than random
> typing - an infinite number of monkeys typing into GNU emacs would never
> make a good program).
>
> So, you can either get rid of GNU emacs, or change it to use saner
> values.  To do the latter, you can stick the following in your .emacs file:
>
> --8<--------------------------------------------------------------------
>
>>> Regarding tabs after the initial indentation, I've just done a quick
>>> grep and around 14% of all defines under include/ uses that so I would
>>> say that this is perfectly fine.
>> Fast typing with lazy eyes, that should read "around 71% of all defines".
> Hmm, that's interesting. Is that in linux/include or amdgpu/include?

linux/include

>
> I've been meaning to do my own extended regex to catch those, although
> I'm using Emacs and pressing Tab key only indents and would not insert
> a Tab char if already indented. (So applying this regex into the pre-commit
> hook of all of my Git repos would never trigger.)
>
> I remember of olden days, circa 2000 when I first got involved with Linux,
> LKML didn't like loose tabs. Also lead kernel developers are using Emacs,
> so it's been my choice of editor since circa 1994 (switched from vi to Emacs
> largely due to the influence of a graphics prof I had in my seniour year of uni,
> and part due to LKML.)

Well I've been working with the Linux kernel since the mid 90ths and 
never ever heard of that.

Christian.

>
> Thanks for chiming in Christian!
>
> Regards,
> Luben
>
>> Sorry,
>> Christian.
>>
>>> Regards,
>>> Christian.
>>>
>>>> Regards,
>>>> Luben
>>>>
>>>>> Marek
>>>> _______________________________________________
>>>> 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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Luben Tuikov]

On 2019-11-20 13:40, Christian König wrote:
> Am 20.11.19 um 18:50 schrieb Luben Tuikov:
>> On 2019-11-20 12:24, Christian König wrote:
>>> Am 20.11.19 um 18:16 schrieb Christian König:
>>>> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>>>>> On 2019-11-19 21:41, Marek Olšák wrote:
>>>>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com
>>>>>> <mailto:luben.tuikov@amd.com>> wrote:
>>>>>>
>>>>>>       On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>>>>       > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>>>>       >
>>>>>>       > To align the kernel uapi change from Alex:
>>>>>>       >
>>>>>>       > "Add a flag to the GEM_CREATE ioctl to create encrypted
>>>>>> buffers. Buffers with
>>>>>>       > this flag set will be created with the TMZ bit set in the
>>>>>> PTEs or engines
>>>>>>       > accessing them. This is required in order to properly access
>>>>>> the data from the
>>>>>>       > engines."
>>>>>>       >
>>>>>>       > We will use GEM_CREATE_ENCRYPTED flag for secure buffer
>>>>>> allocation.
>>>>>>       >
>>>>>>       > Signed-off-by: Huang Rui <ray.huang@amd.com
>>>>>> <mailto:ray.huang@amd.com>>
>>>>>>       > Reviewed-by: Alex Deucher <alexander.deucher@amd.com
>>>>>> <mailto:alexander.deucher@amd.com>>
>>>>>>       > ---
>>>>>>       >  include/drm/amdgpu_drm.h | 5 +++++
>>>>>>       >  1 file changed, 5 insertions(+)
>>>>>>       >
>>>>>>       > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>>>>       > index 5c28aa7..1a95e37 100644
>>>>>>       > --- a/include/drm/amdgpu_drm.h
>>>>>>       > +++ b/include/drm/amdgpu_drm.h
>>>>>>       > @@ -141,6 +141,11 @@ extern "C" {
>>>>>>       >   * releasing the memory
>>>>>>       >   */
>>>>>>       >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE  (1 << 9)
>>>>>>       > +/* Flag that BO will be encrypted and that the TMZ bit
>>>>>> should be
>>>>>>       > + * set in the PTEs when mapping this buffer via GPUVM or
>>>>>>       > + * accessing it with various hw blocks
>>>>>>       > + */
>>>>>>       > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>>>>
>>>>>>       Style!
>>>>>>       TAB char?!
>>>>>>
>>>>>>       You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>>>>       Do NOT add/insert TAB chars instead of space to align colunmns!
>>>>>>       If when you press Tab key a tab is inserted, as opposed to the
>>>>>> line
>>>>>>       indented, then DO NOT use this editor.
>>>>>>       The Tab key should "indent according to mode" by inserting TAB
>>>>>> chars.
>>>>>>       If the line is already indented, as this one is, then it should
>>>>>> do nothing.
>>>>>>
>>>>>>
>>>>>> I disagree with this 100%. Tabs or spaces don't matter here from my
>>>>>> perspective. I also disagree with your language. It's overly impolite.
>>>>> But it's the coding style of Linux: leading tabs only. Try it with
>>>>> Emacs as described and given in
>>>>>
>>>>> linux/Documentation/process/coding-style.rst
>>>>>
>>>>> starting at line 589. And press the Tab key on an already indented
>>>>> line--nothing will happen. Linux has traditionally
>>>>> shunned from loose TAB chars in already indented lines: leading tabs
>>>>> only mode. In a proper code editor
>>>>> pressing the Tab key only indents according to buffer mode, it
>>>>> shouldn't insert a Tab char willy-nilly.
>>>>> People may set their tab stops differently for different tab
>>>>> positions and inserting a tab char may display
>>>>> incorrectly. The most portable way to align columns in an already
>>>>> indented-according-to-mode line, is
>>>>> using spaces. (Of course this doesn't matter when using spaces to
>>>>> indent, but Linux uses hard TAB chars
>>>>> to indent: linux/Documentation/process/coding-style.rst. (which also
>>>>> seem to be set to 8 chars))
>>>>>
>>>>> It's a code review, there is no "language".
>>>> Well the section you noted also suggest to either get rid of emacs or
>>>> change it to use some saner default values. We just got rid of emacs.
>> Yes, it says this, quote (for those who didn't open the file):
>>
>> --8<---------------------------------------------------------------------
>>
>> That's OK, we all do.  You've probably been told by your long-time Unix
>> user helper that ``GNU emacs`` automatically formats the C sources for
>> you, and you've noticed that yes, it does do that, but the defaults it
>> uses are less than desirable (in fact, they are worse than random
>> typing - an infinite number of monkeys typing into GNU emacs would never
>> make a good program).
>>
>> So, you can either get rid of GNU emacs, or change it to use saner
>> values.  To do the latter, you can stick the following in your .emacs file:
>>
>> --8<--------------------------------------------------------------------
>>
>>>> Regarding tabs after the initial indentation, I've just done a quick
>>>> grep and around 14% of all defines under include/ uses that so I would
>>>> say that this is perfectly fine.
>>> Fast typing with lazy eyes, that should read "around 71% of all defines".
>> Hmm, that's interesting. Is that in linux/include or amdgpu/include?
> 
> linux/include
> 
>>
>> I've been meaning to do my own extended regex to catch those, although
>> I'm using Emacs and pressing Tab key only indents and would not insert
>> a Tab char if already indented. (So applying this regex into the pre-commit
>> hook of all of my Git repos would never trigger.)
>>
>> I remember of olden days, circa 2000 when I first got involved with Linux,
>> LKML didn't like loose tabs. Also lead kernel developers are using Emacs,
>> so it's been my choice of editor since circa 1994 (switched from vi to Emacs
>> largely due to the influence of a graphics prof I had in my seniour year of uni,
>> and part due to LKML.)
> 
> Well I've been working with the Linux kernel since the mid 90ths and 
> never ever heard of that.

I see. Hmm, interesting. My experience differs.

Regardless, here is the question:

Is it then okay to embed hard TAB char anywhere in an already indented
line of code?

For instance:

	for (i = 0; i <\t10; i++) {

int table[][3] = {
	{ 2,\t3,      5 },
	{ 2,    4,\t6 },
	{ 1,\t1,\t2 },
};

Because it would render correct on an 8-tab stop configured editor.

Is this okay, and acceptable, according to the LKCS (linux/Documentation/process/coding-style.rst)?

Regards,
Luben

> 
> Christian.
> 
>>
>> Thanks for chiming in Christian!
>>
>> Regards,
>> Luben
>>
>>> Sorry,
>>> Christian.
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>> Regards,
>>>>> Luben
>>>>>
>>>>>> Marek
>>>>> _______________________________________________
>>>>> 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
> 

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Luben Tuikov]

On 2019-11-20 13:40, Christian König wrote:
> Am 20.11.19 um 18:50 schrieb Luben Tuikov:
>> On 2019-11-20 12:24, Christian König wrote:
>>> Am 20.11.19 um 18:16 schrieb Christian König:
>>>> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>>>>> On 2019-11-19 21:41, Marek Olšák wrote:
>>>>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com
>>>>>> <mailto:luben.tuikov@amd.com>> wrote:
>>>>>>
>>>>>>       On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>>>>       > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>>>>       >
>>>>>>       > To align the kernel uapi change from Alex:
>>>>>>       >
>>>>>>       > "Add a flag to the GEM_CREATE ioctl to create encrypted
>>>>>> buffers. Buffers with
>>>>>>       > this flag set will be created with the TMZ bit set in the
>>>>>> PTEs or engines
>>>>>>       > accessing them. This is required in order to properly access
>>>>>> the data from the
>>>>>>       > engines."
>>>>>>       >
>>>>>>       > We will use GEM_CREATE_ENCRYPTED flag for secure buffer
>>>>>> allocation.
>>>>>>       >
>>>>>>       > Signed-off-by: Huang Rui <ray.huang@amd.com
>>>>>> <mailto:ray.huang@amd.com>>
>>>>>>       > Reviewed-by: Alex Deucher <alexander.deucher@amd.com
>>>>>> <mailto:alexander.deucher@amd.com>>
>>>>>>       > ---
>>>>>>       >  include/drm/amdgpu_drm.h | 5 +++++
>>>>>>       >  1 file changed, 5 insertions(+)
>>>>>>       >
>>>>>>       > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>>>>       > index 5c28aa7..1a95e37 100644
>>>>>>       > --- a/include/drm/amdgpu_drm.h
>>>>>>       > +++ b/include/drm/amdgpu_drm.h
>>>>>>       > @@ -141,6 +141,11 @@ extern "C" {
>>>>>>       >   * releasing the memory
>>>>>>       >   */
>>>>>>       >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE  (1 << 9)
>>>>>>       > +/* Flag that BO will be encrypted and that the TMZ bit
>>>>>> should be
>>>>>>       > + * set in the PTEs when mapping this buffer via GPUVM or
>>>>>>       > + * accessing it with various hw blocks
>>>>>>       > + */
>>>>>>       > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>>>>
>>>>>>       Style!
>>>>>>       TAB char?!
>>>>>>
>>>>>>       You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>>>>       Do NOT add/insert TAB chars instead of space to align colunmns!
>>>>>>       If when you press Tab key a tab is inserted, as opposed to the
>>>>>> line
>>>>>>       indented, then DO NOT use this editor.
>>>>>>       The Tab key should "indent according to mode" by inserting TAB
>>>>>> chars.
>>>>>>       If the line is already indented, as this one is, then it should
>>>>>> do nothing.
>>>>>>
>>>>>>
>>>>>> I disagree with this 100%. Tabs or spaces don't matter here from my
>>>>>> perspective. I also disagree with your language. It's overly impolite.
>>>>> But it's the coding style of Linux: leading tabs only. Try it with
>>>>> Emacs as described and given in
>>>>>
>>>>> linux/Documentation/process/coding-style.rst
>>>>>
>>>>> starting at line 589. And press the Tab key on an already indented
>>>>> line--nothing will happen. Linux has traditionally
>>>>> shunned from loose TAB chars in already indented lines: leading tabs
>>>>> only mode. In a proper code editor
>>>>> pressing the Tab key only indents according to buffer mode, it
>>>>> shouldn't insert a Tab char willy-nilly.
>>>>> People may set their tab stops differently for different tab
>>>>> positions and inserting a tab char may display
>>>>> incorrectly. The most portable way to align columns in an already
>>>>> indented-according-to-mode line, is
>>>>> using spaces. (Of course this doesn't matter when using spaces to
>>>>> indent, but Linux uses hard TAB chars
>>>>> to indent: linux/Documentation/process/coding-style.rst. (which also
>>>>> seem to be set to 8 chars))
>>>>>
>>>>> It's a code review, there is no "language".
>>>> Well the section you noted also suggest to either get rid of emacs or
>>>> change it to use some saner default values. We just got rid of emacs.
>> Yes, it says this, quote (for those who didn't open the file):
>>
>> --8<---------------------------------------------------------------------
>>
>> That's OK, we all do.  You've probably been told by your long-time Unix
>> user helper that ``GNU emacs`` automatically formats the C sources for
>> you, and you've noticed that yes, it does do that, but the defaults it
>> uses are less than desirable (in fact, they are worse than random
>> typing - an infinite number of monkeys typing into GNU emacs would never
>> make a good program).
>>
>> So, you can either get rid of GNU emacs, or change it to use saner
>> values.  To do the latter, you can stick the following in your .emacs file:
>>
>> --8<--------------------------------------------------------------------
>>
>>>> Regarding tabs after the initial indentation, I've just done a quick
>>>> grep and around 14% of all defines under include/ uses that so I would
>>>> say that this is perfectly fine.
>>> Fast typing with lazy eyes, that should read "around 71% of all defines".
>> Hmm, that's interesting. Is that in linux/include or amdgpu/include?
> 
> linux/include
> 
>>
>> I've been meaning to do my own extended regex to catch those, although
>> I'm using Emacs and pressing Tab key only indents and would not insert
>> a Tab char if already indented. (So applying this regex into the pre-commit
>> hook of all of my Git repos would never trigger.)
>>
>> I remember of olden days, circa 2000 when I first got involved with Linux,
>> LKML didn't like loose tabs. Also lead kernel developers are using Emacs,
>> so it's been my choice of editor since circa 1994 (switched from vi to Emacs
>> largely due to the influence of a graphics prof I had in my seniour year of uni,
>> and part due to LKML.)
> 
> Well I've been working with the Linux kernel since the mid 90ths and 
> never ever heard of that.

I see. Hmm, interesting. My experience differs.

Regardless, here is the question:

Is it then okay to embed hard TAB char anywhere in an already indented
line of code?

For instance:

	for (i = 0; i <\t10; i++) {

int table[][3] = {
	{ 2,\t3,      5 },
	{ 2,    4,\t6 },
	{ 1,\t1,\t2 },
};

Because it would render correct on an 8-tab stop configured editor.

Is this okay, and acceptable, according to the LKCS (linux/Documentation/process/coding-style.rst)?

Regards,
Luben

> 
> Christian.
> 
>>
>> Thanks for chiming in Christian!
>>
>> Regards,
>> Luben
>>
>>> Sorry,
>>> Christian.
>>>
>>>> Regards,
>>>> Christian.
>>>>
>>>>> Regards,
>>>>> Luben
>>>>>
>>>>>> Marek
>>>>> _______________________________________________
>>>>> 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
> 

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Christian König]

Am 20.11.19 um 20:08 schrieb Luben Tuikov:
> On 2019-11-20 13:40, Christian König wrote:
>> Am 20.11.19 um 18:50 schrieb Luben Tuikov:
>>> On 2019-11-20 12:24, Christian König wrote:
>>>> Am 20.11.19 um 18:16 schrieb Christian König:
>>>>> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>>>>>> On 2019-11-19 21:41, Marek Olšák wrote:
>>>>>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com
>>>>>>> <mailto:luben.tuikov@amd.com>> wrote:
>>>>>>>
>>>>>>>        On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>>>>>        > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>>>>>        >
>>>>>>>        > To align the kernel uapi change from Alex:
>>>>>>>        >
>>>>>>>        > "Add a flag to the GEM_CREATE ioctl to create encrypted
>>>>>>> buffers. Buffers with
>>>>>>>        > this flag set will be created with the TMZ bit set in the
>>>>>>> PTEs or engines
>>>>>>>        > accessing them. This is required in order to properly access
>>>>>>> the data from the
>>>>>>>        > engines."
>>>>>>>        >
>>>>>>>        > We will use GEM_CREATE_ENCRYPTED flag for secure buffer
>>>>>>> allocation.
>>>>>>>        >
>>>>>>>        > Signed-off-by: Huang Rui <ray.huang@amd.com
>>>>>>> <mailto:ray.huang@amd.com>>
>>>>>>>        > Reviewed-by: Alex Deucher <alexander.deucher@amd.com
>>>>>>> <mailto:alexander.deucher@amd.com>>
>>>>>>>        > ---
>>>>>>>        >  include/drm/amdgpu_drm.h | 5 +++++
>>>>>>>        >  1 file changed, 5 insertions(+)
>>>>>>>        >
>>>>>>>        > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>>>>>        > index 5c28aa7..1a95e37 100644
>>>>>>>        > --- a/include/drm/amdgpu_drm.h
>>>>>>>        > +++ b/include/drm/amdgpu_drm.h
>>>>>>>        > @@ -141,6 +141,11 @@ extern "C" {
>>>>>>>        >   * releasing the memory
>>>>>>>        >   */
>>>>>>>        >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE  (1 << 9)
>>>>>>>        > +/* Flag that BO will be encrypted and that the TMZ bit
>>>>>>> should be
>>>>>>>        > + * set in the PTEs when mapping this buffer via GPUVM or
>>>>>>>        > + * accessing it with various hw blocks
>>>>>>>        > + */
>>>>>>>        > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>>>>>
>>>>>>>        Style!
>>>>>>>        TAB char?!
>>>>>>>
>>>>>>>        You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>>>>>        Do NOT add/insert TAB chars instead of space to align colunmns!
>>>>>>>        If when you press Tab key a tab is inserted, as opposed to the
>>>>>>> line
>>>>>>>        indented, then DO NOT use this editor.
>>>>>>>        The Tab key should "indent according to mode" by inserting TAB
>>>>>>> chars.
>>>>>>>        If the line is already indented, as this one is, then it should
>>>>>>> do nothing.
>>>>>>>
>>>>>>>
>>>>>>> I disagree with this 100%. Tabs or spaces don't matter here from my
>>>>>>> perspective. I also disagree with your language. It's overly impolite.
>>>>>> But it's the coding style of Linux: leading tabs only. Try it with
>>>>>> Emacs as described and given in
>>>>>>
>>>>>> linux/Documentation/process/coding-style.rst
>>>>>>
>>>>>> starting at line 589. And press the Tab key on an already indented
>>>>>> line--nothing will happen. Linux has traditionally
>>>>>> shunned from loose TAB chars in already indented lines: leading tabs
>>>>>> only mode. In a proper code editor
>>>>>> pressing the Tab key only indents according to buffer mode, it
>>>>>> shouldn't insert a Tab char willy-nilly.
>>>>>> People may set their tab stops differently for different tab
>>>>>> positions and inserting a tab char may display
>>>>>> incorrectly. The most portable way to align columns in an already
>>>>>> indented-according-to-mode line, is
>>>>>> using spaces. (Of course this doesn't matter when using spaces to
>>>>>> indent, but Linux uses hard TAB chars
>>>>>> to indent: linux/Documentation/process/coding-style.rst. (which also
>>>>>> seem to be set to 8 chars))
>>>>>>
>>>>>> It's a code review, there is no "language".
>>>>> Well the section you noted also suggest to either get rid of emacs or
>>>>> change it to use some saner default values. We just got rid of emacs.
>>> Yes, it says this, quote (for those who didn't open the file):
>>>
>>> --8<---------------------------------------------------------------------
>>>
>>> That's OK, we all do.  You've probably been told by your long-time Unix
>>> user helper that ``GNU emacs`` automatically formats the C sources for
>>> you, and you've noticed that yes, it does do that, but the defaults it
>>> uses are less than desirable (in fact, they are worse than random
>>> typing - an infinite number of monkeys typing into GNU emacs would never
>>> make a good program).
>>>
>>> So, you can either get rid of GNU emacs, or change it to use saner
>>> values.  To do the latter, you can stick the following in your .emacs file:
>>>
>>> --8<--------------------------------------------------------------------
>>>
>>>>> Regarding tabs after the initial indentation, I've just done a quick
>>>>> grep and around 14% of all defines under include/ uses that so I would
>>>>> say that this is perfectly fine.
>>>> Fast typing with lazy eyes, that should read "around 71% of all defines".
>>> Hmm, that's interesting. Is that in linux/include or amdgpu/include?
>> linux/include
>>
>>> I've been meaning to do my own extended regex to catch those, although
>>> I'm using Emacs and pressing Tab key only indents and would not insert
>>> a Tab char if already indented. (So applying this regex into the pre-commit
>>> hook of all of my Git repos would never trigger.)
>>>
>>> I remember of olden days, circa 2000 when I first got involved with Linux,
>>> LKML didn't like loose tabs. Also lead kernel developers are using Emacs,
>>> so it's been my choice of editor since circa 1994 (switched from vi to Emacs
>>> largely due to the influence of a graphics prof I had in my seniour year of uni,
>>> and part due to LKML.)
>> Well I've been working with the Linux kernel since the mid 90ths and
>> never ever heard of that.
> I see. Hmm, interesting. My experience differs.
>
> Regardless, here is the question:
>
> Is it then okay to embed hard TAB char anywhere in an already indented
> line of code?
>
> For instance:
>
> 	for (i = 0; i <\t10; i++) {
>
> int table[][3] = {
> 	{ 2,\t3,      5 },
> 	{ 2,    4,\t6 },
> 	{ 1,\t1,\t2 },
> };
>
> Because it would render correct on an 8-tab stop configured editor.

At least to those examples I would say no cause they use tab and spaces 
inconsistently.

> Is this okay, and acceptable, according to the LKCS (linux/Documentation/process/coding-style.rst)?

As long as you indent consistently I think it is ok. For example most 
defines seem to look like the pattern "#define NAME\t+VALUE".

Regards,
Christian.

>
> Regards,
> Luben
>
>> Christian.
>>
>>> Thanks for chiming in Christian!
>>>
>>> Regards,
>>> Luben
>>>
>>>> Sorry,
>>>> Christian.
>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>> Regards,
>>>>>> Luben
>>>>>>
>>>>>>> Marek
>>>>>> _______________________________________________
>>>>>> 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

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

Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers

[Christian König]

Am 20.11.19 um 20:08 schrieb Luben Tuikov:
> On 2019-11-20 13:40, Christian König wrote:
>> Am 20.11.19 um 18:50 schrieb Luben Tuikov:
>>> On 2019-11-20 12:24, Christian König wrote:
>>>> Am 20.11.19 um 18:16 schrieb Christian König:
>>>>> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>>>>>> On 2019-11-19 21:41, Marek Olšák wrote:
>>>>>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <luben.tuikov@amd.com
>>>>>>> <mailto:luben.tuikov@amd.com>> wrote:
>>>>>>>
>>>>>>>        On 2019-11-14 10:34 p.m., Aaron Liu wrote:
>>>>>>>        > From: Huang Rui <ray.huang@amd.com <mailto:ray.huang@amd.com>>
>>>>>>>        >
>>>>>>>        > To align the kernel uapi change from Alex:
>>>>>>>        >
>>>>>>>        > "Add a flag to the GEM_CREATE ioctl to create encrypted
>>>>>>> buffers. Buffers with
>>>>>>>        > this flag set will be created with the TMZ bit set in the
>>>>>>> PTEs or engines
>>>>>>>        > accessing them. This is required in order to properly access
>>>>>>> the data from the
>>>>>>>        > engines."
>>>>>>>        >
>>>>>>>        > We will use GEM_CREATE_ENCRYPTED flag for secure buffer
>>>>>>> allocation.
>>>>>>>        >
>>>>>>>        > Signed-off-by: Huang Rui <ray.huang@amd.com
>>>>>>> <mailto:ray.huang@amd.com>>
>>>>>>>        > Reviewed-by: Alex Deucher <alexander.deucher@amd.com
>>>>>>> <mailto:alexander.deucher@amd.com>>
>>>>>>>        > ---
>>>>>>>        >  include/drm/amdgpu_drm.h | 5 +++++
>>>>>>>        >  1 file changed, 5 insertions(+)
>>>>>>>        >
>>>>>>>        > diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
>>>>>>>        > index 5c28aa7..1a95e37 100644
>>>>>>>        > --- a/include/drm/amdgpu_drm.h
>>>>>>>        > +++ b/include/drm/amdgpu_drm.h
>>>>>>>        > @@ -141,6 +141,11 @@ extern "C" {
>>>>>>>        >   * releasing the memory
>>>>>>>        >   */
>>>>>>>        >  #define AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE  (1 << 9)
>>>>>>>        > +/* Flag that BO will be encrypted and that the TMZ bit
>>>>>>> should be
>>>>>>>        > + * set in the PTEs when mapping this buffer via GPUVM or
>>>>>>>        > + * accessing it with various hw blocks
>>>>>>>        > + */
>>>>>>>        > +#define AMDGPU_GEM_CREATE_ENCRYPTED          (1 << 10)
>>>>>>>
>>>>>>>        Style!
>>>>>>>        TAB char?!
>>>>>>>
>>>>>>>        You have a TAB char between ".._ENCRYPTED" and "(1 << 10)"
>>>>>>>        Do NOT add/insert TAB chars instead of space to align colunmns!
>>>>>>>        If when you press Tab key a tab is inserted, as opposed to the
>>>>>>> line
>>>>>>>        indented, then DO NOT use this editor.
>>>>>>>        The Tab key should "indent according to mode" by inserting TAB
>>>>>>> chars.
>>>>>>>        If the line is already indented, as this one is, then it should
>>>>>>> do nothing.
>>>>>>>
>>>>>>>
>>>>>>> I disagree with this 100%. Tabs or spaces don't matter here from my
>>>>>>> perspective. I also disagree with your language. It's overly impolite.
>>>>>> But it's the coding style of Linux: leading tabs only. Try it with
>>>>>> Emacs as described and given in
>>>>>>
>>>>>> linux/Documentation/process/coding-style.rst
>>>>>>
>>>>>> starting at line 589. And press the Tab key on an already indented
>>>>>> line--nothing will happen. Linux has traditionally
>>>>>> shunned from loose TAB chars in already indented lines: leading tabs
>>>>>> only mode. In a proper code editor
>>>>>> pressing the Tab key only indents according to buffer mode, it
>>>>>> shouldn't insert a Tab char willy-nilly.
>>>>>> People may set their tab stops differently for different tab
>>>>>> positions and inserting a tab char may display
>>>>>> incorrectly. The most portable way to align columns in an already
>>>>>> indented-according-to-mode line, is
>>>>>> using spaces. (Of course this doesn't matter when using spaces to
>>>>>> indent, but Linux uses hard TAB chars
>>>>>> to indent: linux/Documentation/process/coding-style.rst. (which also
>>>>>> seem to be set to 8 chars))
>>>>>>
>>>>>> It's a code review, there is no "language".
>>>>> Well the section you noted also suggest to either get rid of emacs or
>>>>> change it to use some saner default values. We just got rid of emacs.
>>> Yes, it says this, quote (for those who didn't open the file):
>>>
>>> --8<---------------------------------------------------------------------
>>>
>>> That's OK, we all do.  You've probably been told by your long-time Unix
>>> user helper that ``GNU emacs`` automatically formats the C sources for
>>> you, and you've noticed that yes, it does do that, but the defaults it
>>> uses are less than desirable (in fact, they are worse than random
>>> typing - an infinite number of monkeys typing into GNU emacs would never
>>> make a good program).
>>>
>>> So, you can either get rid of GNU emacs, or change it to use saner
>>> values.  To do the latter, you can stick the following in your .emacs file:
>>>
>>> --8<--------------------------------------------------------------------
>>>
>>>>> Regarding tabs after the initial indentation, I've just done a quick
>>>>> grep and around 14% of all defines under include/ uses that so I would
>>>>> say that this is perfectly fine.
>>>> Fast typing with lazy eyes, that should read "around 71% of all defines".
>>> Hmm, that's interesting. Is that in linux/include or amdgpu/include?
>> linux/include
>>
>>> I've been meaning to do my own extended regex to catch those, although
>>> I'm using Emacs and pressing Tab key only indents and would not insert
>>> a Tab char if already indented. (So applying this regex into the pre-commit
>>> hook of all of my Git repos would never trigger.)
>>>
>>> I remember of olden days, circa 2000 when I first got involved with Linux,
>>> LKML didn't like loose tabs. Also lead kernel developers are using Emacs,
>>> so it's been my choice of editor since circa 1994 (switched from vi to Emacs
>>> largely due to the influence of a graphics prof I had in my seniour year of uni,
>>> and part due to LKML.)
>> Well I've been working with the Linux kernel since the mid 90ths and
>> never ever heard of that.
> I see. Hmm, interesting. My experience differs.
>
> Regardless, here is the question:
>
> Is it then okay to embed hard TAB char anywhere in an already indented
> line of code?
>
> For instance:
>
> 	for (i = 0; i <\t10; i++) {
>
> int table[][3] = {
> 	{ 2,\t3,      5 },
> 	{ 2,    4,\t6 },
> 	{ 1,\t1,\t2 },
> };
>
> Because it would render correct on an 8-tab stop configured editor.

At least to those examples I would say no cause they use tab and spaces 
inconsistently.

> Is this okay, and acceptable, according to the LKCS (linux/Documentation/process/coding-style.rst)?

As long as you indent consistently I think it is ok. For example most 
defines seem to look like the pattern "#define NAME\t+VALUE".

Regards,
Christian.

>
> Regards,
> Luben
>
>> Christian.
>>
>>> Thanks for chiming in Christian!
>>>
>>> Regards,
>>> Luben
>>>
>>>> Sorry,
>>>> Christian.
>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>> Regards,
>>>>>> Luben
>>>>>>
>>>>>>> Marek
>>>>>> _______________________________________________
>>>>>> 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

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

Re: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:50AM +0800, Liu, Aaron wrote:
> In kernel, cs->in.flags is used for TMZ. Hence libdrm should transfer 
> the flag to kernel.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
> ---
>  amdgpu/amdgpu.h    | 4 +++-
>  amdgpu/amdgpu_cs.c | 4 ++++
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h index f45f9f7..aee3f3d 
> 100644
> --- a/amdgpu/amdgpu.h
> +++ b/amdgpu/amdgpu.h
> @@ -342,7 +342,9 @@ struct amdgpu_cs_fence_info {
>   * \sa amdgpu_cs_submit()
>  */
>  struct amdgpu_cs_request {
> -	/** Specify flags with additional information */
> +	/** Specify flags with additional information
> +	 * 0-normal, 1-tmz
> +	 */
>  	uint64_t flags;
>  
>  	/** Specify HW IP block type to which to send the IB. */ diff --git 
> a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c index 437c4a4..6f70771 
> 100644
> --- a/amdgpu/amdgpu_cs.c
> +++ b/amdgpu/amdgpu_cs.c
> @@ -254,6 +254,10 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle context,
>  	memset(&cs, 0, sizeof(cs));
>  	cs.in.chunks = (uint64_t)(uintptr_t)chunk_array;
>  	cs.in.ctx_id = context->id;
> +	/* in kernel, _pad is used as flags
> +	 * #define AMDGPU_CS_FLAGS_SECURE          (1 << 0)
> +	 */
> +	cs.in._pad = (uint32_t)ibs_request->flags;

_pad is not good here. Because it's used to pass the flags to input param.

It's better to rename "_pad" in drm_amdgpu_cs_in as "flags" here.

Thanks,
Ray

>  	if (ibs_request->resources)
>  		cs.in.bo_list_handle = ibs_request->resources->handle;
>  	cs.in.num_chunks = ibs_request->number_of_ibs;
> --
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 07/12] amdgpu: using IB flags for TMZ or non-TMZ

[Huang, Ray]

On Fri, Nov 15, 2019 at 11:34:50AM +0800, Liu, Aaron wrote:
> In kernel, cs->in.flags is used for TMZ. Hence libdrm should transfer 
> the flag to kernel.
> 
> Signed-off-by: Aaron Liu <aaron.liu@amd.com>
> ---
>  amdgpu/amdgpu.h    | 4 +++-
>  amdgpu/amdgpu_cs.c | 4 ++++
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h index f45f9f7..aee3f3d 
> 100644
> --- a/amdgpu/amdgpu.h
> +++ b/amdgpu/amdgpu.h
> @@ -342,7 +342,9 @@ struct amdgpu_cs_fence_info {
>   * \sa amdgpu_cs_submit()
>  */
>  struct amdgpu_cs_request {
> -	/** Specify flags with additional information */
> +	/** Specify flags with additional information
> +	 * 0-normal, 1-tmz
> +	 */
>  	uint64_t flags;
>  
>  	/** Specify HW IP block type to which to send the IB. */ diff --git 
> a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c index 437c4a4..6f70771 
> 100644
> --- a/amdgpu/amdgpu_cs.c
> +++ b/amdgpu/amdgpu_cs.c
> @@ -254,6 +254,10 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle context,
>  	memset(&cs, 0, sizeof(cs));
>  	cs.in.chunks = (uint64_t)(uintptr_t)chunk_array;
>  	cs.in.ctx_id = context->id;
> +	/* in kernel, _pad is used as flags
> +	 * #define AMDGPU_CS_FLAGS_SECURE          (1 << 0)
> +	 */
> +	cs.in._pad = (uint32_t)ibs_request->flags;

_pad is not good here. Because it's used to pass the flags to input param.

It's better to rename "_pad" in drm_amdgpu_cs_in as "flags" here.

Thanks,
Ray

>  	if (ibs_request->resources)
>  		cs.in.bo_list_handle = ibs_request->resources->handle;
>  	cs.in.num_chunks = ibs_request->number_of_ibs;
> --
> 2.7.4
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx