Thank you Christian. An intentional use of invalid PTE setting sounds reasonable for debugger case. I wasn't able to understand because I though this is preparation work for page migration.
Hi Alex,
Please add some comments in the commit message to say that this is intentionally invalid PTE settings to generate no-retry interrupt and this is for debugger use case where we don't want endless translation retry. Endless translation retry is designed for page migration. A s_trap instruction will be inserted in the debugger case to let the wave to enter trap handler to save context.
Regards,
Oak
-----Original Message-----
From: Christian König <ckoenig.leichtzumerken@xxxxxxxxx>
Sent: Monday, November 18, 2019 8:47 AM
To: Zeng, Oak <Oak.Zeng@xxxxxxx>; Yang, Philip <Philip.Yang@xxxxxxx>; Sierra Guiza, Alejandro (Alex) <Alex.Sierra@xxxxxxx>; amd-gfx@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [PATCH] amd/amdgpu: force to trigger a no-retry-fault after a retry-fault
Hi Oak,
well your questions are really valid. This is a follow up from an internal discussion on how to handle the debug trap handler on Vega and newer.
The key missing information in the commit message is that we are intentionally using an invalid combination of flags (F and P set at the same time) to trigger a no-retry fault.
This is used with the debug trap handler to enter debugging when an application accesses an invalid address on the GPU.
Otherwise we would just re-try the access over and over again because the hardware thinks that this is for page migration.
Regards,
Christian.
Am 18.11.19 um 04:42 schrieb Zeng, Oak:
> Hi Philip/Alex,
>
> I found I can't understand this patch without more details in the commit message. Is this preparation work for the page migration? Why setting the translation further bit can force a no-retry-fault? Won't setting this bit cause UTCL2 treat the PTE as a PDE and continue to walk to the PTE that this PTE pointing to? But from the patch below, the next level of PTE (pseudoly the 5th level page table) is not set.
>
> Why this setting will cause the wave to enter trap handler? As I understand it, wave enters trap handler (saving context) either it encounter a s_trap instruction, or CP can initialize suspension to preempt the running waves, or context switch can be triggered by certain counter (monitored by SPI).
>
> Further question will be, what is the planned page migration process? Halt wave/save context -> migrate page/update page table-> restore wave?
>
> Also when I check navi10 GPUVM programming guide, it clearly says that currently the Translate Further (F) option cannot be used in concert with the PDE as PTE (P) option. But this patch set F and P.
>
> Sorry for too many questions.
>
> Regards,
> Oak
>
> -----Original Message-----
> From: amd-gfx <amd-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of
> Philip Yang
> Sent: Friday, November 15, 2019 1:04 PM
> To: Sierra Guiza, Alejandro (Alex) <Alex.Sierra@xxxxxxx>;
> amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH] amd/amdgpu: force to trigger a no-retry-fault
> after a retry-fault
>
> One suggestion below, move the flags setting for else path into else path looks better.
>
> Philip
>
> On 2019-11-15 12:43 p.m., Alex Sierra wrote:
>> After a retry-fault happens, the fault handler will modify the UTCL2
>> to set PTE bits to force a no-retry-fault. This will cause the wave
>> to enter the trap handler.
>>
>> Change-Id: I177102891f715068f15605957ff23b0cab862603
>> Signed-off-by: Alex Sierra <alex.sierra@xxxxxxx>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 13 +++++--------
>> 1 file changed, 5 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index 3c0bd6472a46..e4d1a8fc97d5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -3167,7 +3167,8 @@ bool amdgpu_vm_handle_fault(struct amdgpu_device *adev, unsigned int pasid,
>> uint64_t addr)
>> {
>> struct amdgpu_bo *root;
>> - uint64_t value, flags;
>> + uint64_t value = 0;
>> + uint64_t flags;
>> struct amdgpu_vm *vm;
>> long r;
>>
>> @@ -3200,13 +3201,9 @@ bool amdgpu_vm_handle_fault(struct amdgpu_device *adev, unsigned int pasid,
>> AMDGPU_PTE_SYSTEM;
>>
> >- flags = AMDGPU_PTE_VALID | AMDGPU_PTE_SNOOPED |
> >- AMDGPU_PTE_SYSTEM;
> >
>> if (amdgpu_vm_fault_stop == AMDGPU_VM_FAULT_STOP_NEVER) {
>> - /* Redirect the access to the dummy page */
>> - value = adev->dummy_page_addr;
>> - flags |= AMDGPU_PTE_EXECUTABLE | AMDGPU_PTE_READABLE |
>> - AMDGPU_PTE_WRITEABLE;
> > + /* Setting PTE flags to trigger a no-retry-fault */
> > + flags = AMDGPU_PTE_EXECUTABLE | AMDGPU_PDE_PTE |
> > + AMDGPU_PTE_TF;
> } else {
>> - value = 0;
> >+ flags = AMDGPU_PTE_VALID | AMDGPU_PTE_SNOOPED |
> >+ AMDGPU_PTE_SYSTEM;
> > }
>
>>
>> r = amdgpu_vm_bo_update_mapping(adev, vm, true, NULL, addr, addr
>> + 1,
>>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
