[Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

[Daniel Vetter]

On Thu, Jun 29, 2017 at 08:41:53AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > Does gvt track the live cycle of all dma-bufs it has handed out?
> > 
> > The V9 implementation does track the dma-bufs' live cycle. The
> > original idea was that leaving the dma-bufs' live cycle management to
> > user mode.
> 
> That is still the case, user space decides which dma-bufs it'll go keep
> cached.  But kernel space can see what user space is doing, so there is
> no need to explicitly tell the kernel whenever a cached dma-buf exists
> or not.

We do the same trick in drm_prime.c, keeping a cache of exported dma-buf
around for re-exporting. Since for prime sharing the use-case is almost
always re-importing as a drm gem buffer again we can then on re-import
also tell userspace whether it already has that buffer in it's userspace
buffer manager, but that's an additional optimization. With plain dma-buf
we could achieve the same by wiring up a real stat() implementation with
unique inode numbers (atm they all share the anon_inode singleton). But
thus far no one asked for that.

btw I'm lost a bit in the discussion (was on vacation), but I think all
the concerns I've noticed with the initial rfc have been raised already,
so things look good. I'll check the next rfc once that shows up.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch