> -----Original Message----- > From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@xxxxxxxxxxxxxxxxxxxxx] On > Behalf Of Gerd Hoffmann > Sent: Tuesday, June 27, 2017 2:13 PM > To: Alex Williamson <alex.williamson@xxxxxxxxxx> > Cc: Wang, Zhenyu Z <zhenyu.z.wang@xxxxxxxxx>; intel- > gfx@xxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Chen, Xiaoguang > <xiaoguang.chen@xxxxxxxxx>; Zhang, Tina <tina.zhang@xxxxxxxxx>; Kirti > Wankhede <kwankhede@xxxxxxxxxx>; Lv, Zhiyuan <zhiyuan.lv@xxxxxxxxx>; > intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx; Wang, Zhi A <zhi.a.wang@xxxxxxxxx> > Subject: Re: [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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
