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 10:35:03 +0200 Message-ID: <1497947703.16795.4.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> <20170616103959.3b6f1681@t450s.home> <1497854053.4207.2.camel@redhat.com> <20170619085409.26f5c14c@w520.home> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170619085409.26f5c14c@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: intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, Kirti Wankhede , Xiaoguang Chen , intel-gvt-dev@lists.freedesktop.org, zhiyuan.lv@intel.com List-Id: intel-gfx@lists.freedesktop.org ICBIaSwKCj4gPiBIbW0sIHBsYW5lIGlzbid0IHJlYWxseSBhbiBJRCwgaXQgaXMgYSB0eXBlLCB3 aXRoIHR5cGUgYmVpbmcgZWl0aGVyCj4gPiBEUk1fUExBTkVfVFlQRV9QUklNQVJZIG9yIERSTV9Q TEFORV9UWVBFX0NVUlNPUiwgc28gSSBkb24ndCB0aGluawo+ID4gdGhlCj4gPiBmbGFnZSBhYm92 ZSBtYWtlIHNlbnNlLgo+IAo+IFRoZSBpbnRlbnRpb24gd2FzIHRoYXQgLi4uX1JFR0lPTl9JRCBh bmQgLi4uUExBTkVfSUQgYXJlIGRlc2NyaWJpbmcKPiB3aGF0IHRoZSB2ZmlvX2RldmljZV9xdWVy eV9nZnhfcGxhbmUuaWQgZmllbGQgcmVwcmVzZW50cywgZWl0aGVyIGEKPiByZWdpb24gaW5kZXgg b3IgYSBwbGFuZSBpZGVudGlmaWVyLsKgwqBUaGUgdHlwZSBvZiBwbGFuZSB3b3VsZCBiZQo+IHJl cHJlc2VudGVkIHdpdGhpbiB0aGUgdmZpb19kZXZpY2VfZ2Z4X3BsYW5lX2luZm8gc3RydWN0LgoK VGhlIHBsYW5lcyBkb24ndCByZWFsbHkgaGF2ZSBhbiBpZCwgd2Ugc2hvdWxkIHJlbmFtZSB0aGF0 IHRvCnBsYW5lX3R5cGUsIG9yIG1heWJlIGRybV9wbGFuZV90eXBlIChzaW1saWFyIHRvIHRoZSBk cm1fZm9ybWF0XyoKZmllbGRzKSwgdG8gYXZvaWQgdGhhdCBjb25mdXNpb24uCgpwbGFuZV90eXBl IGlzIHNldCBieSB1c2Vyc3BhY2UgdG8gc3BlY2lmeSB3aGF0IGtpbmQgb2YgcGxhbmUgaXQgYXNr cwpmb3IuCgo+ID4gQWxzbyBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBoYXZlIHNvbWUg d2F5IHRvIGZpZ3VyZSB0aGUKPiA+IGRldmljZQo+ID4gY2FwYWJpbGl0aWVzIGFzIHRoZSB1c2Vy c3BhY2Ugd29ya2Zsb3cgd2lsbCBsb29rIHF1aXRlIGRpZmZlcmVudAo+ID4gZm9yCj4gPiB0aGUg dHdvIGNhc2VzLgo+IAo+IEluIHRoZSByZWdpb24gY2FzZSwgVkZJT19ERVZJQ0VfR0VUX1JFR0lP Tl9JTkZPIHdvdWxkIGluY2x1ZGUgYQo+IGRldmljZQo+IHNwZWNpZmljIHJlZ2lvbiB3aXRoIGEg aG9wZWZ1bGx5IGNvbW1vbiBpZGVudGlmaWVyIHRvIGlkZW50aWZ5IGl0IGFzCj4gYQo+IGdyYXBo aWNzIGZyYW1lYnVmZmVyLgoKT2ssIHRoYXQgc2hvdWxkIHdvcmsgdG8gZmlndXJlIHdoZW5ldmVy IHRoZSBtZGV2IHN1cHBvcnRzIGEgcGxhbmUKcmVnaW9uIG9yIG5vdC4KCj4gSW4gdGhlIGRtYWJ1 ZiBjYXNlLFZGSU9fREVWSUNFX1FVRVJZX0dGWF9QTEFORSB3b3VsZCBpbmRpY2F0ZSB0aGUKPiBw bGFuZSBhcyBhICJwbGFuZSBJRCIgYW5kIHNvbWUgc29ydCBvZgo+IFZGSU9fREVWSUNFX0dFVF9H RlhfUExBTkUoVkZJT19HRlhfVFlQRV9ETUFCVUYpIGlvY3RsIHdvdWxkIGJlCj4gbmVjZXNzYXJ5 IHRvIGdldCBhIGZpbGUgZGVzY3JpcHRvciB0byB0aGF0IHBsYW5lLgo+IAo+IFdoYXQgZWxzZSBh cmUgeW91IHRoaW5raW5nIHdlIG5lZWQ/wqDCoFRoYW5rcywKCkkgbmVlZCB0byBrbm93IHdoZW5l dmVyIHRoZSBtZGV2IHN1cHBvcnRzIGRtYWJ1ZnMgb3Igbm90LCBhdCBkZXZpY2UKaW5pdGlhbGl6 YXRpb24gdGltZSAoYmVjYXVzZSBkbWFidWZzIHJlcXVpcmUgb3BlbmdsIHN1cHBvcnQpLCB3aGVu ClZGSU9fREVWSUNFX1FVRVJZX0dGWF9QTEFORSBkb2Vzbid0IHdvcmsgZHVlIHRvIHRoZSBndWVz dCBub3QgaGF2aW5nCnRoZSBkZXZpY2UgaW5pdGlhbGl6ZWQgeWV0LgoKTWF5YmUgd2Ugc2hvdWxk IGhhdmUgYSBlcnJvciBmaWVsZCBpbiB0aGUgaW9jdGwgc3RydWN0LCBvciB3ZSBuZWVkIHRvCmNs ZWFybHkgZGVmaW5lIGVycm9yIGNvZGVzIHNvIHRoZSBrZXJuZWwgZG9lc24ndCBqdXN0IHRocm93 IEVJTlZBTCBpbgphbGwgY2FzZXMuCgpPciBqdXN0IGEgVkZJT19ERVZJQ0VfR0ZYX0NBUFMgaW9j dGwgd2hpY2ggcmV0dXJucyBOT05FLCBSRUdJT04gb3IKRE1BQlVGLgoKY2hlZXJzLAogIEdlcmQK 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 S1751813AbdFTIe4 (ORCPT ); Tue, 20 Jun 2017 04:34:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60284 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750965AbdFTIey (ORCPT ); Tue, 20 Jun 2017 04:34:54 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B980E4ACD0 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 B980E4ACD0 Message-ID: <1497947703.16795.4.camel@redhat.com> Subject: Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations From: Gerd Hoffmann To: Alex Williamson Cc: Kirti Wankhede , Xiaoguang Chen , chris@chris-wilson.co.uk, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, zhenyuw@linux.intel.com, zhiyuan.lv@intel.com, intel-gvt-dev@lists.freedesktop.org, zhi.a.wang@intel.com, kevin.tian@intel.com Date: Tue, 20 Jun 2017 10:35:03 +0200 In-Reply-To: <20170619085409.26f5c14c@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> <20170616103959.3b6f1681@t450s.home> <1497854053.4207.2.camel@redhat.com> <20170619085409.26f5c14c@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.38]); Tue, 20 Jun 2017 08:34:54 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > > Hmm, plane isn't really an ID, it is a type, with type being either > > DRM_PLANE_TYPE_PRIMARY or DRM_PLANE_TYPE_CURSOR, so I don't think > > the > > flage above make sense. > > The intention was that ..._REGION_ID and ...PLANE_ID are describing > what the vfio_device_query_gfx_plane.id field represents, either a > region index or a plane identifier.  The type of plane would be > represented within the vfio_device_gfx_plane_info struct. The planes don't really have an id, we should rename that to plane_type, or maybe drm_plane_type (simliar to the drm_format_* fields), to avoid that confusion. plane_type is set by userspace to specify what kind of plane it asks for. > > Also I think it would be useful to have some way to figure the > > device > > capabilities as the userspace workflow will look quite different > > for > > the two cases. > > In the region case, VFIO_DEVICE_GET_REGION_INFO would include a > device > specific region with a hopefully common identifier to identify it as > a > graphics framebuffer. Ok, that should work to figure whenever the mdev supports a plane region or not. > In the dmabuf case,VFIO_DEVICE_QUERY_GFX_PLANE would indicate the > plane as a "plane ID" and some sort of > VFIO_DEVICE_GET_GFX_PLANE(VFIO_GFX_TYPE_DMABUF) ioctl would be > necessary to get a file descriptor to that plane. > > What else are you thinking we need?  Thanks, I need to know whenever the mdev supports dmabufs or not, at device initialization time (because dmabufs require opengl support), when VFIO_DEVICE_QUERY_GFX_PLANE doesn't work due to the guest not having the device initialized yet. Maybe we should have a error field in the ioctl struct, or we need to clearly define error codes so the kernel doesn't just throw EINVAL in all cases. Or just a VFIO_DEVICE_GFX_CAPS ioctl which returns NONE, REGION or DMABUF. cheers, Gerd