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: Tue, 27 Jun 2017 08:12:34 +0200 Message-ID: <1498543954.15306.2.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> <1498459157.20591.6.camel@redhat.com> <20170626112857.37c2aa65@w520.home> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170626112857.37c2aa65@w520.home> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: 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 ICBIaSwKCj4gSG1tLCBJIGRvbid0IGxpa2UgdGhhdCBpbnRlcmZhY2UuwqDCoENhbiB5b3UgY2l0 ZSBleGFtcGxlcyBvZiBvdGhlcgo+IGlvY3RscyB0aGF0IGJlaGF2ZSB0aGlzIHdheT/CoMKgSXQg ZG9lc24ndCBmZWVsIGxpa2UgYW4gZWxlZ2FudCB1c2VyCj4gaW50ZXJmYWNlOyB0aGUgdXNlciBj YW4gZ2V0IHRoZSBkbWFidWYsIGJ1dCBvbmx5IGFmdGVyIHRoZXkgcXVlcnkgdGhlCj4gZG1hYnVm LCBldmVuIHRob3VnaCB0aGUgZ2V0LWRtYWJ1ZiBpb2N0bCByZXR1cm5zIHRoZSBzYW1lIGRhdGEg YXMgdGhlCj4gcXVlcnktcGxhbmUgaW9jdGwsIGJ1dCB0aGV5IGNhbid0IGdldCB0aGUgZG1hYnVm IGlmIHRoZSBwbGFuZSBoYXMKPiBjaGFuZ2VkIGluIHRoZSBpbnRlcmltLCB3aGljaCBpcyBub3Qg c29tZXRoaW5nIHRoZSB1c2VyIGNhbgo+IGtub3cuwqDCoEFyZQo+IHdlIGNhdXNpbmcgb3VyIG93 biBwcm9ibGVtcyB3aXRoIHRoaXMgbW9kZWwgb2YgY3ljbGluZyB0aHJvdWdoIGRtYWJ1Zgo+IGZk cz/CoMKgV2UgdGFsa2VkIHByZXZpb3VzbHkgYWJvdXQgYW4gZW51bSBvZiBwbGFuZSB0eXBlcywg cHJpbWFyeSBhbmQKPiBjdXJzb3IuwqDCoFdoYXQgaWYgdGhlIHVzZXIgd2FzIHNpbXBseSBhYmxl IHRvIGdldCBhIGRtYWJ1ZiBmZCBmb3IgZWFjaAo+IG9mCj4gdGhvc2UgYW5kIHRoZXkgcXVlcmll ZCB0aGUgY3VycmVudCBwbGFuZSBpbmZvcm1hdGlvbiB2aWEgdGhvc2UgZmRzPwo+IElPVywgdGhl IGZkIGlzIHBlcnNpc3RlbnQgYW5kIHNwZWNpZmljIHRvIGEgZ2l2ZW4gcGxhbmUgdHlwZSwgYnV0 IHRoZQo+IGZvcm1hdCB3aXRoaW4gaXQgaXMgZHluYW1pYy4KCldpbGwgbm90IHdvcmsgZHVlIHRv IGhvdyBkbWEtYnVmcyBhcmUgZGVzaWduZWQuCgpCdXQsIHllcywgdGhlIFFVRVJZIHRoZW4gR0VU IHNwbGl0IGlzIHVnbHkgZm9yIGEgbnVtYmVyIG9mIHJlYXNvbnMuCgpEb2VzIGd2dCB0cmFjayB0 aGUgbGl2ZSBjeWNsZSBvZiBhbGwgZG1hLWJ1ZnMgaXQgaGFzIGhhbmRlZCBvdXQ/CklmIHNvLCB0 aGVuIG1heWJlIHdlIGNhbiBsZXQgdGhlIGtlcm5lbCBjaGVjayB3aGVuZXZlciBhIGRtYS1idWYg Zm9yCnRoZSBjdXJyZW50IHBsYW5lIGV4aXN0cz8gIEFuZCBpZiB0aGF0IGlzbid0IHRoZSBjYXNl IGhhbmQgb3V0IGEgZG1hLQpidWYgcmlnaHQgYXdheSwgd2l0aG91dCBleHBlY3RpbmcgdXNlcnNw YWNlIGV4cGxpY2l0bHkgYXNraW5nIGZvciBpdD8KClRoYXQgd2lsbCBzaW1wbGlmeSB0aGUgaW50 ZXJmYWNlIGFuZCByZW1vdmUgdGhlIHJhY2UgY29uZGl0aW9uIGF0IHRoZQpleHBlbnNlIG9mIHNv bWUgYWRkaXRpb25hbCBib29ra2VlcGluZyBpbiB0aGUga2VybmVsLgoKY2hlZXJzLAogIEdlcmQK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkludGVsLWdm eCBtYWlsaW5nIGxpc3QKSW50ZWwtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xp c3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludGVsLWdmeAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752130AbdF0GMe (ORCPT ); Tue, 27 Jun 2017 02:12:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47954 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbdF0GM3 (ORCPT ); Tue, 27 Jun 2017 02:12:29 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F168B3B73E Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com F168B3B73E Message-ID: <1498543954.15306.2.camel@redhat.com> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations From: Gerd Hoffmann To: Alex Williamson Cc: "Zhang, Tina" , "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: Tue, 27 Jun 2017 08:12:34 +0200 In-Reply-To: <20170626112857.37c2aa65@w520.home> 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> <1498459157.20591.6.camel@redhat.com> <20170626112857.37c2aa65@w520.home> 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.30]); Tue, 27 Jun 2017 06:12:29 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > Hmm, I don't like that interface.  Can you cite examples of other > ioctls that behave this way?  It doesn't feel like an elegant user > interface; the user can get the dmabuf, but only after they query the > dmabuf, even though the get-dmabuf ioctl returns the same data as the > query-plane ioctl, but they can't get the dmabuf if the plane has > changed in the interim, which is not something the user can > know.  Are > we causing our own problems with this model of cycling through dmabuf > fds?  We talked previously about an enum of plane types, primary and > cursor.  What if the user was simply able to get a dmabuf fd for each > of > those and they queried the current plane information via those fds? > IOW, the fd is persistent and specific to a given plane type, but the > format within it is dynamic. Will not work due to how dma-bufs are designed. But, yes, the QUERY then GET split is ugly for a number of reasons. Does gvt track the live cycle of all dma-bufs it has handed out? If so, then maybe we can let the kernel check whenever a dma-buf for the current plane exists? And if that isn't the case hand out a dma- buf right away, without expecting userspace explicitly asking for it? That will simplify the interface and remove the race condition at the expense of some additional bookkeeping in the kernel. cheers, Gerd