From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753589AbdESIRX (ORCPT ); Fri, 19 May 2017 04:17:23 -0400 Received: from mga07.intel.com ([134.134.136.100]:54405 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751666AbdESIRS (ORCPT ); Fri, 19 May 2017 04:17:18 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,363,1491289200"; d="scan'208";a="1132476101" From: "Chen, Xiaoguang" To: Gerd Hoffmann , Alex Williamson CC: "Tian, Kevin" , "linux-kernel@vger.kernel.org" , "zhenyuw@linux.intel.com" , "Lv, Zhiyuan" , "intel-gvt-dev@lists.freedesktop.org" , "Wang, Zhi A" Subject: RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Thread-Topic: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Thread-Index: AQHSwAN47y043l0J90m8wsAsHWts2aHgTQ8AgAGNjMCAAazCQIAAU9qAgAD30YCAAIqCgIAJhcZQ///LVYCAACZvAIABMD1g//+Lz4CAAGhigIAAfLgAgARXT/CAAHIJgIABcqeQgAH05ICAAMZxEIAAWgmAgAEfcYCAAIcF0A== Date: Fri, 19 May 2017 08:17:06 +0000 Message-ID: References: <1493372130-27727-1-git-send-email-xiaoguang.chen@intel.com> <20170504100833.199bc8ba@t450s.home> <1493967331.371.53.camel@redhat.com> <20170505091115.7a680636@t450s.home> <1494509273.17970.12.camel@redhat.com> <20170511094526.164985ee@w520.home> <20170511205829.672854c3@t450s.home> <1494580325.14352.57.camel@redhat.com> <20170512103828.4a1378a1@t450s.home> <20170515114409.414d1fdb@w520.home> <20170517154331.1b465f69@w520.home> <20170518085601.51e3296a@w520.home> <1495181089.627.33.camel@redhat.com> In-Reply-To: <1495181089.627.33.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v4J8T9K8024937 Hi Gerd and Alex, >-----Original Message----- >From: Gerd Hoffmann [mailto:kraxel@redhat.com] >Sent: Friday, May 19, 2017 4:05 PM >To: Alex Williamson >Cc: Chen, Xiaoguang ; Tian, Kevin >; linux-kernel@vger.kernel.org; zhenyuw@linux.intel.com; >Lv, Zhiyuan ; intel-gvt-dev@lists.freedesktop.org; Wang, >Zhi A >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