Messages in this thread | | | From | "Chen, Xiaoguang" <> | Subject | RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf | Date | Fri, 19 May 2017 08:17:06 +0000 |
| |
Hi Gerd and Alex,
>-----Original Message----- >From: Gerd Hoffmann [mailto:kraxel@redhat.com] >Sent: Friday, May 19, 2017 4:05 PM >To: Alex Williamson <alex.williamson@redhat.com> >Cc: Chen, Xiaoguang <xiaoguang.chen@intel.com>; Tian, Kevin ><kevin.tian@intel.com>; linux-kernel@vger.kernel.org; zhenyuw@linux.intel.com; >Lv, Zhiyuan <zhiyuan.lv@intel.com>; intel-gvt-dev@lists.freedesktop.org; Wang, >Zhi A <zhi.a.wang@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
| |