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: Fri, 23 Jun 2017 09:26:59 +0200 Message-ID: <1498202819.24807.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> <237F54289DF84E4997F34151298ABEBC7C56F3DC@SHSMSX101.ccr.corp.intel.com> <20170620172204.09405cf4@w520.home> <237F54289DF84E4997F34151298ABEBC7C56F843@SHSMSX101.ccr.corp.intel.com> <1498043011.5802.5.camel@redhat.com> <20170621125938.1a92abda@w520.home> <1498120215.25651.5.camel@redhat.com> <20170622125458.01c953ab@w520.home> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170622125458.01c953ab@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 ICBIaSwKCj4gSXMgdGhpcyBvbmx5IGdvaW5nIHRvIHN1cHBvcnQgYWNjZWxlcmF0ZWQgZHJpdmVy IG91dHB1dCwgbm90IGJhc2ljCj4gVkdBCj4gbW9kZXMgZm9yIEJJT1MgaW50ZXJhY3Rpb24/CgpS aWdodCBub3cgdGhlcmUgaXMgbm8gdmdhYmlvcyBvciB1ZWZpIHN1cHBvcnQgZm9yIHRoZSB2Z3B1 LgoKQnV0IGV2ZW4gd2l0aCB0aGF0IGluIHBsYWNlIHRoZXJlIHN0aWxsIGlzIHRoZSBwcm9ibGVt IHRoYXQgdGhlIGRpc3BsYXkKZGV2aWNlIGluaXRpYWxpemF0aW9uIGhhcHBlbnMgYmVmb3JlIHRo ZSBndWVzdCBydW5zIGFuZCB0aGVyZWZvcmUgdGhlcmUKaXNuJ3QgYW4gcGxhbmUgeWV0IC4uLgoK PiA+IFJpZ2h0IG5vdyB0aGUgZXhwZXJpbWVudGFsIGludGVsIHBhdGNoZXMgdGhyb3cgZXJyb3Jz IGluIGNhc2Ugbm8KPiA+IHBsYW5lCj4gPiBleGlzdHMgKHlldCkuwqDCoE1heWJlIHdlIHNob3Vs ZCBoYXZlIGEgImJvb2wgaXNfZW5hYmxlZCIgZmllbGQgaW4KPiA+IHRoZQo+ID4gcGxhbmVfaW5m byBzdHJ1Y3QsIHNvIGRyaXZlcnMgY2FuIHVzZSB0aGF0IHRvIHNpZ25hbCB3aGVuZXZlciB0aGUK PiA+IGd1ZXN0Cj4gPiBoYXMgcHJvZ3JhbW1lZCBhIHZhbGlkIHZpZGVvIG1vZGUgb3Igbm90IChs aWtld2lzZSBmb3IgdGhlIGN1cnNvciwKPiA+IHdoaWNoIGRvZXNuJ3QgZXhpc3Qgd2l0aCBmYmNv biwgb25seSB3aGVuIHJ1bm5pbmcgeG9yZykuwqDCoFdpdGggdGhhdAo+ID4gaW4KPiA+IHBsYWNl IHVzaW5nIHRoZSBRVUVSWV9QTEFORSBpb2N0bCBhbHNvIGZvciBwcm9iaW5nIGxvb2tzCj4gPiBy ZWFzb25hYmxlLgo+IAo+IFN1cmUsIG9yIC1FTk9UVFkgZm9yIGlvY3RsIG5vdCBpbXBsZW1lbnRl ZCB2cyAtRUlOVkFMIGZvciBubwo+IGF2YWlsYWJsZQo+IHBsYW5lLCBidXQgdGhlbiB0aGF0IG1p Z2h0IG5vdCBoZWxwIHRoZSB1c2VyIGtub3cgaG93IGEgcGxhbmUgd291bGQKPiBiZQo+IGF2YWls YWJsZSBpZiBpdCB3ZXJlIGF2YWlsYWJsZS4KClNvIG1heWJlIGEgImVudW0gcGxhbmVfc3RhdGUi IChpbnN0ZWFkIG9mICJib29sIGlzX2VuYWJsZWQiKT8gIFNvIHdlCmNhbiBjbGVhcmx5IGRpc3R1 cmdpc2ggRU5BQkxFRCwgRElTQUJMRUQsIE5PVF9TVVBQT1JURUQgY2FzZXM/Cgo+ID4gWWVzLCBJ J2QgbGVhdmUgdGhhdCB0byB1c2Vyc3BhY2UuwqDCoFNvLCB3aGVuIHRoZSBnZW5lcmF0aW9uIGNo YW5nZXMKPiA+IHVzZXJzcGFjZSBrbm93cyB0aGUgZ3Vlc3QgY2hhbmdlZCB0aGUgcGxhbmUuwqDC oEl0IGNvdWxkIGJlIGEKPiA+IGNvbmZpZ3VyYXRpb24gdGhlIGd1ZXN0IGhhcyB1c2VkIGJlZm9y ZSAoYW5kIHdoZXJlIHVzZXJzcGFjZSBjb3VsZAo+ID4gaGF2ZQo+ID4gYSBjYWNoZWQgZG1hLWJ1 ZiBoYW5kbGUgZm9yKSwgb3IgaXQgY291bGQgYmUgc29tZXRoaW5nIG5ldy4KPiAKPiBCdXQgdXNl cnNwYWNlIGFsc28gZG9lc24ndCBrbm93IHRoYXQgYSBkbWFidWYgZ2VuZXJhdGlvbiB3aWxsIGV2 ZXIgYmUKPiB2aXNpdGVkIGFnYWluLAoKa2VybmVsIHdvdWxkbid0IGtub3cgZWl0aGVyLCBvbmx5 IHRoZSBndWVzdCBrbm93cyAuLi4KCj4gc28gdGhleSdyZSBib3VuZCB0byBoYXZlIHNvbWUgc3Rh bGUgZGVzY3JpcHRvcnMuwqDCoEFyZQo+IHdlIHRoaW5raW5nIHVzZXJzcGFjZSB3b3VsZCBoYXZl IHNvbWUgTFJVIGxpc3Qgb2YgZG1hYnVmcyBzbyB0aGF0Cj4gdGhleQo+IGRvbid0IGNvbGxlY3Qg dG9vIG1hbnk/wqDCoEVhY2ggdXNlcyBzb21lIHJlc291cmNlcyzCoMKgZG8gd2UganVzdCByZWx5 Cj4gb24KPiBvcGVuIGZpbGUgaGFuZGxlcyB0byBzZXQgYW4gdXBwZXIgbGltaXQ/CgpZZXAsIHRo aXMgaXMgZXhhY3RseSB3aGF0IG15IHFlbXUgcGF0Y2hlcyBhcmUgZG9pbmcsIGtlZXAgYSBMUlUg bGlzdC4KwqAKPiA+ID4gV2hhdCBoYXBwZW5zIHRvCj4gPiA+IGV4aXN0aW5nIGRtYWJ1ZiBmZHMg d2hlbiB0aGUgZ2VuZXJhdGlvbiB1cGRhdGVzLCBkbyB0aGV5IHN0b3AKPiA+ID4gcmVmcmVzaGlu Zz/CoMKgCj4gPiAKPiA+IERlcGVuZHMgb24gd2hhdCB0aGUgZ3Vlc3QgaXMgZG9pbmcgOykKPiA+ IAo+ID4gVGhlIGRtYS1idWYgaXMganVzdCBhIGhvc3Qtc2lkZSBoYW5kbGUgZm9yIHRoZSBwaWVj ZSBvZiB2aWRlbwo+ID4gbWVtb3J5Cj4gPiB3aGVyZSB0aGUgZ3Vlc3Qgc3RvcmVkIHRoZSBmcmFt ZWJ1ZmZlci4KPiAKPiBTbyB0aGUgcmVzb3VyY2VzIHRoZSB1c2VyIGlzIGhvbGRpbmcgaWYgdGhl eSBkb24ndCByZWxlYXNlIHRoZWlyCj4gZG1hYnVmCj4gYXJlIHBvdGVudGlhbGx5IG5vbi10cml2 aWFsLgoKTm90IHJlYWxseS4gIEhvc3QgSUdEIGhhcyBhIGNlcnRhaW4gYW1vdW50IG9mIG1lbW9y eSwgc29tZSBvZiBpdCBpcwphc3NpZ25lZCB0byB0aGUgZ3Vlc3QsIGd1ZXN0IHN0b3JlcyB0aGUg ZnJhbWVidWZmZXIgdGhlcmUsIHRoZSBkbWEtYnVmCmlzIGEgaG9zdCBoYW5kbGUgKGRybSBvYmpl Y3QsIHVzYWJsZSBmb3IgcmVuZGVyaW5nIG9wcykgZm9yIHRoZSBndWVzdApmcmFtZWJ1ZmZlci4g IFNvIGl0IGRvZXNuJ3QgdXNlIG11Y2ggcmVzc291cmNlcy4gIFNvbWUgbWVtb3J5IGlzIG5lZWRl ZApmb3IgbWFuYWdlbWVudCBzdHJ1Y3RzLCBidXQgbm90IGZvciB0aGUgYWN0dWFsIGRhdGEgYXMg dGhpcyBpbiB0aGUKdmlkZW8gbWVtb3J5IGRlZGljYXRlZCB0byB0aGUgZ3Vlc3QuCgo+ID4gT2ss IGlmIHdlIHdhbnQgc3VwcG9ydCBtdWx0aXBsZSByZWdpb25zLsKgwqBEbyB3ZT/CoMKgVXNpbmcg dGhlIG9mZnNldAo+ID4gd2UKPiA+IGNhbiBwbGFjZSBtdWx0aXBsZSBwbGFuZXMgaW4gYSBzaW5n bGUgcmVnaW9uLsKgwqBBbmQgSSdtIG5vdCBzdXJlCj4gPiBudmlkaWEKPiA+IHBsYW5zIHRvIHVz ZSBtdWx0aXBsZSBwbGFuZXMgaW4gdGhlIGZpcnN0IHBsYWNlIC4uLgo+IAo+IEkgZG9uJ3Qgd2Fu dCB0byB0YWtlIGEgZHJpdmVyIGlvY3RsIGludGVyZmFjZSBhcyBhIHRocm93IGF3YXksIG9uZQo+ IHRpbWUKPiB1c2UgZXhlcmNpc2UuwqDCoElmIHdlIGNhbiB0aGluayBvZiBzdWNoIHF1ZXN0aW9u cyBub3csIGxldCdzIGRlZmluZQo+IGhvdwo+IHRoZXkgd29yay7CoMKgQSBkZXZpY2UgY291bGQg aGF2ZSBtdWx0aXBsZSBncmFwaGljcyByZWdpb25zIHdpdGgKPiBtdWx0aXBsZQo+IHBsYW5lcyB3 aXRoaW4gZWFjaCByZWdpb24uCgpJJ2Qgc3VnZ2VzdCB0byBzZXR0bGUgZm9yIG9uZSBvZiB0aGVz ZSB0d28uICBFaXRoZXIgb25lIHJlZ2lvbiBhbmQKbXVsdGlwbGUgcGxhbmVzIGluc2lkZSAodXNp bmcgb2Zmc2V0KSBvciBvbmUgcmVnaW9uIHBlciBwbGFuZS4gIEknZApwcmVmZXIgdGhlIGZvcm1l ci4gIFdoZW4gZ29pbmcgZm9yIHRoZSBsYXR0ZXIgdGhlbiB5ZXMgd2UgaGF2ZSB0bwpzcGVjaWZ5 IHRoZSByZWdpb24uICBJJ2QgbmFtZSB0aGUgZmllbGQgcmVnaW9uX2lkIHRoZW4gdG8gbWFrZSBj bGVhcgp3aGF0IGl0IGlzLgoKV2hhdCB3b3VsZCBiZSB0aGUgdXNlIGNhc2UgZm9yIG11bHRpcGxl IHBsYW5lcz8KCmN1cnNvciBzdXBwb3J0PyAgV2UgYWxyZWFkeSBoYXZlIHBsYW5lX3R5cGUgZm9y IHRoYXQuCgptdWx0aWhlYWQgc3VwcG9ydD8gIFdlJ2xsIG5lZWQgKGF0IG1pbmltdW0pIGEgaGVh ZF9pZCBmaWVsZCBmb3IgdGhhdAooZm9yIGJvdGggZG1hLWJ1ZiBhbmQgcmVnaW9uKQoKcGFnZWZs aXBwaW5nIHN1cHBvcnQ/ICBOb3RoaW5nIG5lZWRlZCwgcXVlcnlfcGxhbmUgd2lsbCBzaW1wbHkg cmV0dXJuCnRoZSBjdXJyZW50bHkgdmlzaWJsZSBwbGFuZS4gIFJlZ2lvbiBvbmx5IG5lZWRzIHRv IGJlIGJpZyBlbm91Z2ggdG8gZml0CnRoZSBmcmFtZWJ1ZmZlciB0d2ljZS4gIFRoZW4gdGhlIGRy aXZlciBjYW4gZmxpcCBiZXR3ZWVuIHR3byBidWZmZXJzLApwb2ludCB0byB0aGUgb25lIHFlbXUg c2hvdWxkIGRpc3BsYXkgdXNpbmcgIm9mZnNldCIuCgo+IERvIHdlIGFsc28gd2FudCB0byBleGNs dWRlIHRoYXQgZGV2aWNlCj4gbmVlZHMgdG8gYmUgc3RyaWN0bHkgcmVnaW9uIG9yIGRtYWJ1Zj/C oMKgTWF5YmUgaXQgZG9lcyBib3RoLgoKVmVyeSB1bmxpa2VseSBJTUhPLgoKPiBPciBtYXliZQo+ IGl0IHN1cHBvcnRzIGRtYWJ1Zi1uZyAoaWUuIHdoYXRldmVyIGNvbWVzIG5leHQpLgoKUG9zc2li bHkgaGFwcGVucyBzb21lIGRheSwgYnV0IHdobyBrbm93cyB3aGF0IGludGVyZmFjZXMgd2UnbGwg bmVlZCB0bwpzdXBwb3J0IHRoYXQgLi4uCgo+ID4gdmZpb19kZXZpY2VfcXVlcnkgewo+ID4gwqDC oMKgwqB1MzIgYXJnc3o7Cj4gPiDCoMKgwqDCoHUzMiBmbGFnczsKPiA+IMKgwqDCoMKgZW51bSBx dWVyeV90eXBlO8KgwqAvKiBvciB1c2UgZmxhZ3MgZm9yIHRoYXQgKi8KCj4gV2UgZG9uJ3QgaGF2 ZSBhbiBpbmZpbml0ZSBudW1iZXIgb2YgaW9jdGxzCgpUaGUgbGltaXRlZCBpb2N0bCBudW1iZXIg c3BhY2UgaXMgYSBnb29kIHJlYXNvbiBpbmRlZWQuCk9rLCBsZXRzIHRha2UgdGhpcyByb3V0ZSB0 aGVuLgoKY2hlZXJzLAogIEdlcmQKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCkludGVsLWdmeCBtYWlsaW5nIGxpc3QKSW50ZWwtZ2Z4QGxpc3RzLmZyZWVk ZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ludGVsLWdmeAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753791AbdFWH1J (ORCPT ); Fri, 23 Jun 2017 03:27:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37128 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753693AbdFWH1G (ORCPT ); Fri, 23 Jun 2017 03:27:06 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 853067A16E Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 853067A16E Message-ID: <1498202819.24807.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: Fri, 23 Jun 2017 09:26:59 +0200 In-Reply-To: <20170622125458.01c953ab@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> <237F54289DF84E4997F34151298ABEBC7C56F3DC@SHSMSX101.ccr.corp.intel.com> <20170620172204.09405cf4@w520.home> <237F54289DF84E4997F34151298ABEBC7C56F843@SHSMSX101.ccr.corp.intel.com> <1498043011.5802.5.camel@redhat.com> <20170621125938.1a92abda@w520.home> <1498120215.25651.5.camel@redhat.com> <20170622125458.01c953ab@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.28]); Fri, 23 Jun 2017 07:27:05 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > Is this only going to support accelerated driver output, not basic > VGA > modes for BIOS interaction? Right now there is no vgabios or uefi support for the vgpu. But even with that in place there still is the problem that the display device initialization happens before the guest runs and therefore there isn't an plane yet ... > > Right now the experimental intel patches throw errors in case no > > plane > > exists (yet).  Maybe we should have a "bool is_enabled" field in > > the > > plane_info struct, so drivers can use that to signal whenever the > > guest > > has programmed a valid video mode or not (likewise for the cursor, > > which doesn't exist with fbcon, only when running xorg).  With that > > in > > place using the QUERY_PLANE ioctl also for probing looks > > reasonable. > > Sure, or -ENOTTY for ioctl not implemented vs -EINVAL for no > available > plane, but then that might not help the user know how a plane would > be > available if it were available. So maybe a "enum plane_state" (instead of "bool is_enabled")? So we can clearly disturgish ENABLED, DISABLED, NOT_SUPPORTED cases? > > Yes, I'd leave that to userspace.  So, when the generation changes > > userspace knows the guest changed the plane.  It could be a > > configuration the guest has used before (and where userspace could > > have > > a cached dma-buf handle for), or it could be something new. > > But userspace also doesn't know that a dmabuf generation will ever be > visited again, kernel wouldn't know either, only the guest knows ... > so they're bound to have some stale descriptors.  Are > we thinking userspace would have some LRU list of dmabufs so that > they > don't collect too many?  Each uses some resources,  do we just rely > on > open file handles to set an upper limit? Yep, this is exactly what my qemu patches are doing, keep a LRU list.   > > > What happens to > > > existing dmabuf fds when the generation updates, do they stop > > > refreshing?   > > > > Depends on what the guest is doing ;) > > > > The dma-buf is just a host-side handle for the piece of video > > memory > > where the guest stored the framebuffer. > > So the resources the user is holding if they don't release their > dmabuf > are potentially non-trivial. Not really. Host IGD has a certain amount of memory, some of it is assigned to the guest, guest stores the framebuffer there, the dma-buf is a host handle (drm object, usable for rendering ops) for the guest framebuffer. So it doesn't use much ressources. Some memory is needed for management structs, but not for the actual data as this in the video memory dedicated to the guest. > > Ok, if we want support multiple regions.  Do we?  Using the offset > > we > > can place multiple planes in a single region.  And I'm not sure > > nvidia > > plans to use multiple planes in the first place ... > > I don't want to take a driver ioctl interface as a throw away, one > time > use exercise.  If we can think of such questions now, let's define > how > they work.  A device could have multiple graphics regions with > multiple > planes within each region. I'd suggest to settle for one of these two. Either one region and multiple planes inside (using offset) or one region per plane. I'd prefer the former. When going for the latter then yes we have to specify the region. I'd name the field region_id then to make clear what it is. What would be the use case for multiple planes? cursor support? We already have plane_type for that. multihead support? We'll need (at minimum) a head_id field for that (for both dma-buf and region) pageflipping support? Nothing needed, query_plane will simply return the currently visible plane. Region only needs to be big enough to fit the framebuffer twice. Then the driver can flip between two buffers, point to the one qemu should display using "offset". > Do we also want to exclude that device > needs to be strictly region or dmabuf?  Maybe it does both. Very unlikely IMHO. > Or maybe > it supports dmabuf-ng (ie. whatever comes next). Possibly happens some day, but who knows what interfaces we'll need to support that ... > > vfio_device_query { > >     u32 argsz; > >     u32 flags; > >     enum query_type;  /* or use flags for that */ > We don't have an infinite number of ioctls The limited ioctl number space is a good reason indeed. Ok, lets take this route then. cheers, Gerd