Re: [PATCH 1/1] drm/amdgpu: Fix compute VM BO params after rebase

[zhoucm1]

On 2018年09月06日 08:28, Felix Kuehling wrote:

The intent of two commits was lost in the last rebase:

810955b drm/amdgpu: Fix acquiring VM on large-BAR systems
b5d21aa drm/amdgpu: Don't use shadow BO for compute context

This commit restores the original behaviour:
* Don't set AMDGPU_GEM_CREATE_NO_CPU_ACCESS for page directories
   to allow them to be reused for compute VMs
* Don't create shadow BOs for page tables in compute VMs

Signed-off-by: Felix Kuehling 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index ea5e277..5e7a3de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -577,10 +577,13 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device *adev,
   *
   * @adev: amdgpu_device pointer
   * @vm: requesting vm
+ * @level: level in the page table hierarchy
+ * @no_shadow: disable creation of shadow BO for this VM
   * @bp: resulting BO allocation parameters
   */
  static void amdgpu_vm_bo_param(struct amdgpu_device *adev, struct amdgpu_vm 
*vm,
-  int level, struct amdgpu_bo_param *bp)
+  int level, bool no_shadow,
+  struct amdgpu_bo_param *bp)

How about adding no_shadow to bp? Which also can consider to be parm of bo.

