[PATCH] drm/vram-helper: turn on PRIME import/export

Christian König christian.koenig at amd.com
Thu Mar 2 13:45:22 UTC 2023


Am 02.03.23 um 14:37 schrieb Simon Ser:
> On Thursday, March 2nd, 2023 at 14:21, Christian König <christian.koenig at amd.com> wrote:
>
>> Am 02.03.23 um 11:14 schrieb Simon Ser:
>>
>>> On Thursday, March 2nd, 2023 at 08:11, Christian König christian.koenig at amd.com wrote:
>>>
>>>> Am 01.03.23 um 23:29 schrieb Simon Ser:
>>>>
>>>>> We don't populate gem_prime_import_sg_table so only DMA-BUFs
>>>>> exported from our own device can be imported. Still, this is useful
>>>>> to user-space.
>>>>> But what happens if one of your BOs is imported into another device?
>>>>> Is there a way to make this fail, always?
>> Well you could return an error from the attach callback if I'm not
>> completely mistaken.
> Hmm, but with GEM helpers this is handled by drm_gem_map_attach(). That
> function calls drm_gem_object_funcs.pin but doesn't pass along the
> dma_buf_attachment so there no way to reject the attach based on the
> other device there…
>
> Would it be unreasonable to add a drm_driver.gem_prime_attach hook? Or
> is there a better way to implement this?

That would be the mid layering we usually try hard to avoid.

Your obj doesn't implement the obj->funcs->get_sg_table() callback 
doesn't it? In this case drm_gem_map_dma_buf() would fail just a little 
bit later anyway.

What you could do is to add a check for the get_sg_table callback a bit 
earlier in drm_gem_map_attach() and if that's not implemented reject the 
attachment.

Regards,
Christian.


More information about the dri-devel mailing list