Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

From: Gerd Hoffmann <kraxel@redhat.com>
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" <linux-kernel@vger.kernel.org>,
	"zhenyuw@linux.intel.com" <zhenyuw@linux.intel.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	"intel-gvt-dev@lists.freedesktop.org" 
	<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
Date: Fri, 19 May 2017 10:04:49 +0200	[thread overview]
Message-ID: <1495181089.627.33.camel@redhat.com> (raw)
In-Reply-To: <20170518085601.51e3296a@w520.home>

  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