All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "Kuehling, Felix" <Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH] drm/amdgpu: fix potential VM faults
Date: Thu, 19 Sep 2019 18:51:12 +0200	[thread overview]
Message-ID: <2f65f219-79b8-8bd0-6acb-1477d921c7eb@gmail.com> (raw)
In-Reply-To: <fd47f3c6-a336-5a02-6ff2-3c24ad81dcb9-5C7GfCeVMHo@public.gmane.org>

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

Regards,
Christian.

Am 19.09.19 um 16:29 schrieb Kuehling, Felix:
> 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.
>
> Is this related to recoverable page fault handling? Do we need some more
> generic way to handle eviction of page tables and update the parent page
> directory (invalidate the corresponding PDE)?
>
> Regards,
>     Felix
>
> On 2019-09-19 4:41, Christian König wrote:
>> When we allocate new page tables under memory
>> pressure we should not evict old ones.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>>    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 b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index 70d45d48907a..8e44ecaada35 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -514,7 +514,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
>>    		.interruptible = (bp->type != ttm_bo_type_kernel),
>>    		.no_wait_gpu = bp->no_wait_gpu,
>>    		.resv = bp->resv,
>> -		.flags = TTM_OPT_FLAG_ALLOW_RES_EVICT
>> +		.flags = bp->type != ttm_bo_type_kernel ?
>> +			TTM_OPT_FLAG_ALLOW_RES_EVICT : 0
>>    	};
>>    	struct amdgpu_bo *bo;
>>    	unsigned long page_align, size = bp->size;

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

  parent reply	other threads:[~2019-09-19 16:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19  8:41 [PATCH] drm/amdgpu: fix potential VM faults Christian König
     [not found] ` <20190919084136.82658-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2019-09-19 12:45   ` Deucher, Alexander
2019-09-19 14:29   ` Kuehling, Felix
     [not found]     ` <fd47f3c6-a336-5a02-6ff2-3c24ad81dcb9-5C7GfCeVMHo@public.gmane.org>
2019-09-19 16:51       ` Christian König [this message]
2019-09-25 13:51   ` Liu, Monk
     [not found]     ` <MN2PR12MB393312A21B75620C726F18DF84870-rweVpJHSKTq/67K4VYF1uAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-09-25 14:04       ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f65f219-79b8-8bd0-6acb-1477d921c7eb@gmail.com \
    --to=ckoenig.leichtzumerken-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=Felix.Kuehling-5C7GfCeVMHo@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.