[Intel-gfx] [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get the dma-buf

[Chen, Xiaoguang]

Hi, 

>-----Original Message-----
>From: intel-gvt-dev [mailto:intel-gvt-dev-bounces at lists.freedesktop.org] On
>Behalf Of Gerd Hoffmann
>Sent: Friday, June 02, 2017 11:24 PM
>To: Alex Williamson <alex.williamson at redhat.com>; Chen, Xiaoguang
><xiaoguang.chen at intel.com>
>Cc: Tian, Kevin <kevin.tian at intel.com>; intel-gfx at lists.freedesktop.org; linux-
>kernel at vger.kernel.org; zhenyuw at linux.intel.com; chris at chris-wilson.co.uk; Lv,
>Zhiyuan <zhiyuan.lv at intel.com>; intel-gvt-dev at lists.freedesktop.org; Wang, Zhi
>A <zhi.a.wang at intel.com>
>Subject: Re: [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get
>the dma-buf
>
>  Hi,
>
>> > When i915's dma-buf's release() callback is called it will try to
>> > free the gem object associated with the dma-buf if its ref count is
>> > 0. But in our case the ref count is 1 so no free callback is called
>> > so we can not release allocations there.
>
>Why the ref count is one?  
The gem object is created by us while creating the dma-buf(the ref count of the gem object is initialized to 1).
Later when user import the dma-buf the ref count of the gem object associate with the dma-buf will increased.
When user finished using the dma-buf it will decrease the ref count.
But the ref count of the gem object will become 1 when all the user finished using the dma-buf because we create the gem object(the test also showing this result).

Typically user only export a dma-buf(no gem object yet) then when user import the dma-buf then a gem object will be created.
But in our case we do not implement the dma-buf from scratch but calling the i915_gem_prime_export() where a gem object is an input parameter.

Chenxg


>Who holds a reference and why?
>Maybe it should be the other way around, i.e. the dmabuf holds a reference on
>the vgpu instance backing it, i.e. you can't delete the vgpu while dma-bufs exist?
>
>> We cannot simply say that the user isn't allowed to release them in
>> that order.
>
>Yep, not going to fly.  Can happen even unintentionally because we can pass
>around dmabufs to other processes.  Example: qemu passes dmabuf to spice-
>client, then qemu crashes.  mgmt fd is closed before dmabuf fd then.  The kernel
>must be able to handle that.
>
>cheers,
>  Gerd
>_______________________________________________
>intel-gvt-dev mailing list
>intel-gvt-dev at lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev