why we unreserve MQD of KIQ ?

[Liu, Monk]

Thanks Alex

_____________________________________
Monk Liu|GPU Virtualization Team |AMD
[sig-cloud-gpu]

From: Alex Deucher <alexdeucher at gmail.com>
Sent: Tuesday, November 26, 2019 4:34 AM
To: Liu, Monk <Monk.Liu at amd.com>
Cc: Koenig, Christian <Christian.Koenig at amd.com>; amd-gfx at lists.freedesktop.org
Subject: Re: why we unreserve MQD of KIQ ?



On Mon, Nov 25, 2019 at 4:05 AM Liu, Monk <Monk.Liu at amd.com<mailto:Monk.Liu at amd.com>> wrote:
commit a9a8a788e5e946a9835a1365256fc4ce9e96ba2c
Author: Rex Zhu <Rex.Zhu at amd.com<mailto:Rex.Zhu at amd.com>>
Date:   Wed Aug 22 18:54:45 2018 +0800

    drm/amdgpu: Change kiq ring initialize sequence on gfx9

    1. initialize kiq before initialize gfx ring.
    2. set kiq ring ready immediately when kiq initialize
       successfully.
    3. split function gfx_v9_0_kiq_resume into two functions.
         gfx_v9_0_kiq_resume is for kiq initialize.
         gfx_v9_0_kcq_resume is for kcq initialize.

    Reviewed-by: Alex Deucher <alexander.deucher at amd.com<mailto:alexander.deucher at amd.com>>
    Signed-off-by: Rex Zhu <Rex.Zhu at amd.com<mailto:Rex.Zhu at amd.com>>
    Signed-off-by: Alex Deucher <alexander.deucher at amd.com<mailto:alexander.deucher at amd.com>>

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 21e66f8..3594704a 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -2684,7 +2684,6 @@ static int gfx_v9_0_kiq_kcq_enable(struct amdgpu_device *adev)
                queue_mask |= (1ull << i);
        }

-       kiq_ring->ready = true;
        r = amdgpu_ring_alloc(kiq_ring, (7 * adev->gfx.num_compute_rings) + 8);
        if (r) {
                DRM_ERROR("Failed to lock KIQ (%d).\n", r);
@@ -3091,26 +3090,33 @@ static int gfx_v9_0_kcq_init_queue(struct amdgpu_ring *ring)

static int gfx_v9_0_kiq_resume(struct amdgpu_device *adev)
{
-       struct amdgpu_ring *ring = NULL;
-       int r = 0, i;
-
-       gfx_v9_0_cp_compute_enable(adev, true);
+       struct amdgpu_ring *ring;
+       int r;

        ring = &adev->gfx.kiq.ring;

        r = amdgpu_bo_reserve(ring->mqd_obj, false);
        if (unlikely(r != 0))
-               goto done;
+               return r;

        r = amdgpu_bo_kmap(ring->mqd_obj, (void **)&ring->mqd_ptr);
-       if (!r) {
-               r = gfx_v9_0_kiq_init_queue(ring);
-               amdgpu_bo_kunmap(ring->mqd_obj);
-               ring->mqd_ptr = NULL;
-       }
+       if (unlikely(r != 0))
+               return r;
+
+       gfx_v9_0_kiq_init_queue(ring);
+       amdgpu_bo_kunmap(ring->mqd_obj);  //not invoked before change
+       ring->mqd_ptr = NULL;                             //not invoked before change
        amdgpu_bo_unreserve(ring->mqd_obj); //not invoked before change
-       if (r)
-               goto done;
+       ring->ready = true;
+       return 0;
+}
+
+static int gfx_v9_0_kcq_resume(struct amdgpu_device *adev)
+{

Hi guys

I found in last year, Rex submitted a change which introduced additional “amdgpu_bo_kunmap() and amdgpu_bo_unreserve()”
During the kiq_resume() routine,

I’m wondering why we need this change and I’m also suspecting it has potential regression:
See that the KIQ’s mqd  object is unreserved, so it now available in LRU which means TTM can evict it by will,

But the MQD of KIQ is supposed to be pinned otherwise incorrect memory access would introduced by a world switch
Since MEC always consider KIQ’ MQD is pinned

@Koenig, Christian<mailto:Christian.Koenig at amd.com> you know about that change’s background ?


I think the unreserve here is just to match the reserve at the top of this function for the kmapping.  It should still be pinned because we call amdgpu_bo_create_kernel() to allocate it.

Alex

_____________________________________
Monk Liu|GPU Virtualization Team |AMD
[sig-cloud-gpu]

_______________________________________________
amd-gfx mailing list
amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7CMonk.Liu%40amd.com%7C89db24b863e343d560d708d771e6e595%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637103108837716631&sdata=AvkmJmyFovEOff7%2FBowMktww%2BltLEfYlgBUwmnPHM2I%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20191126/0cb223ea/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 12243 bytes
Desc: image001.png
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20191126/0cb223ea/attachment-0001.png>