[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1495181089.627.33.camel@redhat.com>
Date: Fri, 19 May 2017 10:04:49 +0200
From: Gerd Hoffmann <kraxel@...hat.com>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: "Chen, Xiaoguang" <xiaoguang.chen@...el.com>,
"Tian, Kevin" <kevin.tian@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"zhenyuw@...ux.intel.com" <zhenyuw@...ux.intel.com>,
"Lv, Zhiyuan" <zhiyuan.lv@...el.com>,
"intel-gvt-dev@...ts.freedesktop.org"
<intel-gvt-dev@...ts.freedesktop.org>,
"Wang, Zhi A" <zhi.a.wang@...el.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.
cheers,
Gerd
Powered by blists - more mailing lists