Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754638AbdFWV6Q (ORCPT ); Fri, 23 Jun 2017 17:58:16 -0400 Received: from mga01.intel.com ([192.55.52.88]:58691 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753306AbdFWV6N (ORCPT ); Fri, 23 Jun 2017 17:58:13 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,380,1493708400"; d="scan'208";a="100962981" From: "Zhang, Tina" To: Gerd Hoffmann , 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" Subject: RE: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations Thread-Topic: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations Thread-Index: AQHS6bQOm048yqQnv0S7uYOCurj/4KIzAH9Q Date: Fri, 23 Jun 2017 21:58:09 +0000 Message-ID: <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> In-Reply-To: <1497956256.16795.7.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 v5NLwWrU017345 Content-Length: 3164 Lines: 103 > -----Original Message----- > From: Gerd Hoffmann [mailto:kraxel@redhat.com] > Sent: Tuesday, June 20, 2017 6:58 PM > 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 > Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf > operations > > 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. 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? Thanks Tina > > cheers, > Gerd