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

[Zhang, Tina]

> -----Original Message-----
> From: intel-gvt-dev [mailto:intel-gvt-dev-bounces at lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Tuesday, June 27, 2017 2:13 PM
> To: Alex Williamson <alex.williamson at redhat.com>
> Cc: Wang, Zhenyu Z <zhenyu.z.wang at intel.com>; intel-
> gfx at lists.freedesktop.org; linux-kernel at vger.kernel.org; Chen, Xiaoguang
> <xiaoguang.chen at intel.com>; Zhang, Tina <tina.zhang at intel.com>; Kirti
> Wankhede <kwankhede at nvidia.com>; 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: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf
> operations
> 
>   Hi,
> 
> > Hmm, I don't like that interface.  Can you cite examples of other
> > ioctls that behave this way?  It doesn't feel like an elegant user
> > interface; the user can get the dmabuf, but only after they query the
> > dmabuf, even though the get-dmabuf ioctl returns the same data as the
> > query-plane ioctl, but they can't get the dmabuf if the plane has
> > changed in the interim, which is not something the user can know.  Are
> > we causing our own problems with this model of cycling through dmabuf
> > fds?  We talked previously about an enum of plane types, primary and
> > cursor.  What if the user was simply able to get a dmabuf fd for each
> > of those and they queried the current plane information via those fds?
> > IOW, the fd is persistent and specific to a given plane type, but the
> > format within it is dynamic.
> 
> Will not work due to how dma-bufs are designed.
> 
> But, yes, the QUERY then GET split is ugly for a number of reasons.
> 
> 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.

> If so, then maybe we can let the kernel check whenever a dma-buf for the
> current plane exists?  And if that isn't the case hand out a dma- buf right away,
> without expecting userspace explicitly asking for it?
I think this is a good advice. We are going to try this idea and add some tracking logic to kernel mode.

> 
> That will simplify the interface and remove the race condition at the expense of
> some additional bookkeeping in the kernel.
In this case, maybe one ioctl like QUERY_PLAN is enough. We can block it this ioctl and return it when the fd and info are ready.

Thanks.
Tina


> 
> cheers,
>   Gerd
> 
> _______________________________________________
> intel-gvt-dev mailing list
> intel-gvt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev