From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations Date: Mon, 26 Jun 2017 08:39:17 +0200 Message-ID: <1498459157.20591.6.camel@redhat.com> References: <1497513611-2814-1-git-send-email-xiaoguang.chen@intel.com> <1497513611-2814-6-git-send-email-xiaoguang.chen@intel.com> <1497542438.29252.1.camel@redhat.com> <20170615143833.7526351b@w520.home> <24c4880b-24f5-ea07-834c-c77d3e895c78@nvidia.com> <1497854312.4207.4.camel@redhat.com> <20170619085530.1f5e46dc@w520.home> <237F54289DF84E4997F34151298ABEBC7C56EBE0@SHSMSX101.ccr.corp.intel.com> <1497956256.16795.7.camel@redhat.com> <237F54289DF84E4997F34151298ABEBC7C5731B3@SHSMSX101.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <237F54289DF84E4997F34151298ABEBC7C5731B3@SHSMSX101.ccr.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: "Zhang, Tina" , Alex Williamson Cc: "Wang, Zhenyu Z" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "Chen, Xiaoguang" , Kirti Wankhede , "Lv, Zhiyuan" , "intel-gvt-dev@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org ICBIaSwKCj4gPiBXaXRoIHRoZSBnZW5lcmF0aW9uIHdlIGNhbiBhbHNvIGRvIHNvbWV0aGluZyBk aWZmZXJlbnQ6wqDCoFBhc3MgaW4KPiA+IHBsYW5lX3R5cGUgYW5kCj4gPiBnZW5lcmF0aW9uLCBh bmQgaGF2ZSBWRklPX0RFVklDRV9HRVRfRE1BQlVGX0ZEIHJldHVybiBhbiBlcnJvciBpbgo+ID4g Y2FzZQo+ID4gdGhlIGdlbmVyYXRpb24gZG9lc24ndCBtYXRjaC7CoMKgSW4gdGhhdCBjYXNlIGl0 IGRvZXNuJ3QgbWFrZSBtdWNoCj4gPiBzZW5zZSBhbnkKPiA+IG1vcmUgdG8gaGF2ZSBhIHNlcGFy YXRlIHBsYW5lX2luZm8gc3RydWN0LCB3aGljaCB3YXMgYWRkZWQgc28gd2UKPiA+IGRvbid0IGhh dmUKPiA+IHRvIGR1cGxpY2F0ZSB0aGluZ3MgaW4gcXVlcnktcGxhbmUgYW5kIGdldC0gZG1hYnVm IGlvY3RsIHN0cnVjdHMuCj4gCj4gQ29tcGFyaW5nIHdpdGggdGhlIGN1cnJlbnQgcGF0Y2gsIHRo aXMgd291bGQgbWFrZSB1c2VyIHNwYWNlIGEgbGl0dGxlCj4gYml0IGhhcmRlciB0bwo+IGdldCB0 aGUgZG1hYnVmIGJ5IGNhbGxpbmcgVkZJT19ERVZJQ0VfR0VUX0RNQUJVRiBpb2N0bC4gSXMgaXQK PiBlZmZpY2llbnQgZm9yCj4gdXNlciBtb2RlIHVzYWdlPwoKdXNlciBzcGFjZSBoYXMgdG8gY2Fs bCBRVUVSWS1QTEFORSBmaXJzdCwgdGhlbiBsb29rcyBpZiBpdCBoYXMgYSBkbWEtCmJ1ZiBmb3Ig dGhhdCwgaWYgbm90IGNhbGwgR0VULURNQUJVRi4KClByb2JsZW0gaXMgdGhlIGd1ZXN0IGNvdWxk IGhhdmUgY2hhbmdlZCB0aGUgcGxhbmUgYmV0d2VlbiB0aGUgUVVFUlktClBMQU5FIGFuZCBHRVQt RE1BQlVGIGlvY3Rscy4KCkN1cnJlbnQgcGF0Y2hlcyAodjggc2VyaWVzKSBqdXN0IHJldHVybnMg cGxhbmUtaW5mbyBvbiBHRVQtRE1BQlVGIHRvbywKc28gdXNlcnNwYWNlIGNhbiBhdCBsZWFzdCBk ZXRlY3Qgc29tZXRoaW5nIGNoYW5nZWQuCgpJdCB3b3VsZCBiZSBlYXNpZXIgZm9yIHVzZXJzcGFj ZSBpZiBHRVQtRE1BQlVGIHRocm93cyBhbiBlcnJvciBpbiBjYXNlCnRoZSBwbGFuZSBjaGFuZ2Vk IHNpbmNlIHRoZSBsYXN0IFFVRVJZLVBMQU5FIGlvY3RsLiAgVGhlIGdlbmVyYXRpb24gaWQKd291 bGQgYmUgb25lIHdheSB0byBoYW5kbGUgaXQsIGJ1dCBwb3NzaWJseSBpdCBpcyBlYXNpZXIgaWYg dGhlIGtlcm5lbApkcml2ZXIganVzdCBrZWVwcyB0cmFjayBpbnRlcm5hbGx5LiAgU28gR0VULURN QUJVRiB3b3VsZCBiZSBkZWZpbmVkIHRvCnJldHVybiBhIGRtYWJ1ZiBmb3IgdGhlIHBsYW5lIHJl dHVybmVkIGJ5IHRoZSBwcmV2aW91cyBRVUVSWS1QTEFORQppb2N0bCAob24gdGhlIHNhbWUgZmls ZSBoYW5kbGUpLCBvciByZXR1cm4gYW4gZXJyb3IgaW4gY2FzZSB0aGUgcGxhbmUKaGFzIGNoYW5n ZWQgbWVhbndoaWxlLgoKY2hlZXJzLAogIEdlcmQKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCkludGVsLWdmeCBtYWlsaW5nIGxpc3QKSW50ZWwtZ2Z4QGxp c3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ludGVsLWdmeAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751406AbdFZGjM (ORCPT ); Mon, 26 Jun 2017 02:39:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57578 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751092AbdFZGjG (ORCPT ); Mon, 26 Jun 2017 02:39:06 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4B4794E4C4 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 4B4794E4C4 Message-ID: <1498459157.20591.6.camel@redhat.com> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations From: Gerd Hoffmann To: "Zhang, Tina" , Alex Williamson Cc: "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , Kirti Wankhede , "Chen, Xiaoguang" , "intel-gvt-dev@lists.freedesktop.org" , "Lv, Zhiyuan" , "Wang, Zhi A" , "Wang, Zhenyu Z" Date: Mon, 26 Jun 2017 08:39:17 +0200 In-Reply-To: <237F54289DF84E4997F34151298ABEBC7C5731B3@SHSMSX101.ccr.corp.intel.com> References: <1497513611-2814-1-git-send-email-xiaoguang.chen@intel.com> <1497513611-2814-6-git-send-email-xiaoguang.chen@intel.com> <1497542438.29252.1.camel@redhat.com> <20170615143833.7526351b@w520.home> <24c4880b-24f5-ea07-834c-c77d3e895c78@nvidia.com> <1497854312.4207.4.camel@redhat.com> <20170619085530.1f5e46dc@w520.home> <237F54289DF84E4997F34151298ABEBC7C56EBE0@SHSMSX101.ccr.corp.intel.com> <1497956256.16795.7.camel@redhat.com> <237F54289DF84E4997F34151298ABEBC7C5731B3@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 26 Jun 2017 06:39:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > > With the generation we can also do something different:  Pass in > > plane_type and > > generation, and have VFIO_DEVICE_GET_DMABUF_FD return an error in > > case > > the generation doesn't match.  In that case it doesn't make much > > sense any > > more to have a separate plane_info struct, which was added so we > > don't have > > to duplicate things in query-plane and get- dmabuf ioctl structs. > > Comparing with the current patch, this would make user space a little > bit harder to > get the dmabuf by calling VFIO_DEVICE_GET_DMABUF ioctl. Is it > efficient for > user mode usage? user space has to call QUERY-PLANE first, then looks if it has a dma- buf for that, if not call GET-DMABUF. Problem is the guest could have changed the plane between the QUERY- PLANE and GET-DMABUF ioctls. Current patches (v8 series) just returns plane-info on GET-DMABUF too, so userspace can at least detect something changed. It would be easier for userspace if GET-DMABUF throws an error in case the plane changed since the last QUERY-PLANE ioctl. The generation id would be one way to handle it, but possibly it is easier if the kernel driver just keeps track internally. So GET-DMABUF would be defined to return a dmabuf for the plane returned by the previous QUERY-PLANE ioctl (on the same file handle), or return an error in case the plane has changed meanwhile. cheers, Gerd