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: Wed, 21 Jun 2017 09:34:21 +0200 Message-ID: <1498030461.5802.3.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> <20170620090004.44ac7fbc@w520.home> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170620090004.44ac7fbc@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 ICBIaSwKCj4gV2UgYWxyZWFkeSBoYXZlIFZGSU9fREVWSUNFX0dFVF9JTkZPIHdoaWNoIHJldHVy bnM6Cj4gCj4gc3RydWN0IHZmaW9fZGV2aWNlX2luZm8gewo+IMKgwqDCoMKgwqDCoMKgwqBfX3Uz MsKgwqDCoGFyZ3N6Owo+IMKgwqDCoMKgwqDCoMKgwqBfX3UzMsKgwqDCoGZsYWdzOwo+ICNkZWZp bmUgVkZJT19ERVZJQ0VfRkxBR1NfUkVTRVQgKDEgPDwgMCnCoMKgwqDCoMKgwqDCoMKgLyogRGV2 aWNlIHN1cHBvcnRzCj4gcmVzZXQgKi8KPiAjZGVmaW5lIFZGSU9fREVWSUNFX0ZMQUdTX1BDScKg wqDCoCgxIDw8IDEpwqDCoMKgwqDCoMKgwqDCoC8qIHZmaW8tcGNpIGRldmljZSAqLwo+ICNkZWZp bmUgVkZJT19ERVZJQ0VfRkxBR1NfUExBVEZPUk0gKDEgPDwgMinCoMKgwqDCoMKgLyogdmZpby1w bGF0Zm9ybQo+IGRldmljZSAqLwo+ICNkZWZpbmUgVkZJT19ERVZJQ0VfRkxBR1NfQU1CQcKgwqAo MSA8PCAzKcKgwqDCoMKgwqDCoMKgwqAvKiB2ZmlvLWFtYmEgZGV2aWNlCj4gKi8KPiAjZGVmaW5l IFZGSU9fREVWSUNFX0ZMQUdTX0NDV8KgwqDCoCgxIDw8IDQpwqDCoMKgwqDCoMKgwqDCoC8qIHZm aW8tY2N3IGRldmljZSAqLwo+IMKgwqDCoMKgwqDCoMKgwqBfX3UzMsKgwqDCoG51bV9yZWdpb25z O8KgwqDCoMKgLyogTWF4IHJlZ2lvbiBpbmRleCArIDEgKi8KPiDCoMKgwqDCoMKgwqDCoMKgX191 MzLCoMKgwqBudW1faXJxczvCoMKgwqDCoMKgwqDCoC8qIE1heCBJUlEgaW5kZXggKyAxICovCj4g fTsKPiAKPiBXZSBjb3VsZCB1c2UgdHdvIGZsYWcgYml0cyB0byBpbmRpY2F0ZSBkbWFidWYgb3Ig Z3JhcGhpY3MgcmVnaW9uCj4gc3VwcG9ydC4KClRoYXQgd29ya3MgdG9vLgoKPiA+IFRoZW4gdGhp cyB0byBxdWVyeSB0aGUgcGxhbmU6Cj4gPiAKPiA+IHN0cnVjdCB2ZmlvX2RldmljZV9nZnhfcXVl cnlfcGxhbmUgewo+ID4gwqDCoMKgwqDCoMKgwqDCoF9fdTMyIGFyZ3N6Owo+ID4gwqDCoMKgwqDC oMKgwqDCoF9fdTMyIGZsYWdzOwo+ID4gwqDCoMKgwqDCoMKgwqDCoHN0cnVjdCB2ZmlvX2Rldmlj ZV9nZnhfcGxhbmVfaW5mbyBwbGFuZV9pbmZvO8KgwqAvKiBvdXQgKi8KPiA+IMKgwqDCoMKgwqDC oMKgwqBfX3UzMiBwbGFuZV90eXBlO8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoC8qIGluwqDCoCovCj4gPiB9Owo+IAo+IEknbSBub3Qg c3VyZSB3aHkgd2UncmUgdXNpbmcgYW4gZW51bSBmb3Igc29tZXRoaW5nIHRoYXQgY2FuIGN1cnJl bnRseQo+IGJlIGRlZmluZWQgd2l0aCAyIGJpdHMsCgpXZSBjYW4gcmV1c2UgdGhlIERSTV9QTEFO RV9UWVBFXyogdGhlbi4KCj4gIHNlZW1zIGxpa2UgdGhpcyB3b3VsZCBiZSBhbm90aGVyIGdvb2Qg dXNlIG9mCj4gZmxhZ3MuwqDCoFdlIGNvdWxkIGV2ZW4gZW1iZWQgYW4gZW51bSBpbnRvIHRoZSBm bGFncyBpZiB3ZSB3YW50IHRvCj4gbGVhdmUgc29tZSBleHBhbnNpb24gcm9vbSwgNCBiaXRzIG1h eWJlP8KgwqBBbHNvLCBJIHdhcyBpbWFnaW5pbmcgdGhhdAo+IGEKPiBkZXZpY2UgY291bGQgc3Vw cG9ydCBtdWx0aXBsZSBncmFwaGljcyByZWdpb25zLCB0aGF0J3Mgd2hlcmUKPiBzcGVjaWZ5aW5n Cj4gdGhlICJpZCIgYXMgYSByZWdpb24gaW5kZXggc2VlbWVkIHVzZWZ1bC4KCkhtbSwgeWVzLCBw b3NzaWJseSBmb3IgbXVsdGloZWFkIGNvbmZpZ3VyYXRpb25zLiAgQnV0IEkgZ3Vlc3MgZm9yCnBy b3BlciBtdWx0aWhlYWQgc3VwcG9ydCB3ZSB3b3VsZCBuZWVkIG1vcmUgdGhhbiBqdXN0IGFuIHJl Z2lvbiBpZC4KCk9yIGRvIHlvdSBoYXZlIHNvbWV0aGluZyBlbHNlIGluIG1pbmQ/Cgo+ID4gV2l0 aCB0aGUgZ2VuZXJhdGlvbiB3ZSBjYW4gYWxzbyBkbyBzb21ldGhpbmcgZGlmZmVyZW50OsKgwqBQ YXNzIGluCj4gPiBwbGFuZV90eXBlIGFuZCBnZW5lcmF0aW9uLCBhbmQgaGF2ZSBWRklPX0RFVklD RV9HRVRfRE1BQlVGX0ZECj4gPiByZXR1cm4KPiA+IGFuIGVycm9yIGluIGNhc2UgdGhlIGdlbmVy YXRpb24gZG9lc24ndCBtYXRjaC7CoMKgSW4gdGhhdCBjYXNlIGl0Cj4gPiBkb2Vzbid0Cj4gPiBt YWtlIG11Y2ggc2Vuc2UgYW55IG1vcmUgdG8gaGF2ZSBhIHNlcGFyYXRlIHBsYW5lX2luZm8gc3Ry dWN0LAo+ID4gd2hpY2gKPiA+IHdhcyBhZGRlZCBzbyB3ZSBkb24ndCBoYXZlIHRvIGR1cGxpY2F0 ZSB0aGluZ3MgaW4gcXVlcnktcGxhbmUgYW5kCj4gPiBnZXQtCj4gPiBkbWFidWYgaW9jdGwgc3Ry dWN0cy4KPiAKPiBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIGhvdyB0aGlzIHdvcmtzIGZvciBh IHJlZ2lvbiwgdGhlIHJlZ2lvbiBpcwo+IGFsd2F5cyB0aGUgY3VycmVudCBnZW5lcmF0aW9uLCBo b3cgY2FuIHRoZSB1c2VyIGV2ZXIgYmUgc3VyZSB0aGUKPiBwbGFuZV9pbmZvIG1hdGNoZXMgd2hh dCBpcyBleHBvc2VkIGluIHRoZSByZWdpb24/CgpnZW5lcmF0aW9uIHdpbGwgY2hhbmdlIGVhY2gg dGltZSB0aGUgcGxhbmUgY29uZmlndXJhdGlvbiAobm90IGNvbnRlbnQpCmNoYW5nZXMuICBUeXBp Y2FsbHkgdGhhdCB3aWxsIGJlIG9uIHZpZGVvIG1vZGUgc3dpdGNoZXMuICBJbiB0aGUgZG1hYnVm CmNhc2UgYWxzbyBvbiBwYWdlZmxpcHMuCgpjaGVlcnMsCiAgR2VyZAoKX19fX19fX19fX19fX19f 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 S1751771AbdFUHeS (ORCPT ); Wed, 21 Jun 2017 03:34:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48588 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751056AbdFUHeR (ORCPT ); Wed, 21 Jun 2017 03:34:17 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DAA0661D37 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DAA0661D37 Message-ID: <1498030461.5802.3.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: Wed, 21 Jun 2017 09:34:21 +0200 In-Reply-To: <20170620090004.44ac7fbc@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> <20170620090004.44ac7fbc@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.39]); Wed, 21 Jun 2017 07:34:17 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > We already have VFIO_DEVICE_GET_INFO which returns: > > struct vfio_device_info { >         __u32   argsz; >         __u32   flags; > #define VFIO_DEVICE_FLAGS_RESET (1 << 0)        /* Device supports > reset */ > #define VFIO_DEVICE_FLAGS_PCI   (1 << 1)        /* vfio-pci device */ > #define VFIO_DEVICE_FLAGS_PLATFORM (1 << 2)     /* vfio-platform > device */ > #define VFIO_DEVICE_FLAGS_AMBA  (1 << 3)        /* vfio-amba device > */ > #define VFIO_DEVICE_FLAGS_CCW   (1 << 4)        /* vfio-ccw device */ >         __u32   num_regions;    /* Max region index + 1 */ >         __u32   num_irqs;       /* Max IRQ index + 1 */ > }; > > We could use two flag bits to indicate dmabuf or graphics region > support. That works too. > > 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  */ > > }; > > I'm not sure why we're using an enum for something that can currently > be defined with 2 bits, We can reuse the DRM_PLANE_TYPE_* then. > seems like this would be another good use of > flags.  We could even embed an enum into the flags if we want to > leave some expansion room, 4 bits maybe?  Also, I was imagining that > a > device could support multiple graphics regions, that's where > specifying > the "id" as a region index seemed useful. Hmm, yes, possibly for multihead configurations. But I guess for proper multihead support we would need more than just an region id. Or do you have something else in mind? > > 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. > > I'm not sure I understand how this works for a region, the region is > always the current generation, how can the user ever be sure the > plane_info matches what is exposed in the region? generation will change each time the plane configuration (not content) changes. Typically that will be on video mode switches. In the dmabuf case also on pageflips. cheers, Gerd