Re: [PATCH 5/5] drm/amdgpu: immedially invalidate PTEs

["Christian König" <ckoenig.leichtzumerken@gmail.com>]

Hi Philip,

that is an expected result. You can only invalidate page tables without 
holding the reservation lock.

What you do here is adding a new mapping and that one needs to allocate 
a new page tables and won't work like this.

Regards,
Christian.

Am 12.12.19 um 15:38 schrieb Philip Yang:
> Hi Christian,
>
> FYI, remove amdgpu_bo_reserve(root, true) before calling 
> amdgpu_vm_bo_update_mapping, I got this warning backtrace:
>
>     [  182.390072] WARNING: CPU: 12 PID: 4376 at
>
> /home/yangp/git/compute_staging/kernel/drivers/gpu/drm/ttm/ttm_bo.c:1229
>     ttm_bo_validate+0x14d/0x1b0 [ttm]
>     [  182.390085] Modules linked in: fuse ip6table_filter ip6_tables
>     iptable_filter amdgpu amd_iommu_v2 gpu_sched ast drm_vram_helper
>     drm_ttm_helper ttm k10temp ip_tables x_tables i2c_piix4
>     [  182.390123] CPU: 12 PID: 4376 Comm: kfdtest Tainted: G        W
>     5.4.0-rc7-kfd-yangp #1
>     [  182.390133] Hardware name: GIGABYTE MZ01-CE0-00/MZ01-CE0-00, 
> BIOS F12
>     08/05/2019
>     [  182.390146] RIP: 0010:ttm_bo_validate+0x14d/0x1b0 [ttm]
>     [  182.390153] Code: 40 ff 52 18 8b 44 24 04 e9 4f ff ff ff 48 8b 
> 87 20
>     01 00 00 be ff ff ff ff 48 8d 78 60 e8 5b 3a e1 d4 85 c0 0f 85 e7 
> fe ff
>     ff <0f> 0b e9 e0 fe ff ff be 01 00 00 00 48 89 df e8 2f c4 ff ff 
> e9 19
>     [  182.390161] RSP: 0018:ffffab7a032f3990 EFLAGS: 00010246
>     [  182.390166] RAX: 0000000000000000 RBX: ffff943c59b37850 RCX:
>     ffff943c59b35000
>     [  182.390171] RDX: ffff943c539daf00 RSI: ffff943c56fb31d8 RDI:
>     ffff943c539db790
>     [  182.390178] RBP: ffff943c59b37830 R08: 0000000000000200 R09:
>     0000000000000000
>     [  182.390184] R10: 0000000000000000 R11: 00000000001fee0e R12:
>     ffffab7a032f3a50
>     [  182.390194] R13: 0000000000000200 R14: ffff943c59b37800 R15:
>     0000000000000000
>     [  182.390197] FS:  00007f0d27f41780(0000) GS:ffff943c9e900000(0000)
>     knlGS:0000000000000000
>     [  182.390203] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>     [  182.390209] CR2: 00007fba7a1010a0 CR3: 00000007f2624000 CR4:
>     00000000003406e0
>     [  182.390212] Call Trace:
>     [  182.390219]  ? rcu_read_lock_sched_held+0x52/0x80
>     [  182.390223]  ? _raw_spin_unlock+0x24/0x30
>     [  182.390267]  ? amdgpu_bo_do_create+0x4d1/0x5d0 [amdgpu]
>     [  182.390319]  amdgpu_vm_clear_bo+0x13d/0x3a0 [amdgpu]
>     [  182.390371]  ? amdgpu_vm_num_entries+0x1e/0x70 [amdgpu]
>     [  182.390424]  amdgpu_vm_update_ptes+0x561/0x5d0 [amdgpu]
>     [  182.390480]  amdgpu_vm_bo_update_mapping+0xfd/0x130 [amdgpu]
>     [  182.390530]  amdgpu_vm_bo_split_mapping+0x1ea/0x2c0 [amdgpu]
>     [  182.390591]  svm_range_map_to_gpus+0x160/0x310 [amdgpu]
>     [  182.390650]  kfd_register_svm+0xb8/0x2b0 [amdgpu]
>     [  182.390708]  kfd_ioctl_register_svm+0xe8/0x110 [amdgpu]
>     [  182.390765]  kfd_ioctl+0x232/0x3d0 [amdgpu]
>     [  182.390823]  ? kfd_ioctl_get_process_apertures_new+0x310/0x310
>     [amdgpu]
>     [  182.390838]  ? selinux_file_ioctl+0x153/0x210
>     [  182.390845]  do_vfs_ioctl+0xa2/0x6e0
>     [  182.390854]  ksys_ioctl+0x70/0x80
>     [  182.390862]  __x64_sys_ioctl+0x16/0x20
>     [  182.390869]  do_syscall_64+0x4a/0x1b0
>     [  182.390879]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Philip
>
> On 2019-12-12 3:51 a.m., Christian König wrote:
>> Hi Felix,
>>
>> yeah, I've also found a corner case which would raise a warning now.
>>
>> Need to rework how dependencies for the PTE update are generated.
>>
>> Going to take care of this in the next few days,
>> Christian.
>>
>> Am 12.12.19 um 01:20 schrieb Felix Kuehling:
>>> Hi Christian,
>>>
>>> Alex started trying to invalidate PTEs in the MMU notifiers and 
>>> we're finding that we still need to reserve the VM reservation for 
>>> amdgpu_sync_resv in amdgpu_vm_sdma_prepare. Is that sync_resv still 
>>> needed now, given that VM fences aren't in that reservation object 
>>> any more?
>>>
>>> Regards,
>>>   Felix
>>>
>>> On 2019-12-05 5:39, Christian König wrote:
>>>> When a BO is evicted immedially invalidate the mapped PTEs.
>>>>
>>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>>> ---
>>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 ++++++++++++++++-
>>>>   1 file changed, 16 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>> index 839d6df394fc..e578113bfd55 100644
>>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>>> @@ -2565,6 +2565,7 @@ void amdgpu_vm_bo_invalidate(struct 
>>>> amdgpu_device *adev,
>>>>                    struct amdgpu_bo *bo, bool evicted)
>>>>   {
>>>>       struct amdgpu_vm_bo_base *bo_base;
>>>> +    int r;
>>>>         /* shadow bo doesn't have bo base, its validation needs its 
>>>> parent */
>>>>       if (bo->parent && bo->parent->shadow == bo)
>>>> @@ -2572,8 +2573,22 @@ void amdgpu_vm_bo_invalidate(struct 
>>>> amdgpu_device *adev,
>>>>         for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
>>>>           struct amdgpu_vm *vm = bo_base->vm;
>>>> +        struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
>>>> +
>>>> +        if (bo->tbo.type != ttm_bo_type_kernel) {
>>>> +            struct amdgpu_bo_va *bo_va;
>>>> +
>>>> +            bo_va = container_of(bo_base, struct amdgpu_bo_va,
>>>> +                         base);
>>>> +            r = amdgpu_vm_bo_update(adev, bo_va,
>>>> +                        bo->tbo.base.resv != resv);
>>>> +            if (!r) {
>>>> +                amdgpu_vm_bo_idle(bo_base);
>>>> +                continue;
>>>> +            }
>>>> +        }
>>>>   -        if (evicted && bo->tbo.base.resv == 
>>>> vm->root.base.bo->tbo.base.resv) {
>>>> +        if (evicted && bo->tbo.base.resv == resv) {
>>>>               amdgpu_vm_bo_evicted(bo_base);
>>>>               continue;
>>>>           }
>>
> _______________________________________________
> 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