Regards,
David Zhou

  {
memset(bp, 0, sizeof(*bp));
  
@@ -595,9 +598,8 @@ static void amdgpu_vm_bo_param(struct amdgpu_device *adev, struct amdgpu_vm *vm,

AMDGPU_GEM_CREATE_CPU_GTT_USWC;
if (vm->use_cpu_for_update)
bp->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
-   else
-   bp->flags |= AMDGPU_GEM_CREATE_SHADOW |
-   AMDGPU_GEM_CREATE_NO_CPU_ACCESS;
+   else if (!no_shadow)
+   bp->flags |= AMDGPU_GEM_CREATE_SHADOW;
bp->type = ttm_bo_type_kernel;
if (vm->root.base.bo)
bp->resv = vm->root.base.bo->tbo.resv;
@@ -626,6 +628,7 @@ static int amdgpu_vm_alloc_levels(struct amdgpu_device 
*adev,
  unsigned level, bool ats)
  {
unsigned shift = amdgpu_vm_level_shift(adev, level);
+   bool no_shadow = !vm->root.base.bo->shadow;
struct amdgpu_bo_param bp;
unsigned pt_idx, from, to;
int r;
@@ -650,7 +653,7 @@ static int amdgpu_vm_alloc_levels(struct amdgpu_device 
*adev,
saddr = saddr & ((1 << shift) - 1);
eaddr = eaddr & ((1 << shift) - 1);
  
-	amdgpu_vm_bo_param(adev, vm, level, );

+   amdgpu_vm_bo_param(adev, vm, level, no_shadow, );
  
  	/* walk over the address space and allocate the page tables */

for (pt_idx = from; pt_idx <= to; ++pt_idx) {
@@ -2709,6 +2712,7 @@ void amdgpu_vm_adjust_size(struct amdgpu_device *adev, 
uint32_t min_vm_size,
  int amdgpu_vm_init(struct amdgpu_device *adev, struct amdgpu_vm *vm,
   int vm_context, unsigned int pasid)
  {
+   bool no_shadow = (vm_context == AMDGPU_VM_CONTEXT_COMPUTE);
struct amdgpu_bo_param bp;
struct amdgpu_bo *root;
int r, i;
@@ -2748,7 +2752,8 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm,
  "CPU update of VM recommended only for large BAR system\n");
vm->last_update = NULL;
  
-	amdgpu_vm_bo_param(adev, vm, adev->vm_manager.root_level, );

+   amdgpu_vm_bo_param(adev, vm, adev->vm_manager.root_level, no_shadow,
+  );
r = amdgpu_bo_create(adev, , );
if (r)
goto error_free_sched_entity;


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

Re: [PATCH 1/1] drm/amdgpu: Fix compute VM BO params after rebase

[Zhang, Jerry (Junwei)]

On 09/06/2018 08:28 AM, Felix Kuehling wrote:

The intent of two commits was lost in the last rebase:

810955b drm/amdgpu: Fix acquiring VM on large-BAR systems
b5d21aa drm/amdgpu: Don't use shadow BO for compute context

This commit restores the original behaviour:
* Don't set AMDGPU_GEM_CREATE_NO_CPU_ACCESS for page directories
   to allow them to be reused for compute VMs
* Don't create shadow BOs for page tables in compute VMs

Signed-off-by: Felix Kuehling 


Personally making no_shadow -> shadow looks more simple.
anyway, that patches restoring what it's missing.

Acked-by: Junwei Zhang 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index ea5e277..5e7a3de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -577,10 +577,13 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device *adev,
   *
   * @adev: amdgpu_device pointer
   * @vm: requesting vm
+ * @level: level in the page table hierarchy
+ * @no_shadow: disable creation of shadow BO for this VM
   * @bp: resulting BO allocation parameters
   */
  static void amdgpu_vm_bo_param(struct amdgpu_device *adev, struct amdgpu_vm 
*vm,
-  int level, struct amdgpu_bo_param *bp)
+  int level, bool no_shadow,
+  struct amdgpu_bo_param *bp)
  {
memset(bp, 0, sizeof(*bp));

@@ -595,9 +598,8 @@ static void amdgpu_vm_bo_param(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
AMDGPU_GEM_CREATE_CPU_GTT_USWC;
if (vm->use_cpu_for_update)
bp->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
-   else
-   bp->flags |= AMDGPU_GEM_CREATE_SHADOW |
-   AMDGPU_GEM_CREATE_NO_CPU_ACCESS;
+   else if (!no_shadow)
+   bp->flags |= AMDGPU_GEM_CREATE_SHADOW;
bp->type = ttm_bo_type_kernel;
if (vm->root.base.bo)
bp->resv = vm->root.base.bo->tbo.resv;
@@ -626,6 +628,7 @@ static int amdgpu_vm_alloc_levels(struct amdgpu_device 
*adev,
  unsigned level, bool ats)
  {
unsigned shift = amdgpu_vm_level_shift(adev, level);
+   bool no_shadow = !vm->root.base.bo->shadow;
struct amdgpu_bo_param bp;
unsigned pt_idx, from, to;
int r;
@@ -650,7 +653,7 @@ static int amdgpu_vm_alloc_levels(struct amdgpu_device 
*adev,
saddr = saddr & ((1 << shift) - 1);
eaddr = eaddr & ((1 << shift) - 1);

-   amdgpu_vm_bo_param(adev, vm, level, );
+   amdgpu_vm_bo_param(adev, vm, level, no_shadow, );

/* walk over the address space and allocate the page tables */
for (pt_idx = from; pt_idx <= to; ++pt_idx) {
@@ -2709,6 +2712,7 @@ void amdgpu_vm_adjust_size(struct amdgpu_device *adev, 
uint32_t min_vm_size,
  int amdgpu_vm_init(struct amdgpu_device *adev, struct amdgpu_vm *vm,
   int vm_context, unsigned int pasid)
  {
+   bool no_shadow = (vm_context == AMDGPU_VM_CONTEXT_COMPUTE);
struct amdgpu_bo_param bp;
struct amdgpu_bo *root;
int r, i;
@@ -2748,7 +2752,8 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm,
  "CPU update of VM recommended only for large BAR system\n");
vm->last_update = NULL;

-   amdgpu_vm_bo_param(adev, vm, adev->vm_manager.root_level, );
+   amdgpu_vm_bo_param(adev, vm, adev->vm_manager.root_level, no_shadow,
+  );
r = amdgpu_bo_create(adev, , );
if (r)
goto error_free_sched_entity;


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

[PATCH 1/1] drm/amdgpu: Fix compute VM BO params after rebase

[Felix Kuehling]

The intent of two commits was lost in the last rebase:

810955b drm/amdgpu: Fix acquiring VM on large-BAR systems
b5d21aa drm/amdgpu: Don't use shadow BO for compute context

This commit restores the original behaviour:
* Don't set AMDGPU_GEM_CREATE_NO_CPU_ACCESS for page directories
  to allow them to be reused for compute VMs
* Don't create shadow BOs for page tables in compute VMs

Signed-off-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index ea5e277..5e7a3de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -577,10 +577,13 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device *adev,
  *
  * @adev: amdgpu_device pointer
  * @vm: requesting vm
+ * @level: level in the page table hierarchy
+ * @no_shadow: disable creation of shadow BO for this VM
  * @bp: resulting BO allocation parameters
  */
 static void amdgpu_vm_bo_param(struct amdgpu_device *adev, struct amdgpu_vm 
*vm,
-  int level, struct amdgpu_bo_param *bp)
+  int level, bool no_shadow,
+  struct amdgpu_bo_param *bp)
 {
memset(bp, 0, sizeof(*bp));
 
@@ -595,9 +598,8 @@ static void amdgpu_vm_bo_param(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
AMDGPU_GEM_CREATE_CPU_GTT_USWC;
if (vm->use_cpu_for_update)
bp->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
-   else
-   bp->flags |= AMDGPU_GEM_CREATE_SHADOW |
-   AMDGPU_GEM_CREATE_NO_CPU_ACCESS;
+   else if (!no_shadow)
+   bp->flags |= AMDGPU_GEM_CREATE_SHADOW;
bp->type = ttm_bo_type_kernel;
if (vm->root.base.bo)
bp->resv = vm->root.base.bo->tbo.resv;
@@ -626,6 +628,7 @@ static int amdgpu_vm_alloc_levels(struct amdgpu_device 
*adev,
  unsigned level, bool ats)
 {
unsigned shift = amdgpu_vm_level_shift(adev, level);
+   bool no_shadow = !vm->root.base.bo->shadow;
struct amdgpu_bo_param bp;
unsigned pt_idx, from, to;
int r;
@@ -650,7 +653,7 @@ static int amdgpu_vm_alloc_levels(struct amdgpu_device 
*adev,
saddr = saddr & ((1 << shift) - 1);
eaddr = eaddr & ((1 << shift) - 1);
 
-   amdgpu_vm_bo_param(adev, vm, level, );
+   amdgpu_vm_bo_param(adev, vm, level, no_shadow, );
 
/* walk over the address space and allocate the page tables */
for (pt_idx = from; pt_idx <= to; ++pt_idx) {
@@ -2709,6 +2712,7 @@ void amdgpu_vm_adjust_size(struct amdgpu_device *adev, 
uint32_t min_vm_size,
 int amdgpu_vm_init(struct amdgpu_device *adev, struct amdgpu_vm *vm,
   int vm_context, unsigned int pasid)
 {
+   bool no_shadow = (vm_context == AMDGPU_VM_CONTEXT_COMPUTE);
struct amdgpu_bo_param bp;
struct amdgpu_bo *root;
int r, i;
@@ -2748,7 +2752,8 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm,
  "CPU update of VM recommended only for large BAR system\n");
vm->last_update = NULL;
 
-   amdgpu_vm_bo_param(adev, vm, adev->vm_manager.root_level, );
+   amdgpu_vm_bo_param(adev, vm, adev->vm_manager.root_level, no_shadow,
+  );
r = amdgpu_bo_create(adev, , );
if (r)
goto error_free_sched_entity;
-- 
2.7.4

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

[PATCH xf86-video-ati] Fix uninitialized use of local variable pitch in radeon_setup_kernel_mem

[Michel Dänzer]

From: Michel Dänzer 

Fixes server reset.

Pointed out by clang:

../../src/radeon_kms.c:2721:9: warning: variable 'pitch' is used uninitialized 
whenever 'if' condition is false [-Wsometimes-uninitialized]
if (!info->front_buffer) {
^~~
../../src/radeon_kms.c:2765:27: note: uninitialized use occurs here
pScrn->displayWidth = pitch / cpp;
  ^
../../src/radeon_kms.c:2721:5: note: remove the 'if' if its condition is always 
true
if (!info->front_buffer) {
^
../../src/radeon_kms.c:2680:14: note: initialize the variable 'pitch' to 
silence this warning
int pitch;
 ^
  = 0

Signed-off-by: Michel Dänzer 
---
 src/radeon_kms.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index a24776811..ae69f3353 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -2760,10 +2760,11 @@ static Bool radeon_setup_kernel_mem(ScreenPtr pScreen)
if (tiling_flags)
radeon_bo_set_tiling(info->front_buffer->bo.radeon, 
tiling_flags, pitch);
}
-}
 
-pScrn->displayWidth = pitch / cpp;
+   pScrn->displayWidth = pitch / cpp;
+}
 
+pitch = pScrn->displayWidth * cpp;
 xf86DrvMsg(pScrn->scrnIndex, X_INFO, "Front buffer size: %dK\n",
   pitch * pScrn->virtualY / 1024);
 radeon_kms_update_vram_limit(pScrn, pitch * pScrn->virtualY);
-- 
2.19.0.rc1

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

[PATCH 13/13] drm/amdkfd: Generate xGMI direct iolink

[shaoyunl]

From: Shaoyun Liu 

Generate xGMI iolink for upper level usage

Change-Id: I37bc29fee45cb10d1da849956055c59d823f6f5d
Signed-off-by: Shaoyun Liu 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 78 ++-
 1 file changed, 68 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index ee49960..130db4d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -346,7 +346,7 @@ static int kfd_parse_subtype_iolink(struct 
crat_subtype_iolink *iolink,
struct list_head *device_list)
 {
struct kfd_iolink_properties *props = NULL, *props2;
-   struct kfd_topology_device *dev, *cpu_dev;
+   struct kfd_topology_device *dev, *to_dev;
uint32_t id_from;
uint32_t id_to;
 
@@ -369,6 +369,8 @@ static int kfd_parse_subtype_iolink(struct 
crat_subtype_iolink *iolink,
 
if (props->iolink_type == CRAT_IOLINK_TYPE_PCIEXPRESS)
props->weight = 20;
+   else if (props->iolink_type == CRAT_IOLINK_TYPE_XGMI)
+   props->weight = 15;
else
props->weight = node_distance(id_from, id_to);
 
@@ -390,19 +392,22 @@ static int kfd_parse_subtype_iolink(struct 
crat_subtype_iolink *iolink,
 * links are not built at that time. If a PCIe type is discovered, it
 * means a GPU is detected and we are adding GPU->CPU to the topology.
 * At this time, also add the corresponded CPU->GPU link.
+* For xGMI, we only added the link with one direction in the crat
+* table, add corresponded reversed direction link now.
 */
-   if (props && props->iolink_type == CRAT_IOLINK_TYPE_PCIEXPRESS) {
-   cpu_dev = kfd_topology_device_by_proximity_domain(id_to);
-   if (!cpu_dev)
+   if (props && (props->iolink_type == CRAT_IOLINK_TYPE_PCIEXPRESS ||
+ props->iolink_type == CRAT_IOLINK_TYPE_XGMI)) {
+   to_dev = kfd_topology_device_by_proximity_domain(id_to);
+   if (!to_dev)
return -ENODEV;
/* same everything but the other direction */
props2 = kmemdup(props, sizeof(*props2), GFP_KERNEL);
props2->node_from = id_to;
props2->node_to = id_from;
props2->kobj = NULL;
-   cpu_dev->io_link_count++;
-   cpu_dev->node_props.io_links_count++;
-   list_add_tail(>list, _dev->io_link_props);
+   to_dev->io_link_count++;
+   to_dev->node_props.io_links_count++;
+   list_add_tail(>list, _dev->io_link_props);
}
 
return 0;
@@ -1037,7 +1042,7 @@ static int kfd_fill_gpu_memory_affinity(int *avail_size,
  *
  * Return 0 if successful else return -ve value
  */
-static int kfd_fill_gpu_direct_io_link(int *avail_size,
+static int kfd_fill_gpu_direct_io_link_to_cpu(int *avail_size,
struct kfd_dev *kdev,
struct crat_subtype_iolink *sub_type_hdr,
uint32_t proximity_domain)
@@ -1069,6 +1074,28 @@ static int kfd_fill_gpu_direct_io_link(int *avail_size,
return 0;
 }
 
+static int kfd_fill_gpu_xgmi_link_to_gpu(int *avail_size,
+   struct kfd_dev *kdev,
+   struct crat_subtype_iolink *sub_type_hdr,
+   uint32_t proximity_domain_from,
+   uint32_t proximity_domain_to)
+{
+   *avail_size -= sizeof(struct crat_subtype_iolink);
+   if (*avail_size < 0)
+   return -ENOMEM;
+
+   memset((void *)sub_type_hdr, 0, sizeof(struct crat_subtype_iolink));
+
+   sub_type_hdr->type = CRAT_SUBTYPE_IOLINK_AFFINITY;
+   sub_type_hdr->length = sizeof(struct crat_subtype_iolink);
+   sub_type_hdr->flags |= CRAT_SUBTYPE_FLAGS_ENABLED;
+
+   sub_type_hdr->io_interface_type = CRAT_IOLINK_TYPE_XGMI;
+   sub_type_hdr->proximity_domain_from = proximity_domain_from;
+   sub_type_hdr->proximity_domain_to = proximity_domain_to;
+   return 0;
+}
+
 /* kfd_create_vcrat_image_gpu - Create Virtual CRAT for CPU
  *
  * @pcrat_image: Fill in VCRAT for GPU
@@ -1081,14 +1108,16 @@ static int kfd_create_vcrat_image_gpu(void *pcrat_image,
 {
struct crat_header *crat_table = (struct crat_header *)pcrat_image;
struct crat_subtype_generic *sub_type_hdr;
+   struct kfd_local_mem_info local_mem_info;
+   struct kfd_topology_device *peer_dev;
struct crat_subtype_computeunit *cu;
struct kfd_cu_info cu_info;
int avail_size = *size;
uint32_t total_num_of_cu;
int num_of_cache_entries = 0;
int cache_mem_filled = 0;
+   uint32_t nid = 0;
int ret = 0;
- 

[PATCH 12/13] drm/amdkfd: Add new iolink type defines

[shaoyunl]

From: Shaoyun Liu 

Update the iolink type defines according to the new thunk spec

Change-Id: Ie155641b6bfbe005ae0e12c5c31c68157247ea26
Signed-off-by: Shaoyun Liu 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_crat.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.h
index b5cd182..7a93aeb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.h
@@ -248,7 +248,12 @@ struct crat_subtype_ccompute {
 #define CRAT_IOLINK_TYPE_RAPID_IO  8
 #define CRAT_IOLINK_TYPE_INFINIBAND9
 #define CRAT_IOLINK_TYPE_RESERVED3 10
-#define CRAT_IOLINK_TYPE_OTHER 11
+#define CRAT_IOLINK_TYPE_XGMI  11
+#define CRAT_IOLINK_TYPE_XGOP  12
+#define CRAT_IOLINK_TYPE_GZ13
+#define CRAT_IOLINK_TYPE_ETHERNET_RDMA 14
+#define CRAT_IOLINK_TYPE_RDMA_OTHER15
+#define CRAT_IOLINK_TYPE_OTHER 16
 #define CRAT_IOLINK_TYPE_MAX   255
 
 #define CRAT_IOLINK_RESERVED_LENGTH24
-- 
2.7.4

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

[PATCH 11/13] drm/amdkfd: kfd expose the hive_id of the device through its node properties

[shaoyunl]

From: Shaoyun Liu 

Thunk will generate the XGMI topology information when necessary with the 
hive_id
for each specified device

Change-Id: I3bbc37bd2af4295e24357ce82f2c760162aff9ca
Signed-off-by: Shaoyun Liu 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device.c   | 3 +++
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 +++
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 
 drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 1 +
 4 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 1b04871..b4d9e6b 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -476,6 +476,9 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
goto kfd_doorbell_error;
}
 
+   if (kfd->kfd2kgd->get_hive_id)
+   kfd->hive_id = kfd->kfd2kgd->get_hive_id(kfd->kgd);
+
if (kfd_topology_add_device(kfd)) {
dev_err(kfd_device, "Error adding device to topology\n");
goto kfd_topology_add_device_error;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 355f79d..6a5418f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -254,6 +254,9 @@ struct kfd_dev {
bool cwsr_enabled;
const void *cwsr_isa;
unsigned int cwsr_isa_size;
+
+   /* xGMI */
+   uint64_t hive_id;
 };
 
 /* KGD2KFD callbacks */
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index bc95d4df..19ecc82 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -443,6 +443,8 @@ static ssize_t node_show(struct kobject *kobj, struct 
attribute *attr,
dev->node_props.location_id);
sysfs_show_32bit_prop(buffer, "drm_render_minor",
dev->node_props.drm_render_minor);
+   sysfs_show_64bit_prop(buffer, "hive_id",
+   dev->node_props.hive_id);
 
if (dev->gpu) {
log_max_watch_addr =
@@ -1219,6 +1221,8 @@ int kfd_topology_add_device(struct kfd_dev *gpu)
dev->node_props.drm_render_minor =
gpu->shared_resources.drm_render_minor;
 
+   dev->node_props.hive_id = gpu->hive_id;
+
kfd_fill_mem_clk_max_info(dev);
kfd_fill_iolink_non_crat_info(dev);
 
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.h
index 7d9c3f9..92a19be 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.h
@@ -49,6 +49,7 @@
 #define HSA_CAP_AQL_QUEUE_DOUBLE_MAP   0x4000
 
 struct kfd_node_properties {
+   uint64_t hive_id;
uint32_t cpu_cores_count;
uint32_t simd_count;
uint32_t mem_banks_count;
-- 
2.7.4

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

[PATCH 10/13] drm/amdgpu: get_hive_id from amdgpu side

[shaoyunl]

From: Shaoyun Liu 

Retrieve hive_id from amdgpu device

Change-Id: I9bb4d87870edf638b477a9088f14bc84b70e71e2
Signed-off-by: Shaoyun Liu 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 7 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 1 +
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 1a0824e..5661c34 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -411,6 +411,13 @@ uint64_t amdgpu_amdkfd_get_vram_usage(struct kgd_dev *kgd)
return amdgpu_vram_mgr_usage(>mman.bdev.man[TTM_PL_VRAM]);
 }
 
+uint64_t amdgpu_amdkfd_get_hive_id(struct kgd_dev *kgd)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)kgd;
+
+   return adev->gmc.xgmi.hive_id;
+}
+
 int amdgpu_amdkfd_submit_ib(struct kgd_dev *kgd, enum kgd_engine_type engine,
uint32_t vmid, uint64_t gpu_addr,
uint32_t *ib_cmd, uint32_t ib_len)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 2a1da3f..41e7dfc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -145,6 +145,7 @@ uint64_t get_gpu_clock_counter(struct kgd_dev *kgd);
 uint32_t get_max_engine_clock_in_mhz(struct kgd_dev *kgd);
 void get_cu_info(struct kgd_dev *kgd, struct kfd_cu_info *cu_info);
 uint64_t amdgpu_amdkfd_get_vram_usage(struct kgd_dev *kgd);
+uint64_t amdgpu_amdkfd_get_hive_id(struct kgd_dev *kgd);
 
 #define read_user_wptr(mmptr, wptr, dst)   \
({  \
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
index 3dc987c..94d39a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
@@ -216,6 +216,7 @@ static const struct kfd2kgd_calls kfd2kgd = {
.submit_ib = amdgpu_amdkfd_submit_ib,
.gpu_recover = amdgpu_amdkfd_gpu_reset,
.set_compute_idle = amdgpu_amdkfd_set_compute_idle
+   .get_hive_id = amdgpu_amdkfd_get_hive_id,
 };
 
 struct kfd2kgd_calls *amdgpu_amdkfd_gfx_9_0_get_functions(void)
-- 
2.7.4

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

[PATCH 09/13] drm/amd/include: Add get_hive_id interface in kfd2kgd

[shaoyunl]

From: Shaoyun Liu 

KFD need to get hive id from amdgpu to build up the XGMI topology

Change-Id: If68ea8fd7fb17b7ffb581f45d8406925578d96b8
Signed-off-by: Shaoyun Liu 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h 
b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
index 31c52c1..cb4deb2 100644
--- a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
+++ b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h
@@ -313,6 +313,8 @@ struct tile_config {
  * @set_compute_idle: Indicates that compute is idle on a device. This
  * can be used to change power profiles depending on compute activity.
  *
+ * @get_hive_id: Returns hive id of current  device,  0 if xgmi is not enabled
+ *
  * This structure contains function pointers to services that the kgd driver
  * provides to amdkfd driver.
  *
@@ -438,6 +440,9 @@ struct kfd2kgd_calls {
void (*gpu_recover)(struct kgd_dev *kgd);
 
void (*set_compute_idle)(struct kgd_dev *kgd, bool idle);
+
+   uint64_t (*get_hive_id)(struct kgd_dev *kgd);
+
 };
 
 /**
-- 
2.7.4

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

[PATCH 08/13] drm/amdgpu : Generate XGMI topology info from driver level

[shaoyunl]

From: Shaoyun Liu 

Driver will save an array of XGMI hive info, each hive will have a list of 
devices
that have the same hive ID.

Change-Id: Ia2934d5b624cffa3283bc0a37679eddbd387cbdd
Signed-off-by: Shaoyun Liu 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdgpu/Makefile|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   6 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h|   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   | 119 +
 5 files changed, 128 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index e83ba7b..138cb78 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -53,7 +53,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_atomfirmware.o \
amdgpu_vf_error.o amdgpu_sched.o amdgpu_debugfs.o amdgpu_ids.o \
-   amdgpu_gmc.o
+   amdgpu_gmc.o amdgpu_xgmi.o
 
 # add asic specific block
 amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index e992e0f..27382767 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1219,6 +1219,12 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
+
+/*
+ * functions used by amdgpu_xgmi.c
+ */
+int amdgpu_xgmi_add_device(struct amdgpu_device *adev);
+
 /*
  * functions used by amdgpu_encoder.c
  */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 93476b8..e24a171 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1586,6 +1586,7 @@ static int amdgpu_device_ip_init(struct amdgpu_device 
*adev)
adev->ip_blocks[i].status.hw = true;
}
 
+   amdgpu_xgmi_add_device(adev);
amdgpu_amdkfd_device_init(adev);
 
if (amdgpu_sriov_vf(adev))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
index bfb0a7e..f7c90c2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
@@ -88,6 +88,7 @@ struct amdgpu_gmc_funcs {
 };
 
 struct amdgpu_xgmi {
+   struct list_head head; /* gpu list in the same hive */
u64 device_id; /* from psp */
u64 hive_id; /* from psp */
u64 node_segment_size; /* fixed per family */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
new file mode 100644
index 000..897afbb
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -0,0 +1,119 @@
+/*
+ * Copyright 2018 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 
+#include "amdgpu.h"
+#include "amdgpu_psp.h"
+
+
+static DEFINE_MUTEX(xgmi_mutex);
+
+#define AMDGPU_MAX_XGMI_HIVE   8
+#define AMDGPU_MAX_XGMI_DEVICE_PER_HIVE4
+
+struct amdgpu_hive_info {
+   uint64_thive_id;
+   struct list_headdevice_list;
+};
+
+static struct amdgpu_hive_info xgmi_hives[AMDGPU_MAX_XGMI_HIVE];
+static unsigned hive_count = 0;
+
+static struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct amdgpu_device 
*adev)
+{
+   int i;
+   struct amdgpu_hive_info *tmp;
+
+   if (!adev->gmc.xgmi.hive_id)
+   return NULL;
+   for (i = 0 ; i < hive_count; ++i) {
+   tmp = _hives[i];
+   if (tmp->hive_id == adev->gmc.xgmi.hive_id)
+ 

[PATCH 07/13] drm/amdgpu: Add place holder functions for xgmi topology interface with psp

[shaoyunl]

From: Shaoyun Liu 

Add dummy function for xgmi function interface with psp

Change-Id: I01f35baf5a4b96e9654d448c9892be3cd72c05b7
Signed-off-by: Shaoyun Liu 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
index b70cfa3..b1c0b33 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v11_0.c
@@ -548,6 +548,29 @@ static int psp_v11_0_mode1_reset(struct psp_context *psp)
return 0;
 }
 
+static int psp_v11_0_xgmi_get_topology_info(struct psp_context *psp,
+   int number_devices, struct psp_xgmi_topology_info *topology)
+{
+   return 0;
+}
+
+static int psp_v11_0_xgmi_set_topology_info(struct psp_context *psp,
+   int number_devices, struct psp_xgmi_topology_info *topology)
+{
+   return 0;
+}
+
+static u64 psp_v11_0_xgmi_get_hive_id(struct psp_context *psp)
+{
+   u64 hive_id = 0;
+
+   /* Remove me when normal psp interface is ready */
+   if (psp->adev->gmc.xgmi.num_physical_nodes)
+   hive_id = 0x123456789abcdef;
+
+   return hive_id;
+}
+
 static const struct psp_funcs psp_v11_0_funcs = {
.init_microcode = psp_v11_0_init_microcode,
.bootloader_load_sysdrv = psp_v11_0_bootloader_load_sysdrv,
@@ -560,6 +583,9 @@ static const struct psp_funcs psp_v11_0_funcs = {
.cmd_submit = psp_v11_0_cmd_submit,
.compare_sram_data = psp_v11_0_compare_sram_data,
.mode1_reset = psp_v11_0_mode1_reset,
+   .xgmi_get_topology_info = psp_v11_0_xgmi_get_topology_info,
+   .xgmi_set_topology_info = psp_v11_0_xgmi_set_topology_info,
+   .xgmi_get_hive_id = psp_v11_0_xgmi_get_hive_id,
 };
 
 void psp_v11_0_set_psp_funcs(struct psp_context *psp)
-- 
2.7.4

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

[PATCH 06/13] drm/amdgpu : Add psp function interfaces for XGMI support

[shaoyunl]

From: Shaoyun Liu 

Place holder for XGMI support

Change-Id: I924fa3693366409de0218009c7f709cb464854cc
Signed-off-by: Shaoyun Liu 
Reviewed-by: Huang Rui 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 34 +
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
index 981887c..8b8720e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
@@ -35,6 +35,7 @@
 #define PSP_TMR_SIZE   0x40
 
 struct psp_context;
+struct psp_xgmi_topology_info;
 
 enum psp_ring_type
 {
@@ -79,6 +80,12 @@ struct psp_funcs
  enum AMDGPU_UCODE_ID ucode_type);
bool (*smu_reload_quirk)(struct psp_context *psp);
int (*mode1_reset)(struct psp_context *psp);
+   uint64_t (*xgmi_get_device_id)(struct psp_context *psp);
+   uint64_t (*xgmi_get_hive_id)(struct psp_context *psp);
+   int (*xgmi_get_topology_info)(struct psp_context *psp, int 
number_devices,
+   struct psp_xgmi_topology_info *topology);
+   int (*xgmi_set_topology_info)(struct psp_context *psp, int 
number_devices,
+   struct psp_xgmi_topology_info *topology);
 };
 
 struct psp_context
@@ -134,6 +141,23 @@ struct amdgpu_psp_funcs {
enum AMDGPU_UCODE_ID);
 };
 
+struct psp_xgmi_topology_info {
+   /* Generated by PSP to identify the GPU instance within xgmi connection 
*/
+   uint64_tdevice_id;
+   /*
+* If all bits set to 0 , driver indicates it wants to retrieve the xgmi
+* connection vector topology, but not access enable the connections
+* if some or all bits are set to 1, driver indicates it want to 
retrieve the
+* current xgmi topology and  access enable the link to GPU[i] 
associated
+* with the bit position in the  vector.
+* On return,: bits indicated which xgmi links are present/active 
depending
+* on the  value passed in. The relative bit offset for the  relative 
GPU index
+* within the  hive is always marked active.
+*/
+   uint32_tconnection_mask;
+   uint32_treserved; /* must be  0 */
+};
+
 #define psp_prep_cmd_buf(ucode, type) (psp)->funcs->prep_cmd_buf((ucode), 
(type))
 #define psp_ring_init(psp, type) (psp)->funcs->ring_init((psp), (type))
 #define psp_ring_create(psp, type) (psp)->funcs->ring_create((psp), (type))
@@ -153,6 +177,16 @@ struct amdgpu_psp_funcs {
((psp)->funcs->smu_reload_quirk ? 
(psp)->funcs->smu_reload_quirk((psp)) : false)
 #define psp_mode1_reset(psp) \
((psp)->funcs->mode1_reset ? (psp)->funcs->mode1_reset((psp)) : 
false)
+#define psp_xgmi_get_device_id(psp) \
+   ((psp)->funcs->xgmi_get_device_id ? 
(psp)->funcs->xgmi_get_device_id((psp)) : 0)
+#define psp_xgmi_get_hive_id(psp) \
+   ((psp)->funcs->xgmi_get_hive_id ? 
(psp)->funcs->xgmi_get_hive_id((psp)) : 0)
+#define psp_xgmi_get_topology_info(psp, num_device, topology) \
+   ((psp)->funcs->xgmi_get_topology_info ? \
+   (psp)->funcs->xgmi_get_topology_info((psp), (num_device), 
(topology)) : -EINVAL)
+#define psp_xgmi_set_topology_info(psp, num_device, topology) \
+   ((psp)->funcs->xgmi_set_topology_info ?  \
+   (psp)->funcs->xgmi_set_topology_info((psp), (num_device), 
(topology)) : -EINVAL)
 
 #define amdgpu_psp_check_fw_loading_status(adev, i) 
(adev)->firmware.funcs->check_fw_loading_status((adev), (i))
 
-- 
2.7.4

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

[PATCH 05/13] drm/amdgpu/gmc9: populate xgmi info for vega20

[shaoyunl]

From: Alex Deucher 

Call the new gfxhub 1.1 function to get the xgmi info.

Acked-by: Huang Rui 
Acked-by: Slava Abramov 
Reviewed-by :Shaoyun liu 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 0da89ba..b1c8489 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -43,6 +43,7 @@
 
 #include "gfxhub_v1_0.h"
 #include "mmhub_v1_0.h"
+#include "gfxhub_v1_1.h"
 
 #include "ivsrcid/vmc/irqsrcs_vmc_1_0.h"
 
@@ -991,6 +992,12 @@ static int gmc_v9_0_sw_init(void *handle)
}
adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
+   if (adev->asic_type == CHIP_VEGA20) {
+   r = gfxhub_v1_1_get_xgmi_info(adev);
+   if (r)
+   return r;
+   }
+
r = gmc_v9_0_mc_init(adev);
if (r)
return r;
-- 
2.7.4

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

[PATCH 04/13] drm/amdgpu/gmc9: Adjust xgmi offset

[shaoyunl]

From: Alex Deucher 

On hives with xgmi enabled, the fb_location aperture is a size
which defines the total framebuffer size of all nodes in the
hive.  Each GPU in the hive has the same view via the fb_location
aperture.  GPU0 starts at offset (0 * segment size),
GPU1 starts at offset (1 * segment size), etc.

For access to local vram on each GPU, we need to take this offset into
account. This including on setting up GPUVM page table  and  GART table

Acked-by: Huang Rui 
Acked-by: Slava Abramov 
Signed-off-by: Shaoyun Liu 
Signed-off-by: Alex Deucher 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c  | 4 
 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c | 3 +++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c| 6 ++
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 6acdeeb..a95b615 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -158,6 +158,10 @@ void amdgpu_gmc_gart_location(struct amdgpu_device *adev, 
struct amdgpu_gmc *mc)
if ((size_bf >= mc->gart_size && size_bf < size_af) ||
(size_af < mc->gart_size))
mc->gart_start = 0;
+   else if (mc->xgmi.num_physical_nodes)
+   mc->gart_start = mc->vram_start +
+   (mc->xgmi.num_physical_nodes - 
mc->xgmi.physical_node_id)
+   * mc->xgmi.node_segment_size;
else
mc->gart_start = mc->mc_mask - mc->gart_size + 1;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c 
b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c
index d4170cb..5e9ab8e 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c
@@ -44,6 +44,9 @@ int gfxhub_v1_1_get_xgmi_info(struct amdgpu_device *adev)
REG_GET_FIELD(xgmi_lfb_cntl, MC_VM_XGMI_LFB_CNTL, 
PF_LFB_REGION);
if (adev->gmc.xgmi.physical_node_id > 3)
return -EINVAL;
+   adev->gmc.xgmi.node_segment_size = REG_GET_FIELD(
+   RREG32_SOC15(GC, 0, mmMC_VM_XGMI_LFB_SIZE),
+   MC_VM_XGMI_LFB_SIZE, PF_LFB_SIZE) << 24;
}
 
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 3529c55..0da89ba 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -770,12 +770,18 @@ static void gmc_v9_0_vram_gtt_location(struct 
amdgpu_device *adev,
u64 base = 0;
if (!amdgpu_sriov_vf(adev))
base = mmhub_v1_0_get_fb_location(adev);
+   /* add the xgmi offset of the physical node */
+   base += adev->gmc.xgmi.physical_node_id * 
adev->gmc.xgmi.node_segment_size;
amdgpu_gmc_vram_location(adev, >gmc, base);
amdgpu_gmc_gart_location(adev, mc);
if (!amdgpu_sriov_vf(adev))
amdgpu_gmc_agp_location(adev, mc);
/* base offset of vram pages */
adev->vm_manager.vram_base_offset = gfxhub_v1_0_get_mc_fb_offset(adev);
+
+   /* XXX: add the xgmi offset of the physical node? */
+   adev->vm_manager.vram_base_offset +=
+   adev->gmc.xgmi.physical_node_id * 
adev->gmc.xgmi.node_segment_size;
 }
 
 /**
-- 
2.7.4

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

[PATCH 03/13] drm/amdgpu/gmc9: add a new gfxhub 1.1 helper for xgmi

[shaoyunl]

From: Alex Deucher 

Used to populate the xgmi info on vega20.

v2: PF_MAX_REGION is val - 1 (Ray)

Acked-by: Huang Rui 
Acked-by: Slava Abramov 
Reviewed-by :Shaoyun liu 
Signed-off-by: Alex Deucher 

Change-Id: Ia7b7f112880e69cdbcf73a8abf04cd6ef303940c
---
 drivers/gpu/drm/amd/amdgpu/Makefile  |  2 +-
 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c | 50 
 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.h | 29 ++
 3 files changed, 80 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.h

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 847536b..e83ba7b 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -74,7 +74,7 @@ amdgpu-y += \
 amdgpu-y += \
gmc_v7_0.o \
gmc_v8_0.o \
-   gfxhub_v1_0.o mmhub_v1_0.o gmc_v9_0.o
+   gfxhub_v1_0.o mmhub_v1_0.o gmc_v9_0.o gfxhub_v1_1.o
 
 # add IH block
 amdgpu-y += \
diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c 
b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c
new file mode 100644
index 000..d4170cb
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright 2018 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 "amdgpu.h"
+#include "gfxhub_v1_1.h"
+
+#include "gc/gc_9_2_1_offset.h"
+#include "gc/gc_9_2_1_sh_mask.h"
+
+#include "soc15_common.h"
+
+int gfxhub_v1_1_get_xgmi_info(struct amdgpu_device *adev)
+{
+   u32 xgmi_lfb_cntl = RREG32_SOC15(GC, 0, mmMC_VM_XGMI_LFB_CNTL);
+   u32 max_region =
+   REG_GET_FIELD(xgmi_lfb_cntl, MC_VM_XGMI_LFB_CNTL, 
PF_MAX_REGION);
+
+   /* PF_MAX_REGION=0 means xgmi is disabled */
+   if (max_region) {
+   adev->gmc.xgmi.num_physical_nodes = max_region + 1;
+   if (adev->gmc.xgmi.num_physical_nodes > 4)
+   return -EINVAL;
+
+   adev->gmc.xgmi.physical_node_id =
+   REG_GET_FIELD(xgmi_lfb_cntl, MC_VM_XGMI_LFB_CNTL, 
PF_LFB_REGION);
+   if (adev->gmc.xgmi.physical_node_id > 3)
+   return -EINVAL;
+   }
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.h 
b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.h
new file mode 100644
index 000..d753cf2
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright 2018 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.
+ *
+ */
+
+#ifndef __GFXHUB_V1_1_H__
+#define __GFXHUB_V1_1_H__
+
+int gfxhub_v1_1_get_xgmi_info(struct amdgpu_device *adev);
+
+#endif
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org

[PATCH 02/13] drm/amdgpu/gmc: add initial xgmi structure to amdgpu_gmc structure

[shaoyunl]

From: Alex Deucher 

Initial pass at a structure to store xgmi info.  xgmi is a high
speed cross gpu interconnect.

Acked-by: Huang Rui 
Acked-by: Slava Abramov 
Reviewed-by :Shaoyun liu 
Signed-off-by: Alex Deucher 

Change-Id: I8b373bd847c857dd7cbefa55d1ede2a8785deb06
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
index 17ffc35..bfb0a7e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
@@ -87,6 +87,14 @@ struct amdgpu_gmc_funcs {
   u64 *dst, u64 *flags);
 };
 
+struct amdgpu_xgmi {
+   u64 device_id; /* from psp */
+   u64 hive_id; /* from psp */
+   u64 node_segment_size; /* fixed per family */
+   unsigned physical_node_id; /* physical node (0-3) */
+   unsigned num_physical_nodes; /* number of nodes (0-4) */
+};
+
 struct amdgpu_gmc {
resource_size_t aper_size;
resource_size_t aper_base;
@@ -125,6 +133,8 @@ struct amdgpu_gmc {
atomic_tvm_fault_info_updated;
 
const struct amdgpu_gmc_funcs   *gmc_funcs;
+
+   struct amdgpu_xgmi xgmi;
 };
 
 #define amdgpu_gmc_flush_gpu_tlb(adev, vmid) 
(adev)->gmc.gmc_funcs->flush_gpu_tlb((adev), (vmid))
-- 
2.7.4

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

[PATCH 01/13] drm/amd/include: update the bitfield define for PF_MAX_REGION

[shaoyunl]

From: Shaoyun Liu 

Correct the definition based on vega20 register spec

Change-Id: Ifde296134d00423cdf1078c8249d044f5b5cf5a5
Signed-off-by: Shaoyun Liu 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_2_1_sh_mask.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_2_1_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_2_1_sh_mask.h
index 6626fc2..76ea902 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_2_1_sh_mask.h
+++ b/drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_2_1_sh_mask.h
@@ -8241,9 +8241,9 @@
 #define MC_VM_LOCAL_HBM_ADDRESS_LOCK_CNTL__LOCK_MASK   
   0x0001L
 //MC_VM_XGMI_LFB_CNTL
 #define MC_VM_XGMI_LFB_CNTL__PF_LFB_REGION__SHIFT  
   0x0
-#define MC_VM_XGMI_LFB_CNTL__PF_MAX_REGION__SHIFT  
   0x3
+#define MC_VM_XGMI_LFB_CNTL__PF_MAX_REGION__SHIFT  
   0x4
 #define MC_VM_XGMI_LFB_CNTL__PF_LFB_REGION_MASK
   0x0007L
-#define MC_VM_XGMI_LFB_CNTL__PF_MAX_REGION_MASK
   0x0038L
+#define MC_VM_XGMI_LFB_CNTL__PF_MAX_REGION_MASK
   0x0070L
 //MC_VM_XGMI_LFB_SIZE
 #define MC_VM_XGMI_LFB_SIZE__PF_LFB_SIZE__SHIFT
   0x0
 #define MC_VM_XGMI_LFB_SIZE__PF_LFB_SIZE_MASK  
   0xL
-- 
2.7.4

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

Re: [PATCH] drm/amdgpu: set bulk_moveable to false when a per VM is released

[Christian König]

Hi Tom,

please check if that patch helps with your KASAN problem.

Thanks,
Christian.

Am 05.09.2018 um 17:08 schrieb Christian König:

Otherwise we might run into a use after free during bulk move.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index ea5e277ae038..ed1e6abda391 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2513,8 +2513,12 @@ void amdgpu_vm_bo_rmv(struct amdgpu_device *adev,
  struct amdgpu_bo_va *bo_va)
  {
struct amdgpu_bo_va_mapping *mapping, *next;
+   struct amdgpu_bo *bo = bo_va->base.bo;
struct amdgpu_vm *vm = bo_va->base.vm;
  
+	if (bo && bo->tbo.resv == vm->root.base.bo->tbo.resv)

+   vm->bulk_moveable = false;
+
list_del(_va->base.bo_list);
  
  	spin_lock(>invalidated_lock);


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

[PATCH] drm/amdgpu: set bulk_moveable to false when a per VM is released

[Christian König]

Otherwise we might run into a use after free during bulk move.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index ea5e277ae038..ed1e6abda391 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2513,8 +2513,12 @@ void amdgpu_vm_bo_rmv(struct amdgpu_device *adev,
  struct amdgpu_bo_va *bo_va)
 {
struct amdgpu_bo_va_mapping *mapping, *next;
+   struct amdgpu_bo *bo = bo_va->base.bo;
struct amdgpu_vm *vm = bo_va->base.vm;
 
+   if (bo && bo->tbo.resv == vm->root.base.bo->tbo.resv)
+   vm->bulk_moveable = false;
+
list_del(_va->base.bo_list);
 
spin_lock(>invalidated_lock);
-- 
2.17.1

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

Re: Patches for XGMI support

[Christian König]

Please use git send-email instead of attaching the changes.

And make sure the patches apply to amd-staging-drm-next, not drm-next!

Regards,
Christian.

Am 05.09.2018 um 17:02 schrieb Liu, Shaoyun:

Here is a list of patches in the topic branch  for XGMI support , now I try to 
merge them into drm-next .
Please have  a look .

Regards
Shaoyun.liu



___
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

Patches for XGMI support

[Liu, Shaoyun]

Here is a list of patches in the topic branch  for XGMI support , now I try to 
merge them into drm-next .
Please have  a look . 

Regards
Shaoyun.liu



0001-drm-amd-include-update-the-bitfield-define-for-PF_MA.patch
Description: 0001-drm-amd-include-update-the-bitfield-define-for-PF_MA.patch


0002-drm-amdgpu-gmc-add-initial-xgmi-structure-to-amdgpu_.patch
Description: 0002-drm-amdgpu-gmc-add-initial-xgmi-structure-to-amdgpu_.patch


0003-drm-amdgpu-gmc9-add-a-new-gfxhub-1.1-helper-for-xgmi.patch
Description: 0003-drm-amdgpu-gmc9-add-a-new-gfxhub-1.1-helper-for-xgmi.patch


0004-drm-amdgpu-gmc9-Adjust-xgmi-offset.patch
Description: 0004-drm-amdgpu-gmc9-Adjust-xgmi-offset.patch


0005-drm-amdgpu-gmc9-populate-xgmi-info-for-vega20.patch
Description: 0005-drm-amdgpu-gmc9-populate-xgmi-info-for-vega20.patch


0006-drm-amdgpu-Add-psp-function-interfaces-for-XGMI-supp.patch
Description: 0006-drm-amdgpu-Add-psp-function-interfaces-for-XGMI-supp.patch


0007-drm-amdgpu-Add-place-holder-functions-for-xgmi-topol.patch
Description: 0007-drm-amdgpu-Add-place-holder-functions-for-xgmi-topol.patch


0008-drm-amdgpu-Generate-XGMI-topology-info-from-driver-l.patch
Description: 0008-drm-amdgpu-Generate-XGMI-topology-info-from-driver-l.patch


0009-drm-amd-include-Add-get_hive_id-interface-in-kfd2kgd.patch
Description: 0009-drm-amd-include-Add-get_hive_id-interface-in-kfd2kgd.patch


0010-drm-amdgpu-get_hive_id-from-amdgpu-side.patch
Description: 0010-drm-amdgpu-get_hive_id-from-amdgpu-side.patch


0011-drm-amdkfd-kfd-expose-the-hive_id-of-the-device-thro.patch
Description: 0011-drm-amdkfd-kfd-expose-the-hive_id-of-the-device-thro.patch


0012-drm-amdkfd-Add-new-iolink-type-defines.patch
Description: 0012-drm-amdkfd-Add-new-iolink-type-defines.patch


0013-drm-amdkfd-Generate-xGMI-direct-iolink.patch
Description: 0013-drm-amdkfd-Generate-xGMI-direct-iolink.patch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

[Emil Velikov]

On 5 September 2018 at 14:20, Thomas Hellstrom  wrote:

>> In that case, please give me 24h to do a libdrm release before pushing.
>> I had to push some workarounds for the sandboxing mentioned earlier :-\
>>
>> Thanks
>> Emil
>
>
> Ouch, I just pushed the patch, but feel free to cut the release just before
> that commit.
>
That doesn't quite work. Barring any objections I'll: revert, release, reapply.

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

Re: two KASANs in TTM logic

[Tom St Denis]

Logs attached.

Tom



On 09/05/2018 08:02 AM, Christian König wrote:
Still not the slightest idea what is causing this and the patch 
definitely fixes things a lot.


Can you try to enable list debugging in your kernel?

Thanks,
Christian.

Am 04.09.2018 um 19:18 schrieb Tom St Denis:

Sure:

d2917f399e0b250f47d07da551a335843a24f835 is the first bad commit
commit d2917f399e0b250f47d07da551a335843a24f835
Author: Christian König 
Date:   Thu Aug 30 10:04:53 2018 +0200

    drm/amdgpu: fix "use bulk moves for efficient VM LRU handling" v2

    First step to fix the LRU corruption, we accidentially tried to 
move things

    on the LRU after dropping the lock.

    Signed-off-by: Christian König 
    Tested-by: Michel Dänzer 

:04 04 ed5be1ad4da129c4154b2b43acf7ef349a470700 
0008c4e2fb56512f41559618dd474c916fc09a37 M  drivers



The commit before that I can run xonotic-glx and piglit on my Carrizo 
without a KASAN.


Tom

On 09/04/2018 10:05 AM, Christian König wrote:

The first one should already be fixed.

Not sure where the second comes from. Can you narrow that down further?

Christian.

Am 04.09.2018 um 15:46 schrieb Tom St Denis:

First is caused by this commit while running a GL heavy application.

d78c1fa0c9f815fe951fd57001acca3d35262a17 is the first bad commit
commit d78c1fa0c9f815fe951fd57001acca3d35262a17
Author: Michel Dänzer 
Date:   Wed Aug 29 11:59:38 2018 +0200

    Revert "drm/amdgpu: move PD/PT bos on LRU again"

    This reverts commit 31625ccae4464b61ec8cdb9740df848bbc857a5b.

    It triggered various badness on my development machine when 
running the

    piglit gpu profile with radeonsi on Bonaire, looks like memory
    corruption due to insufficiently protected list manipulations.

    Signed-off-by: Michel Dänzer 
    Signed-off-by: Alex Deucher 

:04 04 b7169f0cf0c7decec631751a9896a92badb67f9d 
42ea58f43199d26fc0c7ddcc655e6d0964b81817 M  drivers


The second is caused by something between that and the tip of the 
4.19-rc1 amd-staging-drm-next (I haven't pinned it down yet) while 
loading GNOME.


Tom



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




[0.00] Linux version 4.19.0-rc1+ (root@raven) (gcc version 8.1.1 20180712 (Red Hat 8.1.1-5) (GCC)) #24 SMP Wed Sep 5 08:59:20 EDT 2018
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-rc1+ root=UUID=66163c80-0ca1-4beb-aeba-5cc130b813e6 ro rhgb quiet modprobe.blacklist=amdgpu,radeon LANG=en_CA.UTF-8
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d3ff] usable
[0.00] BIOS-e820: [mem 0x0009d400-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x03ff] usable
[0.00] BIOS-e820: [mem 0x0400-0x04009fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x0400a000-0x09bf] usable
[0.00] BIOS-e820: [mem 0x09c0-0x09ff] reserved
[0.00] BIOS-e820: [mem 0x0a00-0x0aff] usable
[0.00] BIOS-e820: [mem 0x0b00-0x0b01] reserved
[0.00] BIOS-e820: [mem 0x0b02-0x73963fff] usable
[0.00] BIOS-e820: [mem 0x73964000-0x7397cfff] ACPI data
[0.00] BIOS-e820: [mem 0x7397d000-0x7a5aafff] usable
[0.00] BIOS-e820: [mem 0x7a5ab000-0x7a6c2fff] reserved
[0.00] BIOS-e820: [mem 0x7a6c3000-0x7a6cefff] ACPI data
[0.00] BIOS-e820: [mem 0x7a6cf000-0x7a7d1fff] usable
[0.00] BIOS-e820: [mem 0x7a7d2000-0x7ab89fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7ab8a000-0x7b942fff] reserved
[0.00] BIOS-e820: [mem 0x7b943000-0x7dff] usable
[0.00] BIOS-e820: [mem 0x7e00-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfd80-0xfdff] reserved
[0.00] BIOS-e820: [mem 0xfea0-0xfea0] reserved
[0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfec3-0xfec30fff] reserved
[0.00] 

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

[Thomas Hellstrom]

On 09/05/2018 03:07 PM, Emil Velikov wrote:

On 5 September 2018 at 11:10, Thomas Hellstrom  wrote:

Hi, Emil,


On 09/05/2018 11:33 AM, Emil Velikov wrote:

On 4 September 2018 at 23:33, Dave Airlie  wrote:

On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom 
wrote:

On 09/03/2018 06:33 PM, Daniel Vetter wrote:

On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:

On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:

On 08/31/2018 05:27 PM, Emil Velikov wrote:

On 31 August 2018 at 15:38, Michel Dänzer 
wrote:

[ Adding the amd-gfx list ]

On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote:

On 08/31/2018 02:30 PM, Emil Velikov wrote:

On 31 August 2018 at 12:54, Thomas Hellstrom

wrote:

To determine whether a device node is a drm device
node or not, the code
currently compares the node's major number to the static drm
major
device
number.

This breaks the standalone vmwgfx driver on XWayland dri
clients,


Any particular reason why the code doesn't use a fixed node
there?
It will make the diff vs the in-kernel driver a bit smaller.

Because then it won't be able to interoperate with other in-tree
drivers, like virtual drm drivers or passthrough usb drm drivers.
There is no clean way to share the minor number allocation
with in-tree
drm, so standalone vmwgfx is using dynamic major allocation.

I wonder why I haven't heard of any of these issues with the
standalone
version of amdgpu shipped in packaged AMD releases. Does that
also use a
different major number? If yes, maybe it's just that nobody has
tried
Xwayland clients with that driver. If no, how does it avoid the
other
issues described above?


AFAICT, the difference is that the standalone vmwgfx uses an
internal
copy of drm core.
It doesn't reuse the in-kernel drm, hence it cannot know which minor
it can use.

-Emil

Actually, standalone vmwgfx could perhaps also try to allocate minors
from 63 and downwards. That might work, but needs some verification.


So unfortuntately this doesn't work since the in-tree drm's file
operations
are registered with the DRM_MAJOR.
So I still think the patch is the way to go. If people are concerned
that
also fbdev file descriptors are allowed, perhaps there are other sysfs
traits we can look at?

Somewhat out of curiosity, but why do you have to overwrite all of drm?
amdgpu seems to be able to pull their stunt off without ...
-Daniel

At the time we launched the standalone vmwgfx, the DRM <-> driver
interface was moving considerably more rapidly than the DRM <-> kernel
interface. I think that's still the case. Hence less work for us. Also
meant we can install the full driver stack with latest features on
fairly old VMs without backported DRM functionality.


I think this should be fine for 99% of drm usage, there may be corner
cases in wierd places, but I can't point to any that really matter
(maybe strace?)


Having a closer look, I think this will break the Firefox/Chrome
sandboxing :-\
I cannot see the path /sys/dev/char/%d:%d/device/drm in the allowed
list [1] [2].

Thanks for pointing this out.

The function drmGetMinorNameForFD() already opens this path, so any
user-space using that function would not work before either.

Also mozilla/firefox adds /sys/dev/char/226:* Which means that while it
still won't work on standalone vmwgfx, there should at least be no
regression.

For Chromium it seems they allow /sys/dev/char/ for AmdGpu, but only under
ChromOS, so I'll ping those to be safe.

I also won't be doing an immediate release after pushing.


In that case, please give me 24h to do a libdrm release before pushing.
I had to push some workarounds for the sandboxing mentioned earlier :-\

Thanks
Emil


Ouch, I just pushed the patch, but feel free to cut the release just 
before that commit.


/Thomas


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

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

[Emil Velikov]

On 5 September 2018 at 11:10, Thomas Hellstrom  wrote:
> Hi, Emil,
>
>
> On 09/05/2018 11:33 AM, Emil Velikov wrote:
>>
>> On 4 September 2018 at 23:33, Dave Airlie  wrote:
>>>
>>> On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom 
>>> wrote:

 On 09/03/2018 06:33 PM, Daniel Vetter wrote:
>
> On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:
>>
>> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:
>>>
>>> On 08/31/2018 05:27 PM, Emil Velikov wrote:

 On 31 August 2018 at 15:38, Michel Dänzer 
 wrote:
>
> [ Adding the amd-gfx list ]
>
> On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote:
>>
>> On 08/31/2018 02:30 PM, Emil Velikov wrote:
>>>
>>> On 31 August 2018 at 12:54, Thomas Hellstrom
>>> 
>>> wrote:

 To determine whether a device node is a drm device
 node or not, the code
 currently compares the node's major number to the static drm
 major
 device
 number.

 This breaks the standalone vmwgfx driver on XWayland dri
 clients,

>>> Any particular reason why the code doesn't use a fixed node
>>> there?
>>> It will make the diff vs the in-kernel driver a bit smaller.
>>
>> Because then it won't be able to interoperate with other in-tree
>> drivers, like virtual drm drivers or passthrough usb drm drivers.
>> There is no clean way to share the minor number allocation
>> with in-tree
>> drm, so standalone vmwgfx is using dynamic major allocation.
>
> I wonder why I haven't heard of any of these issues with the
> standalone
> version of amdgpu shipped in packaged AMD releases. Does that
> also use a
> different major number? If yes, maybe it's just that nobody has
> tried
> Xwayland clients with that driver. If no, how does it avoid the
> other
> issues described above?
>
 AFAICT, the difference is that the standalone vmwgfx uses an
 internal
 copy of drm core.
 It doesn't reuse the in-kernel drm, hence it cannot know which minor
 it can use.

 -Emil
>>>
>>> Actually, standalone vmwgfx could perhaps also try to allocate minors
>>> from 63 and downwards. That might work, but needs some verification.
>>>
>> So unfortuntately this doesn't work since the in-tree drm's file
>> operations
>> are registered with the DRM_MAJOR.
>> So I still think the patch is the way to go. If people are concerned
>> that
>> also fbdev file descriptors are allowed, perhaps there are other sysfs
>> traits we can look at?
>
> Somewhat out of curiosity, but why do you have to overwrite all of drm?
> amdgpu seems to be able to pull their stunt off without ...
> -Daniel

 At the time we launched the standalone vmwgfx, the DRM <-> driver
 interface was moving considerably more rapidly than the DRM <-> kernel
 interface. I think that's still the case. Hence less work for us. Also
 meant we can install the full driver stack with latest features on
 fairly old VMs without backported DRM functionality.

>>> I think this should be fine for 99% of drm usage, there may be corner
>>> cases in wierd places, but I can't point to any that really matter
>>> (maybe strace?)
>>>
>> Having a closer look, I think this will break the Firefox/Chrome
>> sandboxing :-\
>> I cannot see the path /sys/dev/char/%d:%d/device/drm in the allowed
>> list [1] [2].
>
> Thanks for pointing this out.
>
> The function drmGetMinorNameForFD() already opens this path, so any
> user-space using that function would not work before either.
>
> Also mozilla/firefox adds /sys/dev/char/226:* Which means that while it
> still won't work on standalone vmwgfx, there should at least be no
> regression.
>
> For Chromium it seems they allow /sys/dev/char/ for AmdGpu, but only under
> ChromOS, so I'll ping those to be safe.
>
> I also won't be doing an immediate release after pushing.
>
In that case, please give me 24h to do a libdrm release before pushing.
I had to push some workarounds for the sandboxing mentioned earlier :-\

Thanks
Emil
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu: Fix typo in warning message

[Paul Menzel]

From 0974a1477e9118fbf76b5c89e0c3e604c1acd7da Mon Sep 17 00:00:00 2001
From: Paul Menzel 
Date: Wed, 8 Aug 2018 16:23:30 +0200

Signed-off-by: Paul Menzel 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8ab5ccbc14ac..23f307f4ac44 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1005,7 +1005,7 @@ static void amdgpu_device_check_arguments(struct 
amdgpu_device *adev)
}
 
if (amdgpu_lockup_timeout == 0) {
-   dev_warn(adev->dev, "lockup_timeout msut be > 0, adjusting to 
1\n");
+   dev_warn(adev->dev, "lockup_timeout must be > 0, adjusting to 
1\n");
amdgpu_lockup_timeout = 1;
}
 
-- 
2.17.1



smime.p7s
Description: S/MIME Cryptographic Signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: two KASANs in TTM logic

[Tom St Denis]

Hi Christian,

Will in a sec.  I'm doing a piglit run with Felix's KFD patch on top of 
HEAD~ just to verify that everything before that is peachy on my 
Raven+Polaris rig.


Tom

On 09/05/2018 08:02 AM, Christian König wrote:
Still not the slightest idea what is causing this and the patch 
definitely fixes things a lot.


Can you try to enable list debugging in your kernel?

Thanks,
Christian.

Am 04.09.2018 um 19:18 schrieb Tom St Denis:

Sure:

d2917f399e0b250f47d07da551a335843a24f835 is the first bad commit
commit d2917f399e0b250f47d07da551a335843a24f835
Author: Christian König 
Date:   Thu Aug 30 10:04:53 2018 +0200

    drm/amdgpu: fix "use bulk moves for efficient VM LRU handling" v2

    First step to fix the LRU corruption, we accidentially tried to 
move things

    on the LRU after dropping the lock.

    Signed-off-by: Christian König 
    Tested-by: Michel Dänzer 

:04 04 ed5be1ad4da129c4154b2b43acf7ef349a470700 
0008c4e2fb56512f41559618dd474c916fc09a37 M  drivers



The commit before that I can run xonotic-glx and piglit on my Carrizo 
without a KASAN.


Tom

On 09/04/2018 10:05 AM, Christian König wrote:

The first one should already be fixed.

Not sure where the second comes from. Can you narrow that down further?

Christian.

Am 04.09.2018 um 15:46 schrieb Tom St Denis:

First is caused by this commit while running a GL heavy application.

d78c1fa0c9f815fe951fd57001acca3d35262a17 is the first bad commit
commit d78c1fa0c9f815fe951fd57001acca3d35262a17
Author: Michel Dänzer 
Date:   Wed Aug 29 11:59:38 2018 +0200

    Revert "drm/amdgpu: move PD/PT bos on LRU again"

    This reverts commit 31625ccae4464b61ec8cdb9740df848bbc857a5b.

    It triggered various badness on my development machine when 
running the

    piglit gpu profile with radeonsi on Bonaire, looks like memory
    corruption due to insufficiently protected list manipulations.

    Signed-off-by: Michel Dänzer 
    Signed-off-by: Alex Deucher 

:04 04 b7169f0cf0c7decec631751a9896a92badb67f9d 
42ea58f43199d26fc0c7ddcc655e6d0964b81817 M  drivers


The second is caused by something between that and the tip of the 
4.19-rc1 amd-staging-drm-next (I haven't pinned it down yet) while 
loading GNOME.


Tom



___
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: two KASANs in TTM logic

[Christian König]

Still not the slightest idea what is causing this and the patch 
definitely fixes things a lot.


Can you try to enable list debugging in your kernel?

Thanks,
Christian.

Am 04.09.2018 um 19:18 schrieb Tom St Denis:

Sure:

d2917f399e0b250f47d07da551a335843a24f835 is the first bad commit
commit d2917f399e0b250f47d07da551a335843a24f835
Author: Christian König 
Date:   Thu Aug 30 10:04:53 2018 +0200

    drm/amdgpu: fix "use bulk moves for efficient VM LRU handling" v2

    First step to fix the LRU corruption, we accidentially tried to 
move things

    on the LRU after dropping the lock.

    Signed-off-by: Christian König 
    Tested-by: Michel Dänzer 

:04 04 ed5be1ad4da129c4154b2b43acf7ef349a470700 
0008c4e2fb56512f41559618dd474c916fc09a37 M  drivers



The commit before that I can run xonotic-glx and piglit on my Carrizo 
without a KASAN.


Tom

On 09/04/2018 10:05 AM, Christian König wrote:

The first one should already be fixed.

Not sure where the second comes from. Can you narrow that down further?

Christian.

Am 04.09.2018 um 15:46 schrieb Tom St Denis:

First is caused by this commit while running a GL heavy application.

d78c1fa0c9f815fe951fd57001acca3d35262a17 is the first bad commit
commit d78c1fa0c9f815fe951fd57001acca3d35262a17
Author: Michel Dänzer 
Date:   Wed Aug 29 11:59:38 2018 +0200

    Revert "drm/amdgpu: move PD/PT bos on LRU again"

    This reverts commit 31625ccae4464b61ec8cdb9740df848bbc857a5b.

    It triggered various badness on my development machine when 
running the

    piglit gpu profile with radeonsi on Bonaire, looks like memory
    corruption due to insufficiently protected list manipulations.

    Signed-off-by: Michel Dänzer 
    Signed-off-by: Alex Deucher 

:04 04 b7169f0cf0c7decec631751a9896a92badb67f9d 
42ea58f43199d26fc0c7ddcc655e6d0964b81817 M  drivers


The second is caused by something between that and the tip of the 
4.19-rc1 amd-staging-drm-next (I haven't pinned it down yet) while 
loading GNOME.


Tom



___
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 v3 03/13] fbdev: add kerneldoc do remove_conflicting_framebuffers()

[Paul Menzel]

Dear Michał,


Thank you for documenting the function. Do you mean *to* instead of *do*
in the commit message summary?


On 09/01/18 16:08, Michał Mirosław wrote:
> Document remove_conflicting_framebuffers() behaviour.
> 
> Signed-off-by: Michał Mirosław 
> ---
>  drivers/video/fbdev/core/fbmem.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c 
> b/drivers/video/fbdev/core/fbmem.c
> index 0df148eb4699..2de93b5014e3 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1775,6 +1775,16 @@ int unlink_framebuffer(struct fb_info *fb_info)
>  }
>  EXPORT_SYMBOL(unlink_framebuffer);
>  
> +/**
> + * remove_conflicting_framebuffers - remove firmware-configured framebuffers
> + * @a: memory range, users of which are to be removed
> + * @name: requesting driver name
> + * @primary: also kick vga16fb if present
> + *
> + * This function removes framebuffer devices (initialized by 
> firmware/bootloader)
> + * which use memory range described by @a. If @a is NULL all such devices are
> + * removed.
> + */
>  int remove_conflicting_framebuffers(struct apertures_struct *a,
>   const char *name, bool primary)
>  {

Acked-by: Paul Menzel 


Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

[Thomas Hellstrom]

Hi, Emil,

On 09/05/2018 11:33 AM, Emil Velikov wrote:

On 4 September 2018 at 23:33, Dave Airlie  wrote:

On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom  wrote:

On 09/03/2018 06:33 PM, Daniel Vetter wrote:

On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:

On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:

On 08/31/2018 05:27 PM, Emil Velikov wrote:

On 31 August 2018 at 15:38, Michel Dänzer  wrote:

[ Adding the amd-gfx list ]

On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote:

On 08/31/2018 02:30 PM, Emil Velikov wrote:

On 31 August 2018 at 12:54, Thomas Hellstrom 
wrote:

To determine whether a device node is a drm device
node or not, the code
currently compares the node's major number to the static drm major
device
number.

This breaks the standalone vmwgfx driver on XWayland dri clients,


Any particular reason why the code doesn't use a fixed node there?
It will make the diff vs the in-kernel driver a bit smaller.

Because then it won't be able to interoperate with other in-tree
drivers, like virtual drm drivers or passthrough usb drm drivers.
There is no clean way to share the minor number allocation
with in-tree
drm, so standalone vmwgfx is using dynamic major allocation.

I wonder why I haven't heard of any of these issues with the standalone
version of amdgpu shipped in packaged AMD releases. Does that
also use a
different major number? If yes, maybe it's just that nobody has tried
Xwayland clients with that driver. If no, how does it avoid the other
issues described above?


AFAICT, the difference is that the standalone vmwgfx uses an internal
copy of drm core.
It doesn't reuse the in-kernel drm, hence it cannot know which minor
it can use.

-Emil

Actually, standalone vmwgfx could perhaps also try to allocate minors
from 63 and downwards. That might work, but needs some verification.


So unfortuntately this doesn't work since the in-tree drm's file operations
are registered with the DRM_MAJOR.
So I still think the patch is the way to go. If people are concerned that
also fbdev file descriptors are allowed, perhaps there are other sysfs
traits we can look at?

Somewhat out of curiosity, but why do you have to overwrite all of drm?
amdgpu seems to be able to pull their stunt off without ...
-Daniel

At the time we launched the standalone vmwgfx, the DRM <-> driver
interface was moving considerably more rapidly than the DRM <-> kernel
interface. I think that's still the case. Hence less work for us. Also
meant we can install the full driver stack with latest features on
fairly old VMs without backported DRM functionality.


I think this should be fine for 99% of drm usage, there may be corner
cases in wierd places, but I can't point to any that really matter
(maybe strace?)


Having a closer look, I think this will break the Firefox/Chrome sandboxing :-\
I cannot see the path /sys/dev/char/%d:%d/device/drm in the allowed
list [1] [2].

Thanks for pointing this out.

The function drmGetMinorNameForFD() already opens this path, so any 
user-space using that function would not work before either.


Also mozilla/firefox adds /sys/dev/char/226:* Which means that while it 
still won't work on standalone vmwgfx, there should at least be no 
regression.


For Chromium it seems they allow /sys/dev/char/ for AmdGpu, but only 
under ChromOS, so I'll ping those to be safe.


I also won't be doing an immediate release after pushing.

Thanks,
Thomas



Thomas, can you please send a patch to the respective teams or give
them a heads up?

Thanks
Emil



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

[PATCH xf86-video-ati 1/2] Always delete entry from list in drm_queue_handler

[Michel Dänzer]

From: Michel Dänzer 

We left entries without a handler hook in the list, so the list could
keep taking longer to process and use up more memory.

(Ported from amdgpu commit 7eea3e2cd74eed22e982319144e18ae5b1087b78)

Signed-off-by: Michel Dänzer 
---
 src/radeon_drm_queue.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/radeon_drm_queue.c b/src/radeon_drm_queue.c
index 857278fdd..61a2f5cef 100644
--- a/src/radeon_drm_queue.c
+++ b/src/radeon_drm_queue.c
@@ -82,7 +82,7 @@ radeon_drm_queue_handler(struct xorg_list *signalled, 
unsigned int frame,
 xorg_list_for_each_entry_safe(e, tmp, _drm_queue, list) {
if (e->seq == seq) {
if (!e->handler) {
-   e->abort(e->crtc, e->data);
+   radeon_drm_queue_handle_one(e);
break;
}
 
-- 
2.19.0.rc1

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

[PATCH xf86-video-ati 2/2] Don't use xorg_list_for_each_entry_safe for signalled flips

[Michel Dänzer]

From: Michel Dänzer 

drm_wait_pending_flip can get called from drm_handle_event, in which
case xorg_list_for_each_entry_safe can end up processing the same entry
in both. To avoid this, just process the first list entry until the list
is empty.

(Ported from amdgpu commit 26770be44b89b83bf39c28f2fe284c8cb92ed0c0)

Signed-off-by: Michel Dänzer 
---
 src/radeon_drm_queue.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/radeon_drm_queue.c b/src/radeon_drm_queue.c
index 61a2f5cef..bf1650ea9 100644
--- a/src/radeon_drm_queue.c
+++ b/src/radeon_drm_queue.c
@@ -257,8 +257,11 @@ radeon_drm_handle_event(int fd, drmEventContext 
*event_context)
 
 r = drmHandleEvent(fd, event_context);
 
-xorg_list_for_each_entry_safe(e, tmp, _drm_flip_signalled, list)
+while (!xorg_list_is_empty(_drm_flip_signalled)) {
+   e = xorg_list_first_entry(_drm_flip_signalled,
+ struct radeon_drm_queue_entry, list);
radeon_drm_queue_handle_one(e);
+}
 
 xorg_list_for_each_entry_safe(e, tmp, _drm_vblank_signalled, list) {
drmmode_crtc_private_ptr drmmode_crtc = e->crtc->driver_private;
@@ -277,12 +280,15 @@ void radeon_drm_wait_pending_flip(xf86CrtcPtr crtc)
 {
 drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
 RADEONEntPtr pRADEONEnt = RADEONEntPriv(crtc->scrn);
-struct radeon_drm_queue_entry *e, *tmp;
+struct radeon_drm_queue_entry *e;
 
 drmmode_crtc->wait_flip_nesting_level++;
 
-xorg_list_for_each_entry_safe(e, tmp, _drm_flip_signalled, list)
+while (!xorg_list_is_empty(_drm_flip_signalled)) {
+   e = xorg_list_first_entry(_drm_flip_signalled,
+ struct radeon_drm_queue_entry, list);
radeon_drm_queue_handle_one(e);
+}
 
 while (drmmode_crtc->flip_pending
   && radeon_drm_handle_event(pRADEONEnt->fd,
-- 
2.19.0.rc1

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

Re: [PATCH libdrm] libdrm: Allow dynamic drm majors on linux

[Emil Velikov]

On 4 September 2018 at 23:33, Dave Airlie  wrote:
> On Tue, 4 Sep 2018 at 03:00, Thomas Hellstrom  wrote:
>>
>> On 09/03/2018 06:33 PM, Daniel Vetter wrote:
>> > On Mon, Sep 03, 2018 at 11:16:29AM +0200, Thomas Hellstrom wrote:
>> >> On 08/31/2018 05:30 PM, Thomas Hellstrom wrote:
>> >>> On 08/31/2018 05:27 PM, Emil Velikov wrote:
>>  On 31 August 2018 at 15:38, Michel Dänzer  wrote:
>> > [ Adding the amd-gfx list ]
>> >
>> > On 2018-08-31 3:05 p.m., Thomas Hellstrom wrote:
>> >> On 08/31/2018 02:30 PM, Emil Velikov wrote:
>> >>> On 31 August 2018 at 12:54, Thomas Hellstrom 
>> >>> wrote:
>>  To determine whether a device node is a drm device
>>  node or not, the code
>>  currently compares the node's major number to the static drm major
>>  device
>>  number.
>> 
>>  This breaks the standalone vmwgfx driver on XWayland dri clients,
>> 
>> >>> Any particular reason why the code doesn't use a fixed node there?
>> >>> It will make the diff vs the in-kernel driver a bit smaller.
>> >> Because then it won't be able to interoperate with other in-tree
>> >> drivers, like virtual drm drivers or passthrough usb drm drivers.
>> >> There is no clean way to share the minor number allocation
>> >> with in-tree
>> >> drm, so standalone vmwgfx is using dynamic major allocation.
>> > I wonder why I haven't heard of any of these issues with the standalone
>> > version of amdgpu shipped in packaged AMD releases. Does that
>> > also use a
>> > different major number? If yes, maybe it's just that nobody has tried
>> > Xwayland clients with that driver. If no, how does it avoid the other
>> > issues described above?
>> >
>>  AFAICT, the difference is that the standalone vmwgfx uses an internal
>>  copy of drm core.
>>  It doesn't reuse the in-kernel drm, hence it cannot know which minor
>>  it can use.
>> 
>>  -Emil
>> >>> Actually, standalone vmwgfx could perhaps also try to allocate minors
>> >>> from 63 and downwards. That might work, but needs some verification.
>> >>>
>> >> So unfortuntately this doesn't work since the in-tree drm's file 
>> >> operations
>> >> are registered with the DRM_MAJOR.
>> >> So I still think the patch is the way to go. If people are concerned that
>> >> also fbdev file descriptors are allowed, perhaps there are other sysfs
>> >> traits we can look at?
>> > Somewhat out of curiosity, but why do you have to overwrite all of drm?
>> > amdgpu seems to be able to pull their stunt off without ...
>> > -Daniel
>>
>> At the time we launched the standalone vmwgfx, the DRM <-> driver
>> interface was moving considerably more rapidly than the DRM <-> kernel
>> interface. I think that's still the case. Hence less work for us. Also
>> meant we can install the full driver stack with latest features on
>> fairly old VMs without backported DRM functionality.
>>
>
> I think this should be fine for 99% of drm usage, there may be corner
> cases in wierd places, but I can't point to any that really matter
> (maybe strace?)
>
Having a closer look, I think this will break the Firefox/Chrome sandboxing :-\
I cannot see the path /sys/dev/char/%d:%d/device/drm in the allowed
list [1] [2].

Thomas, can you please send a patch to the respective teams or give
them a heads up?

Thanks
Emil

[1] 
https://hg.mozilla.org/releases/mozilla-beta/file/264fcd3206a6/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp
[2] 
https://chromium.googlesource.com/chromium/src/+/8655d49f657d3878c937f1387b3d31fa66c8e76a/content/gpu/gpu_sandbox_hook_linux.cc
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v2 xf86-video-amdgpu] Bail early from drm_wait_pending_flip if there's no pending flip

[Michel Dänzer]

From: Michel Dänzer 

No need to process any events in that case.

v2:
* Re-check drmmode_crtc->flip_pending after processing each event

Signed-off-by: Michel Dänzer 
---
 src/amdgpu_drm_queue.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amdgpu_drm_queue.c b/src/amdgpu_drm_queue.c
index ba841d1ef..035356234 100644
--- a/src/amdgpu_drm_queue.c
+++ b/src/amdgpu_drm_queue.c
@@ -284,7 +284,8 @@ void amdgpu_drm_wait_pending_flip(xf86CrtcPtr crtc)
 
drmmode_crtc->wait_flip_nesting_level++;
 
-   while (!xorg_list_is_empty(_drm_flip_signalled)) {
+   while (drmmode_crtc->flip_pending &&
+  !xorg_list_is_empty(_drm_flip_signalled)) {
e = xorg_list_first_entry(_drm_flip_signalled,
  struct amdgpu_drm_queue_entry, list);
amdgpu_drm_queue_handle_one(e);
-- 
2.19.0.rc1

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

CentOS 7 as hostos: gim error:(set_new_adapter:617) asic does not support SRIOV

[Acewind]

Hello!

I'm trying to use an AMD FirePro S7150 in a CentOS 7.3 system. Here is some
information regarding the setup:

[root@host001 /]# uname -r
3.10.0-514.el7.x86_64

[root@host001 /]# dmesg | grep gim
[ 10.887502] gim: loading out-of-tree module taints kernel.
[ 10.887809] gim: module verification failed: signature and/or required key
missing - tainting kernel
[ 10.60] gim info:(gim_init:144) Start AMD open source GIM
initialization
[ 10.64] gim info:(gim_init:147) GPU IOV MODULE - version 1.0.0-k
[ 10.66] gim info:(gim_init:149) Copyright (c) 2014-2017 AMD
Corporation.
[ 10.87] gim info:(init_config:305) INIT CONFIG
[ 10.888908] gim info:(set_new_adapter:614) curr allocated at
a0341a40
[ 10.888910] gim error:(set_new_adapter:617) asic does not support SRIOV
[ 10.888912] gim info:(gim_probe:86) AMD GIM probe: pf_count = 0


SRIOV is already enabled in BIOS.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

gim error:(set_new_adapter:791) fail to enable MSI

[Acewind]

I'm working on AMD FirePro S7150 GPU passthrough by SRIOV on CentOS 7.3
(kernel = 3.10.0-514).
According to the two patches from
https://github.com/GPUOpen-LibrariesAndSDKs/MxGPU-Virtualization, I have
patched the kernel and rebooted.
Iommu and sriov are both enabled, 8 VFs can be found.
But there's error from dmesg:  gim error:(set_new_adapter:791) fail to
enable MSI
And in win7 guests os, the AMD driver always show error code 43.
Are the two errors related? Or MSI error can be ignored?

[   10.859725] gim: loading out-of-tree module taints kernel.
[   10.860008] gim: module verification failed: signature and/or required
key missing - tainting kernel
[   10.861041] gim info:(gim_init:144) Start AMD open source GIM
initialization
[   10.861045] gim info:(gim_init:147) GPU IOV MODULE - version 1.0.0-k
[   10.861047] gim info:(gim_init:149) Copyright (c) 2014-2017 AMD
Corporation.
[   10.861069] gim info:(init_config:305) INIT CONFIG
[   10.861091] gim info:(set_new_adapter:614) curr allocated at
a0326a40
[   10.861092] gim info:(set_new_adapter:621) SRIOV is supported
[   10.861098] gim info:(set_new_adapter:629) found PCI bridge device
[   10.861100] gim info:(set_new_adapter:633) found: 00:2.0
[   10.861122] gim info:(set_new_adapter:650) mmio_base = c9000718
[   10.861130] gim info:(set_new_adapter:652) doorbell = c90007c0
[   10.861147] gim info:(set_new_adapter:654) pf.fb_va = c9004000
[   10.861159] gim info:(sriov_is_ari_enabled:164) PCI_SRIOV_CAP =
0x0002
[   10.861162] gim info:(sriov_is_ari_enabled:173) PCI_SRIOV_CTRL =
0x0010
[   10.861163] gim info:(sriov_is_ari_enabled:176) PCI_SRIOV_CTRL_ARI is
set --> ARI is supported
[   10.861167] gim info:(program_ari_mode:483) Read bif_strap8 = 0x0024
[   10.861169] gim info:(program_ari_mode:488) program_ari_mode - Set
ARI_Mode = PF_BUS
[   10.861171] gim info:(program_ari_mode:498) Write bif_strap8 = 0x0004
[   10.861173] gim info:(gim_read_rom_from_reg:222) Reading VBios from ROM
[   10.861290] gim info:(gim_read_vbios:284) VBIOS starts:  0x55, 0xaa
[   10.861292] gim info:(gim_read_vbios:287) VBios size is 0x1
[   10.861299] gim info:(gim_read_vbios:290) vbios allocated at
c90006d7d000
[   10.861301] gim info:(gim_read_rom_from_reg:222) Reading VBios from ROM
[   10.994958] gim info:(gim_read_vbios:298) BIOS Version Major 0xF Minor
0x31
[   10.994999] gim info:(gim_read_vbios:311) Valid video BIOS image,
[   10.995000] gim info:(gim_read_vbios:313) size = 0x1, check sum is
0x53b100
[   10.995011] gim info:(gim_post_vbios:344) Init Parser passed!, continue
[   10.995015] gim info:(atom_chk_asic_status:335) ATOM_CheckAsicStatus -
BIOS_SCRATCH_7 = 0x
[   10.995016] gim info:(atom_chk_asic_status:338) Isolate
ATOM_S7_ASIC_INIT_COMPLETE_MASK bit(s) = 0x
[   10.995018] gim info:(atom_chk_asic_status:341) RLC_CNTL = 0x
[   10.995019] gim info:(atom_chk_asic_status:343) Isolate
RLC_CNTL__RLC_ENABLE_F32_MASK = 0x
[   10.995020] gim info:(atom_chk_asic_status:350) ATOM_ASIC_NEED_POST
[   10.995021] gim info:(gim_post_vbios:347) Asic needs a VBios post
[   10.995022] gim info:(atom_post_vbios:200) ATOM_PostVBIOS: firmware_info
passed
[   10.995023] gim info:(atom_post_vbios:253) asic_init before, engine
clock = 7530; memory clock =1e848
[   11.320309] gim info:(atom_post_vbios:256) asic_init after
[   11.320312] gim info:(atom_post_vbios:263) atom_init_fan_cntl before
[   11.320313] gim info:(atom_post_vbios:265) atom_init_fan_cntl after
[   11.320314] gim info:(gim_post_vbios:353) Post INIT_ASIC successfully!
[   11.320327] gim info:(firmware_requires_update:512) SMU option ROM
version 0x111700
[   11.320328] gim info:(firmware_requires_update:513) versus patch version
0x111a00
[   11.320339] gim info:(firmware_requires_update:523) RLCV option ROM
version 113 versus patch version 113
[   11.320340] gim info:(firmware_requires_update:528) TOC found, update it
[   11.320341] gim info:(patch_firmware:579) Update smc_init table
[   11.882360] gim info:(patch_firmware:612) Update smu firmware
[   11.892326] gim info:(patch_firmware:630) Update TOC
[   11.896239] gim info:(gim_post_vbios:359) Asic needs firmware loaded
[   11.896241] gim info:(atom_post_vbios:200) ATOM_PostVBIOS: firmware_info
passed
[   11.896242] gim info:(atom_post_vbios:239) just load uCode
[   11.896243] gim info:(atom_post_vbios:253) asic_init before, engine
clock = 7530; memory clock =1e848
[   13.172548] gim info:(atom_post_vbios:256) asic_init after
[   13.172551] gim info:(atom_post_vbios:263) atom_init_fan_cntl before
[   13.172552] gim info:(atom_post_vbios:265) atom_init_fan_cntl after
[   13.172553] gim info:(gim_post_vbios:365) Post LOAD_FW successfully!
[   13.172554] gim info:(gim_post_vbios:366) Post VBIOS successfully!
[   13.172555] gim info:(set_new_adapter:701) gim_post_vbios done
[   13.172557] gim info:(set_new_adapter:739) Scheduler Time interval is
per-vf from XL
[   13.172557] gim 

Re: [PATCH 5/5] [RFC]drm: add syncobj timeline support v3

[Christian König]

Am 05.09.2018 um 05:36 schrieb zhoucm1:



On 2018年09月04日 17:20, Christian König wrote:

Am 04.09.2018 um 11:00 schrieb zhoucm1:



On 2018年09月04日 16:42, Christian König wrote:

Am 04.09.2018 um 10:27 schrieb zhoucm1:



On 2018年09月04日 16:05, Christian König wrote:

Am 04.09.2018 um 09:53 schrieb zhoucm1:

[SNIP]


How about this idea:
1. Each signaling point is a fence implementation with an rb 
node.
2. Each node keeps a reference to the last previously 
inserted node.

3. Each node is referenced by the sync object itself.
4. Before each signal/wait operation we do a garbage 
collection and remove the first node from the tree as long as 
it is signaled.


5. When enable_signaling is requested for a node we cascade 
that to the left using rb_prev.
    This ensures that signaling is enabled for the current 
fence as well as all previous fences.


6. A wait just looks into the tree for the signal point lower 
or equal of the requested sequence number.
After re-thought your idea, I think it doesn't work since there 
is no timeline value as a line:
signal pt value doesn't must be continues, which can be jump by 
signal operation, like 1, 4, 8, 15, 19, e.g. there are five 
singal_pt, 
signal_pt1->signal_pt4->signal_pt8->signal_pt15->signal_pt19, if 
a wait pt is 7, do you mean this wait only needs signal_pt1 and 
signal_pt4???  That's certainly not right, we need to make sure 
the timeline value is bigger than wait pt value, that means 
signal_pt8 is need for wait_pt7.


That can be defined as we like it, e.g. when a wait operation 
asks for 7 we can return 8 as well.
If defined this, then problem is coming again, if 8 is removed 
when garbage collection, you will return 15?


The garbage collection is only done for signaled nodes. So when 8 
is already garbage collected and 7 is asked we know that we don't 
need to return anything.
8 is a signaled node, waitA/signal operation do garbage collection, 
how waitB(7) know the garbage history?


Well we of course keep what the last garbage collected number is, 
don't we?


Since there is no timeline as a line, I think this is not right 
direction.


That is actually intended. There is no infinite timeline here, just 
a windows of the last not yet signaled fences.
No one said the it's a infinite timeline, timeline will stop 
increasing when syncobj is released.


Yeah, but the syncobj can live for a very very long time. Not having 
some form of shrinking it when fences are signaled is certainly not 
going to fly very far.

I will try to fix this problem.
btw, when I try your suggestion, I find it will be difficult to 
implement drm_syncobj_array_wait_timeout by your idea, since it needs 
first_signaled. if there is un-signaled syncobj, we will still 
register cb to timeline value change, then still back to need 
enble_signaling.


I don't full understand the problem here. When we need to wait for a 
fence it is obvious that we need to enable signaling. So what exactly is 
the issue?


BTW: I'm going to commit patches #1-#4 to drm-misc-next now if nobody is 
going to object.


Christian.



Thanks,
David Zhou


Regards,
Christian.



Anyway kref is a good way to solve the 'free' problem, I will try to 
use it improve my patch, of course, will refer your idea.:)


Thanks,
David Zhou


Otherwise you will never be able to release nodes from the tree 
since you always need to keep them around just in case somebody 
asks for a lower number.


Regards,
Christian.





The key is that as soon as a signal point is added adding a 
previous point is no longer allowed.

That's intention.

Regards,
David Zhou




7. When the sync object is released we use 
rbtree_postorder_for_each_entry_safe() and drop the extra 
reference to each node, but never call rb_erase!
    This way the rb_tree stays in memory, but without a root 
(e.g. the sync object). It only destructs itself when the 
looked up references to the nodes are dropped.
And here, who will destroy rb node since no one do 
enable_signaling, and there is no callback to free themselves.


The node will be destroyed when the last reference drops, not 
when enable_signaling is called.


In other words the sync_obj keeps the references to each tree 
object to provide the wait operation, as soon as the sync_obj is 
destroyed we don't need that functionality any more.


We don't even need to wait for anything to be signaled, this way 
we can drop all unused signal points as soon as the sync_obj is 
destroyed.


Only the used ones will stay alive and provide the necessary 
functionality to provide the signal for each wait operation.


Regards,
Christian.



Regards,
David Zhou


Well that is quite a bunch of logic, but I think that should 
work fine.
Yeah, it could work, simple timeline reference also can solve 
'free' problem.


I think this approach is still quite a bit better, 


e.g. you don't run into circle dependency problems, it needs 
less memory and each node has always the same size which means 
we can use a kmem_cache