[Intel-gfx] [RFC 08/10] drm/i915/vm_bind: userptr dma-resv changes

[Niranjana Vishwanathapura]

On Fri, Jul 08, 2022 at 03:20:01PM +0000, Hellstrom, Thomas wrote:
>On Fri, 2022-07-08 at 07:51 -0700, Niranjana Vishwanathapura wrote:
>> > Since we don't loop over the vm_bound_list, there is a need to
>> > check
>> > whether the rebind_list is empty here under the notifier_lock in
>> > read
>> > mode, and in that case, restart from eb_lookup_vmas(). That might
>> > also
>> > eliminate the need for the __EXEC3_USERPTR_USED flag?
>> >
>> > That will also catch any objects that were evicted between
>> > eb_lookup_vmas() where the rebind_list was last checked, and
>> > i915_gem_vm_priv_lock(), which prohibits further eviction, but if
>> > we
>> > want to catch these earlier (which I think is a good idea), we
>> > could
>> > check that the rebind_list is indeed empty just after taking the
>> > vm_priv_lock(), and if not, restart from eb_lookup_vmas().
>>
>> Yah, right, we need to check rebind_list here and if not empty,
>> restart
>> from lookup phase.
>> It is bit tricky with userptr here as the unbind happens during
>> submit_init() call after we scoop unbound vmas here, the vmas gets
>> re-added to rebind_list :(.
>
>Ugh.
>
>> I think we need a separate 'invalidated_userptr_list' here and we
>> iterate through it for submit_init() and submit_done() calls (yes,
>> __EXEC3_USERPTR_USED flag won't be needed then).
>> And, we call, eb_scoop_unbound_vmas() after calling
>> eb_lookup_persistent_userptr_vmas(), so that we scoop all unbound
>> vmas properly.
>>
>
>I'm not sure that will help much, because we'd also need to recheck the
>rebind_list and possibly restart after taking the vm_priv_lock, since
>objects can be evicted between the scooping and taking the
>vm_priv_lock. So then the userptrs will be caught by that check.

Yah, what I mentioned above is in addition to rechecking rebind_list and
restarting.

Niranjana

>
>/Thomas
>
>