> -----Original Message----- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Gerd Hoffmann > Sent: Tuesday, June 27, 2017 2:13 PM > To: Alex Williamson <alex.william...@redhat.com> > Cc: Wang, Zhenyu Z <zhenyu.z.w...@intel.com>; intel- > g...@lists.freedesktop.org; linux-kernel@vger.kernel.org; Chen, Xiaoguang > <xiaoguang.c...@intel.com>; Zhang, Tina <tina.zh...@intel.com>; Kirti > Wankhede <kwankh...@nvidia.com>; Lv, Zhiyuan <zhiyuan...@intel.com>; > intel-gvt-...@lists.freedesktop.org; Wang, Zhi A <zhi.a.w...@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-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
