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, 20 Jun 2017 12:57:36 +0200 Message-ID: <1497956256.16795.7.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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <237F54289DF84E4997F34151298ABEBC7C56EBE0@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 T24gVHVlLCAyMDE3LTA2LTIwIGF0IDA4OjQxICswMDAwLCBaaGFuZywgVGluYSB3cm90ZToKPiBI aSwKPiAKPiBUaGFua3MgZm9yIGFsbCB0aGUgY29tbWVudHMuIEhlcmUgYXJlIHRoZSBzdW1tYXJp ZXM6Cj4gCj4gMS4gTW9kaWZ5IHRoZSBzdHJ1Y3R1cmVzIHRvIG1ha2UgaXQgbW9yZSBnZW5lcmFs Lgo+IHN0cnVjdCB2ZmlvX2RldmljZV9nZnhfcGxhbmVfaW5mbyB7Cj4gCV9fdTY0IHN0YXJ0Owo+ IAlfX3U2NCBkcm1fZm9ybWF0X21vZDsKPiAJX191MzIgZHJtX2Zvcm1hdDsKPiAJX191MzIgd2lk dGg7Cj4gCV9fdTMyIGhlaWdodDsKPiAJX191MzIgc3RyaWRlOwo+IAlfX3UzMiBzaXplOwo+IAlf X3UzMiB4X3BvczsKPiAJX191MzIgeV9wb3M7Cj4gCV9fdTMyIGdlbmVyYXRpb247Cj4gfTsKCkxv b2tzIGdvb2QgdG8gbWUuCgo+IHN0cnVjdCB2ZmlvX2RldmljZV9xdWVyeV9nZnhfcGxhbmUgewo+ IAlfX3UzMiBhcmdzejsKPiAJX191MzIgZmxhZ3M7Cj4gI2RlZmluZSBWRklPX0dGWF9QTEFORV9G TEFHU19SRUdJT05fSUQJCSgxIDw8IDApCj4gI2RlZmluZSBWRklPX0dGWF9QTEFORV9GTEFHU19Q TEFORV9JRAkJKDEgPDwgMSkKPiAJc3RydWN0IHZmaW9fZGV2aWNlX2dmeF9wbGFuZV9pbmZvIHBs YW5lX2luZm87Cj4gCV9fdTMyIGlkO8KgCj4gfTsKCkknbSBub3QgY29udmluY2VkIHRoZSBmbGFn cyBhcmUgYSBncmVhdCBpZGVhLiAgV2hlbmV2ZXIgZG1hYnVmcyBvciBhCnJlZ2lvbiBpcyB1c2Vk IGlzIGEgc3RhdGljIHByb3BlcnR5IG9mIHRoZSBkZXZpY2UsIG5vdCBvZiBlYWNoCmluZGl2aWR1 YWwgcGxhbmUuCgoKSSB0aGluayB3ZSBzaG91bGQgaGF2ZSB0aGlzIGZvciB1c2Vyc3BhY2UgdG8g ZmlndXJlOgoKZW51bSB2ZmlvX2RldmljZV9nZnhfdHlwZSB7CiAgICAgICAgVkZJT19ERVZJQ0Vf R0ZYX05PTkUsCiAgICAgICAgVkZJT19ERVZJQ0VfR0ZYX0RNQUJVRiwKICAgICAgICBWRklPX0RF VklDRV9HRlhfUkVHSU9OLAp9OwoKc3RydWN0IHZmaW9fZGV2aWNlX2dmeF9xdWVyeV9jYXBzIHsK ICAgICAgICBfX3UzMiBhcmdzejsKICAgICAgICBfX3UzMiBmbGFnczsKICAgICAgICBlbnVtIHZm aW9fZGV2aWNlX2dmeF90eXBlOwp9OwoKClRoZW4gdGhpcyB0byBxdWVyeSB0aGUgcGxhbmU6Cgpz dHJ1Y3QgdmZpb19kZXZpY2VfZ2Z4X3F1ZXJ5X3BsYW5lIHsKICAgICAgICBfX3UzMiBhcmdzejsK ICAgICAgICBfX3UzMiBmbGFnczsKICAgICAgICBzdHJ1Y3QgdmZpb19kZXZpY2VfZ2Z4X3BsYW5l X2luZm8gcGxhbmVfaW5mbzsgIC8qIG91dCAqLwogICAgICAgIF9fdTMyIHBsYW5lX3R5cGU7ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogaW4gICovCn07CgoKMi4gUmVtb3ZlIGRtYWJ1 ZiBtZ3IgZmQgYW5kIGFkZCB0aGVzZSB0d28gaW9jdGwgY29tbWFuZHMgdG8gdGhlIHZmaW8KZGV2 aWNlIGZkLgo+IFZGSU9fREVWSUNFX1FVRVJZX0dGWF9QTEFORSA6IHVzZWQgdG8gcXVlcnkKPiB2 ZmlvX2RldmljZV9nZnhfcGxhbmVfaW5mby4KClllcy4KCj4gVkZJT19ERVZJQ0VfR0VUX0RNQUJV Rl9GRDogdXNlZCB0byBjcmVhdGUgYW5kIHJldHVybiB0aGUgZG1hYnVmIGZkLgoKWWVzLiAgVGhl IHBsYW5lIG1pZ2h0IGhhdmUgY2hhbmdlZCBiZXR3ZWVuIHF1ZXJ5LXBsYW5lIGFuZCBnZXQtZG1h YnVmCmlvY3RsIGNhbGxzIHRob3VnaCwgd2UgbXVzdCBtYWtlIHN1cmUgd2UgaGFuZGxlIHRoYXQg c29tZWhvdy4gIEN1cnJlbnQKcGF0Y2hlcyByZXR1cm4gcGxhbmVfaW5mbyBvbiBnZXQtZG1hYnVm IGlvY3RsIHRvbywgc28gdXNlcnNwYWNlIGNhbiBzZWUKd2hhdCBpdCBhY3R1YWxseSBnb3QuCgpX aXRoIHRoZSBnZW5lcmF0aW9uIHdlIGNhbiBhbHNvIGRvIHNvbWV0aGluZyBkaWZmZXJlbnQ6ICBQ YXNzIGluCnBsYW5lX3R5cGUgYW5kIGdlbmVyYXRpb24sIGFuZCBoYXZlIFZGSU9fREVWSUNFX0dF VF9ETUFCVUZfRkQgcmV0dXJuCmFuIGVycm9yIGluIGNhc2UgdGhlIGdlbmVyYXRpb24gZG9lc24n dCBtYXRjaC4gIEluIHRoYXQgY2FzZSBpdCBkb2Vzbid0Cm1ha2UgbXVjaCBzZW5zZSBhbnkgbW9y ZSB0byBoYXZlIGEgc2VwYXJhdGUgcGxhbmVfaW5mbyBzdHJ1Y3QsIHdoaWNoCndhcyBhZGRlZCBz byB3ZSBkb24ndCBoYXZlIHRvIGR1cGxpY2F0ZSB0aGluZ3MgaW4gcXVlcnktcGxhbmUgYW5kIGdl dC0KZG1hYnVmIGlvY3RsIHN0cnVjdHMuCgpjaGVlcnMsCiAgR2VyZAoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4IG1haWxpbmcgbGlzdApJ bnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Au b3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751888AbdFTK52 (ORCPT ); Tue, 20 Jun 2017 06:57:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38306 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994AbdFTK50 (ORCPT ); Tue, 20 Jun 2017 06:57:26 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1F1DA3B703 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 1F1DA3B703 Message-ID: <1497956256.16795.7.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: Tue, 20 Jun 2017 12:57:36 +0200 In-Reply-To: <237F54289DF84E4997F34151298ABEBC7C56EBE0@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> 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, 20 Jun 2017 10:57:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-06-20 at 08:41 +0000, Zhang, Tina wrote: > Hi, > > Thanks for all the comments. Here are the summaries: > > 1. Modify the structures to make it more general. > struct vfio_device_gfx_plane_info { > __u64 start; > __u64 drm_format_mod; > __u32 drm_format; > __u32 width; > __u32 height; > __u32 stride; > __u32 size; > __u32 x_pos; > __u32 y_pos; > __u32 generation; > }; Looks good to me. > struct vfio_device_query_gfx_plane { > __u32 argsz; > __u32 flags; > #define VFIO_GFX_PLANE_FLAGS_REGION_ID (1 << 0) > #define VFIO_GFX_PLANE_FLAGS_PLANE_ID (1 << 1) > struct vfio_device_gfx_plane_info plane_info; > __u32 id;  > }; I'm not convinced the flags are a great idea. Whenever dmabufs or a region is used is a static property of the device, not of each individual plane. I think we should have this for userspace to figure: enum vfio_device_gfx_type { VFIO_DEVICE_GFX_NONE, VFIO_DEVICE_GFX_DMABUF, VFIO_DEVICE_GFX_REGION, }; struct vfio_device_gfx_query_caps { __u32 argsz; __u32 flags; enum vfio_device_gfx_type; }; Then this to query the plane: struct vfio_device_gfx_query_plane { __u32 argsz; __u32 flags; struct vfio_device_gfx_plane_info plane_info; /* out */ __u32 plane_type; /* in */ }; 2. Remove dmabuf mgr fd and add these two ioctl commands to the vfio device fd. > VFIO_DEVICE_QUERY_GFX_PLANE : used to query > vfio_device_gfx_plane_info. Yes. > VFIO_DEVICE_GET_DMABUF_FD: used to create and return the dmabuf fd. Yes. The plane might have changed between query-plane and get-dmabuf ioctl calls though, we must make sure we handle that somehow. Current patches return plane_info on get-dmabuf ioctl too, so userspace can see what it actually got. 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. cheers, Gerd