a quetion about buffer migration for user mapped bo.

[Christian König]

Yes, Andrey is right.

A top level explanation is that we don't prevent moving the buffer but 
rather we prevent user space from accessing it.

Regards,
Christian.

Am 05.04.21 um 18:34 schrieb Andrey Grodzovsky:
>
> From my understanding and looking at the code I think we don't prevent 
> but rather invalidate current user mappings and use subsequent page 
> faults to map into user space process the pages from the new location. 
> Check what this function is doing during move - 
> https://elixir.bootlin.com/linux/v5.12-rc5/source/drivers/gpu/drm/ttm/ttm_bo.c#L238
>
> Andrey
>
> On 2021-04-05 12:01 p.m., 258454946 wrote:
>> Hi Guys,
>>
>> I am a newbee of gfx development. Recently, I am researching amdgpu 
>> open source driver, and encounter a problem, but do not find the answer.
>>
>> We know the user maybe map a gem backing buffer for reading/writing 
>> and hold the mapping for a long term. while, kernel driver will also 
>> moves the user mapped bo to other memory region. vram ->gtt, 
>> gtt->vram, even it may be swaped out under OOM case.
>>
>> So, my question is how driver prevents kernel ttm from moving the 
>> user mapped bo while user is accessing it?
>>
>> Thanks for your attention!
>>
>> Lizhi.
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20210406/f7111368/attachment-0001.htm>