Hi Gerd and Alex, >-----Original Message----- >From: Gerd Hoffmann [mailto:kra...@redhat.com] >Sent: Friday, May 19, 2017 4:05 PM >To: Alex Williamson <alex.william...@redhat.com> >Cc: Chen, Xiaoguang <xiaoguang.c...@intel.com>; Tian, Kevin ><kevin.t...@intel.com>; linux-kernel@vger.kernel.org; zhen...@linux.intel.com; >Lv, Zhiyuan <zhiyuan...@intel.com>; intel-gvt-...@lists.freedesktop.org; Wang, >Zhi A <zhi.a.w...@intel.com> >Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf > > Hi, > >> > User space need to check whether there's a dmabuf for the plane(user space >usually cached two or three dmabuf to handle double buffer or triple buffer >situation) only there's no dmabuf for the plane we will create a dmabuf for >it(another ioctl). >> >> If our ioctls are "Query current plane" and "Give me a dmabuf for >> current plane", isn't that racey? The current plane could have >> changed between those two calls so the user doesn't absolutely know >> which plane the dmabuf retrieved is for. The "Give me a dmabuf" >> therefore needs to take some sort of plane index so the user can >> request a specific plane. > >The "give me a dmabuf" ioctl returns the plane description too, so userspace >can >at least figure it did hit the race window. > >We could also do it the other way around: Instead of having the kernel >returning >the plane description userspace could pass it in, and the kernel throws >-EINVAL in >case it doesn't match due to things having changed meanwhile. Or just return a dmabuf based on the current plane ? Because if user got -EINVAL while ioctl "Give me a dmabuf" user should do the ioctl again.
> >cheers, > Gerd
