Hi Gerd and Alex, >-----Original Message----- >From: Gerd Hoffmann [mailto:[email protected]] >Sent: Friday, May 19, 2017 4:05 PM >To: Alex Williamson <[email protected]> >Cc: Chen, Xiaoguang <[email protected]>; Tian, Kevin ><[email protected]>; [email protected]; [email protected]; >Lv, Zhiyuan <[email protected]>; [email protected]; Wang, >Zhi A <[email protected]> >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
