/a the root cause.
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: amd-gfx On Behalf Of Christian
K?nig
Sent: Thursday, September 19, 2019 4:42 PM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix potential VM faults
When we
|GPU Virtualization Team |AMD
-Original Message-
From: amd-gfx On Behalf Of Christian
K?nig
Sent: Thursday, September 19, 2019 4:42 PM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix potential VM faults
When we allocate new page tables under memory pressure we should
If the page tables are reserved or fenced while you allocate a new one, they
would not be evicted.
And exactly that's not correct. The TTM_OPT_FLAG_ALLOW_RES_EVICT flag
allows evicting of reserved objects.
This is useful for allocating per VM BOs, but is of course completely
fatal in all
I'm not disagreeing with the change. Just trying to understand how this
could have caused a VM fault. If the page tables are reserved or fenced
while you allocate a new one, they would not be evicted. If they are not
reserved or fenced, there should be no expectation that they stay resident.
Acked-by: Alex Deucher
From: amd-gfx on behalf of Christian
König
Sent: Thursday, September 19, 2019 4:41 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: fix potential VM faults
When we allocate new page tables under memory
pressure we
When we allocate new page tables under memory
pressure we should not evict old ones.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
