Re: [PATCH] drm/ttm: Don't delete the system manager before the delayed delete

["Christian König" <christian.koenig@amd.com>]

Am 23.09.21 um 15:53 schrieb Zack Rusin:
> On 9/20/21 10:59 AM, Zack Rusin wrote:
>>> On Sep 20, 2021, at 02:30, Christian König 
>>> <christian.koenig@amd.com> wrote:
>>>
>>> Am 17.09.21 um 19:53 schrieb Zack Rusin:
>>>> On some hardware, in particular in virtualized environments, the
>>>> system memory can be shared with the "hardware". In those cases
>>>> the BO's allocated through the ttm system manager might be
>>>> busy during ttm_bo_put which results in them being scheduled
>>>> for a delayed deletion.
>>>
>>> While the patch itself is probably fine the reasoning here is a 
>>> clear NAK.
>>>
>>> Buffers in the system domain are not GPU accessible by definition, 
>>> even in a shared environment and so *must* be idle.
>>
>> I’m assuming that means they are not allowed to be ever fenced then, 
>> yes?
>
> Any thoughts on this? I'd love a confirmation because it would mean I 
> need to go and rewrite the vmwgfx_mob.c bits where we use 
> TTM_PL_SYSTEM memory (through vmw_bo_create_and_populate) for a page 
> table which is read by the host, and those bo's need to be fenced to 
> prevent destruction of the page tables while the memory they point to 
> is still used. So if those were never allowed to be fenced in the 
> first place we probably need to add a new memory type to hold those 
> page tables.

Yeah, as far as I can see that is pretty much illegal from a design 
point of view.

We could probably change that rule on the TTM side, but I think that 
keeping the design as it is and adding a placement in vmwgfx sounds like 
the cleaner approach.

Christian.

>
> z