AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Koenig, Christian" <Christian.Koenig-5C7GfCeVMHo@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 1/8] drm/amdgpu: fix ATC handling for Ryzen
Date: Wed, 3 Apr 2019 17:24:09 +0000	[thread overview]
Message-ID: <c2cfeddb-7217-2110-d335-824b0a22371c@amd.com> (raw)
In-Reply-To: <32035eda-563d-b26b-83a6-71db67c846e6-5C7GfCeVMHo@public.gmane.org>

Am 01.04.19 um 20:58 schrieb Kuehling, Felix:
> On 2019-04-01 2:03 p.m., Christian König wrote:
>> Am 01.04.19 um 19:59 schrieb Kuehling, Felix:
>>> On 2019-04-01 7:23 a.m., Christian König wrote:
>>>> Am 30.03.19 um 01:41 schrieb Kuehling, Felix:
>>>>> Patches 1-3 are Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
>>>> Thanks.
>>>>
>>>>> About the direct mode, that removes a bunch of synchronization, so it
>>>>> must make some assumptions about the state of the page tables. What
>>>>> makes that safe?
>>>> Direct mode is only supposed to be used during page fault handling.
>>>>
>>>> E.g. we know that the page tables are in the correct place in this
>>>> situation because the hardware is hammering on a PTE and waiting for
>>>> it to become valid.
>>> A fence could also indicate a concurrent modification of the page table.
>>> For example a PTB may be allocated and initialized concurrently, not in
>>> direct mode. Would direct mode need to wait for a fence that indicates
>>> completion of the PTB initialization? Or do we have some way to ensure
>>> such concurrent allocation and initialization of a PTB cannot happen?
>> Yeah, that is a very good question I haven't solved yet either.
>>
>> My currently best idea is to separate the address space, e.g. use the
>> lower address space for on demand paging and the higher with classic
>> pre-filled page tables for the MM and display engines.
> That may work for graphics, but doesn't work for KFD. I need the ability
> to mix pre-filled page tables with HMM in the same SVM address space.

Even after thinking for multiple days about it I can't of hand find a 
way to make this work.

> That's why I was thinking that all page table updates for a given VM
> would need to use the same method.

Well what exactly do you mean with that? Essentially there are two methods:

1. Pre-fill the page tables before accessing them with the hardware.

2. Fill on demand with page faults.

I don't think we can mix those two methods together in the same address 
range.

E.g. we can say to use pre-fill for MM engines in the upper range and on 
demand filling in the lower range, but we can't mix them.

Regards,
Christian.

>
> Regards,
>     Felix
>
>> Christian.
>>
>>> Regards,
>>>      Felix
>>>
>>>
>>>> Christian.
>>>>
>>>>>     Is it safe to use direct-mode on a
>>>>> per-page-table-update basis? Or do all page table updates have to go
>>>>> through direct mode to avoid hazards? If yes, then maybe this
>>>>> should be
>>>>> a property of the VM rather than a parameter that gets passed to a
>>>>> bunch
>>>>> of function calls.
>>>>>
>>>>> Regards,
>>>>>       Felix
>>>>>
>>>>> On 2019-03-29 6:45 a.m., Christian König wrote:
>>>>>> Otherwise we don't correctly use translate further.
>>>>>>
>>>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>>>> ---
>>>>>>      drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 13 ++++++++-----
>>>>>>      1 file changed, 8 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>>>> index 3d221f044183..059d9802e713 100644
>>>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>>>> @@ -767,14 +767,17 @@ static int amdgpu_vm_clear_bo(struct
>>>>>> amdgpu_device *adev,
>>>>>>             addr = 0;
>>>>>>          if (ats_entries) {
>>>>>> -        uint64_t ats_value;
>>>>>> +        uint64_t value = 0, flags;
>>>>>>      -        ats_value = AMDGPU_PTE_DEFAULT_ATC;
>>>>>> -        if (level != AMDGPU_VM_PTB)
>>>>>> -            ats_value |= AMDGPU_PDE_PTE;
>>>>>> +        flags = AMDGPU_PTE_DEFAULT_ATC;
>>>>>> +        if (level != AMDGPU_VM_PTB) {
>>>>>> +            /* Handle leaf PDEs as PTEs */
>>>>>> +            flags |= AMDGPU_PDE_PTE;
>>>>>> +            amdgpu_gmc_get_vm_pde(adev, level, &value, &flags);
>>>>>> +        }
>>>>>>                 r = vm->update_funcs->update(&params, bo, addr, 0,
>>>>>> ats_entries,
>>>>>> -                         0, ats_value);
>>>>>> +                         value, flags);
>>>>>>              if (r)
>>>>>>                  return r;
>>> _______________________________________________
>>> 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

  parent reply	other threads:[~2019-04-03 17:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-29 10:45 [PATCH 1/8] drm/amdgpu: fix ATC handling for Ryzen Christian König
     [not found] ` <20190329104507.2602-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2019-03-29 10:45   ` [PATCH 2/8] drm/amdgpu: handle leaf PDEs as PTEs on Vega Christian König
2019-03-29 10:45   ` [PATCH 3/8] drm/amdgpu: provide the page fault queue to the VM code Christian König
     [not found]     ` <20190329104507.2602-3-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2019-03-29 14:23       ` Alex Deucher
     [not found]         ` <CADnq5_Mv5dVc2o5yvnFRJXLAwxuv5ysFLOLGc9OTWeiVBZAeZA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-03-29 14:24           ` Christian König
2019-03-29 10:45   ` [PATCH 4/8] drm/amdgpu: allow direct submission in the VM backends Christian König
2019-03-29 10:45   ` [PATCH 5/8] drm/amdgpu: allow direct submission of PDE updates Christian König
2019-03-29 10:45   ` [PATCH 6/8] drm/amdgpu: allow direct submission of PTE updates Christian König
2019-03-29 10:45   ` [PATCH 7/8] drm/amdgpu: allow direct submission of clears Christian König
2019-03-29 10:45   ` [PATCH 8/8] drm/amdgpu: add graceful VM fault handling Christian König
2019-03-30  0:41   ` [PATCH 1/8] drm/amdgpu: fix ATC handling for Ryzen Kuehling, Felix
     [not found]     ` <9cd61a18-fe16-f5aa-5b61-fef6d91d143b-5C7GfCeVMHo@public.gmane.org>
2019-04-01 11:23       ` Christian König
     [not found]         ` <7317b472-f24a-346a-7e6c-97c98b04e600-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-04-01 17:59           ` Kuehling, Felix
     [not found]             ` <ba45371a-7ea9-5144-c3c9-c59f93b434d8-5C7GfCeVMHo@public.gmane.org>
2019-04-01 18:03               ` Christian König
     [not found]                 ` <a40597e6-1f76-583b-55ad-089dcd9eeed4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-04-01 18:58                   ` Kuehling, Felix
     [not found]                     ` <32035eda-563d-b26b-83a6-71db67c846e6-5C7GfCeVMHo@public.gmane.org>
2019-04-03 17:24                       ` Koenig, Christian [this message]
     [not found]                         ` <c2cfeddb-7217-2110-d335-824b0a22371c-5C7GfCeVMHo@public.gmane.org>
2019-04-03 21:41                           ` Kuehling, Felix

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=c2cfeddb-7217-2110-d335-824b0a22371c@amd.com \
    --to=christian.koenig-5c7gfcevmho@public.gmane.org \
    --cc=Felix.Kuehling-5C7GfCeVMHo@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox