> -----Original Message----- > From: intel-gvt-dev [mailto:[email protected]] On > Behalf Of Gerd Hoffmann > Sent: Tuesday, June 27, 2017 2:13 PM > To: Alex Williamson <[email protected]> > Cc: Wang, Zhenyu Z <[email protected]>; intel- > [email protected]; [email protected]; Chen, Xiaoguang > <[email protected]>; Zhang, Tina <[email protected]>; Kirti > Wankhede <[email protected]>; Lv, Zhiyuan <[email protected]>; > [email protected]; Wang, Zhi A <[email protected]> > 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
