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

[Simon Ser]

On Thursday, March 2nd, 2023 at 14:45, Christian König <christian.koenig at amd.com> wrote:

> 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.

Indeed!

> 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.

That's a good idea, thanks for the suggestion! Done in v2.