From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf Date: Fri, 12 May 2017 11:12:05 +0200 Message-ID: <1494580325.14352.57.camel@redhat.com> References: <1493372130-27727-1-git-send-email-xiaoguang.chen@intel.com> <1493372130-27727-7-git-send-email-xiaoguang.chen@intel.com> <1493718658.8581.82.camel@redhat.com> <20170504100833.199bc8ba@t450s.home> <1493967331.371.53.camel@redhat.com> <20170505091115.7a680636@t450s.home> <1494509273.17970.12.camel@redhat.com> <20170511094526.164985ee@w520.home> <20170511205829.672854c3@t450s.home> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170511205829.672854c3@t450s.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" , "Lv, Zhiyuan" , "Chen, Xiaoguang" , "intel-gvt-dev@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org ICBIaSwKCj4gSWYgdGhlIGNvbnRlbnRzIG9mIHRoZSBmcmFtZWJ1ZmZlciBjaGFuZ2Ugb3IgaWYg dGhlIHBhcmFtZXRlcnMgb2YgdGhlCj4gZnJhbWVidWZmZXIgY2hhbmdlPyAgSSBjYW4ndCBpbWFn ZSB0aGF0IGNyZWF0aW5nIGEgbmV3IGRtYWJ1ZiBmZCBmb3IKPiBldmVyeSB2aXN1YWwgY2hhbmdl IHdpdGhpbiB0aGUgZnJhbWVidWZmZXIgd291bGQgYmUgZWZmaWNpZW50LCBidXQgSQo+IGRvbid0 IGhhdmUgYW55IGNvbmNlcHQgb2Ygd2hhdCBhIGRtYWJ1ZiBhY3R1YWxseSBkb2VzLgoKT2ssIHNv bWUgYmFja2dyb3VuZDoKClRoZSBkcm0gc3Vic3lzdGVtIGhhcyB0aGUgY29uY2VwdCBvZiBwbGFu ZXMuICBUaGUgbW9zdCBpbXBvcnRhbnQgcGxhbmUKaXMgdGhlIHByaW1hcnkgZnJhbWVidWZmZXIg KGkuZS4gd2hhdCBnZXRzIHNjYW5uZWQgb3V0IHRvIHRoZSBwaHlzaWNhbApkaXNwbGF5KS4gIFRo ZSBjdXJzb3IgaXMgYSBwbGFuZSB0b28sIGFuZCB0aGVyZSBjYW4gYmUgYWRkaXRpb25hbApvdmVy bGF5IHBsYW5lcyBmb3Igc3R1ZmYgbGlrZSB2aWRlbyBwbGF5YmFjay4KClR5cGljYWxseSB0aGVy ZSBhcmUgbXVsdGlwbGUgcGxhbmVzIGluIGEgc3lzdGVtIGFuZCBvbmx5IG9uZSBvZiB0aGVtCmdl dHMgc2Nhbm5lZCBvdXQgdG8gdGhlIGNydGMsIGkuZS4gdGhlIGZiZGV2IGVtdWxhdGlvbiBjcmVh dGVzIG9uZSBwbGFuZQpmb3IgdGhlIGZyYW1lYnVmZmVyIGNvbnNvbGUuICBUaGUgWC1TZXJ2ZXIg Y3JlYXRlcyBhIHBsYW5lIHRvbywgYW5kIHdoZW4KeW91IHN3aXRjaCBiZXR3ZWVuIFgtU2VydmVy IGFuZCBmcmFtZWJ1ZmZlciBjb25zb2xlIHZpYSBjdHJsLWFsdC1mbiB0aGUKaW50ZWwgZHJpdmVy IGp1c3QgcmVwcm9ncmFtcyB0aGUgZW5jb2RlciB0byBzY2FuIG91dCB0aGUgb25lIG9yIHRoZQpv dGhlciBwbGFuZSB0byB0aGUgY3J0Yy4KClRoZSBkbWEtYnVmIGhhbmRlZCBvdXQgYnkgZ3Z0IGlz IGEgcmVmZXJlbmNlIHRvIGEgcGxhbmUuICBJIHRoaW5rIG9uIHRoZQpob3N0IHNpZGUgZ3Z0IGNh biBzZWUgb25seSB0aGUgYWN0aXZlIHBsYW5lIChmcm9tIGVuY29kZXIvY3J0YyByZWdpc3Rlcgpw cm9ncmFtbWluZykgbm90IHRoZSBpbmFjdGl2ZSBvbmVzLgoKVGhlIGRtYS1idWYgY2FuIGJlIGlt cG9ydGVkIGFzIG9wZW5nbCB0ZXh0dXJlIGFuZCB0aGVuIGJlIHVzZWQgdG8gcmVuZGVyCnRoZSBn dWVzdCBkaXNwbGF5IHRvIGEgaG9zdCB3aW5kb3cuICBJIHRoaW5rIGl0IGlzIGV2ZW4gcG9zc2li bGUgdG8gdXNlCnRoZSBkbWEtYnVmIGFzIHBsYW5lIGluIHRoZSBob3N0IGRybSBkcml2ZXIgYW5k IHNjYW4gaXQgb3V0IGRpcmVjdGx5IHRvCmEgcGh5c2ljYWwgZGlzcGxheS4gIFRoZSBhY3R1YWwg ZnJhbWVidWZmZXIgY29udGVudCBzdGF5cyBpbiBncHUgbWVtb3J5CmFsbCB0aGUgdGltZSwgdGhl IGNwdSBuZXZlciBoYXMgdG8gdG91Y2ggaXQuCgpJdCBpcyBwb3NzaWJsZSB0byBjYWNoZSB0aGUg ZG1hLWJ1ZiBoYW5kbGVzLCBpLmUuIHdoZW4gdGhlIGd1ZXN0IGJvb3RzCnlvdSdsbCBnZXQgdGhl IGZpcnN0IGZvciB0aGUgZmJjb24gcGxhbmUsIHdoZW4gdGhlIHgtc2VydmVyIHN0YXJ0cyB0aGUK c2Vjb25kIGZvciB0aGUgeC1zZXJ2ZXIgZnJhbWVidWZmZXIsIGFuZCB3aGVuIHRoZSB1c2VyIHN3 aXRjaGVzIHRvIHRoZQp0ZXh0IGNvbnNvbGUgdmlhIGN0cmwtYWx0LWZuIHlvdSBjYW4gcmUtdXNl IHRoZSBmYmNvbiBkbWEtYnVmIHlvdQphbHJlYWR5IGhhdmUuCgpUaGUgY2FjaGluZyBiZWNvbWVz IG1vcmUgaW1wb3J0YW50IGZvciBnb29kIHBlcmZvcm1hbmNlIHdoZW4gdGhlIGd1ZXN0CnVzZXMg cGFnZWZsaXBwaW5nICh3YXlsYW5kIGRvZXMpOiBkZWZpbmUgdHdvIHBsYW5lcywgcmVuZGVyIGlu dG8gb25lCndoaWxlIGRpc3BsYXlpbmcgdGhlIG90aGVyLCB0aGVuIGZsaXAgdGhlIHR3byBmb3Ig YSBhdG9taWMgZGlzcGxheQp1cGRhdGUuCgpUaGUgY2FjaGluZyBhbHNvIG1ha2VzIGl0IGEgYml0 IGRpZmZpY3VsdCB0byBjcmVhdGUgYSBnb29kIGludGVyZmFjZS4KU28sIHRoZSBjdXJyZW50IHBh dGNoIHNldCBjcmVhdGVzOgoKICAoYSkgQSB3YXkgdG8gcXVlcnkgdGhlIGFjdGl2ZSBwbGFuZXMg KGlvY3RsCiAgICAgIElOVEVMX1ZHUFVfUVVFUllfRE1BQlVGIGFkZGVkIGJ5IHBhdGNoIDUvNiBv ZiB0aGlzIHNlcmllcykuCiAgKGIpIEEgd2F5IHRvIGNyZWF0ZSBhIGRtYS1idWYgZm9yIHRoZSBh Y3RpdmUgcGxhbmUgKGlvY3RsCiAgICAgIElOVEVMX1ZHUFVfR0VORVJBVEVfRE1BQlVGKS4KClR5 cGljYWwgdXNlcnNwYWNlIHdvcmtmbG93IGlzIHRvIGZpcnN0IHF1ZXJ5IHRoZSBwbGFuZSwgdGhl biBjaGVjayBpZiBpdAphbHJlYWR5IGhhcyBhIGRtYS1idWYgZm9yIGl0LCBhbmQgaWYgbm90IGNy ZWF0ZSBvbmUuCgo+IFdoYXQgY2hhbmdlcyB0byB0aGUgZnJhbWVidWZmZXIgcmVxdWlyZSBhIG5l dyBkbWFidWYgZmQ/ICBTaG91bGRuJ3QgdGhlCj4gdXNlciBxdWVyeSB0aGUgcGFyYW1ldGVycyBv ZiB0aGUgZnJhbWVidWZmZXIgdGhyb3VnaCBhIGRtYWJ1ZiBmZCBhbmQKPiBzaG91bGRuJ3QgdGhl IGRtYWJ1ZiBmZCBoYXZlIHNvbWUgc2lnbmFsaW5nIG1lY2hhbmlzbSB0byB0aGUgdXNlcgo+IChl dmVudGZkIHBlcmhhcHMpIHRvIG5vdGlmeSB0aGUgdXNlciB0byByZS1ldmFsdWF0ZSB0aGUgcGFy YW1ldGVycz8KCmRtYS1idWZzIGRvbid0IHN1cHBvcnQgdGhhdCwgdGhleSBhcmUgcmVhbGx5IGp1 c3QgYSBoYW5kbGUgdG8gYSBwaWVjZSBvZgptZW1vcnksIGFsbCBtZXRhZGF0YSAoZm9ybWF0LCBz aXplKSBtb3N0IGJlIGNvbW11bmljYXRlZCBieSBvdGhlciBtZWFucy4KCj4gT3RoZXJ3aXNlIGFy ZSB5b3UgaW1hZ2luaW5nIHRoYXQgdGhlIHVzZXIgcG9sbHMgdGhlIHZmaW8gcmVnaW9uPwoKSG1t LCBub3RpZmljYXRpb24gc3VwcG9ydCB3b3VsZCBwcm9iYWJseSBhIGdvb2QgcmVhc29uIHRvIGhh dmUgYQpzZXBhcmF0ZSBmaWxlIGhhbmRsZSB0byBtYW5hZ2UgdGhlIGRtYS1idWZzIChpbnN0ZWFk IG9mIHVzaW5nCmRyaXZlci1zcGVjaWZpYyBpb2N0bHMgb24gdGhlIHZmaW8gZmQpLCBiZWNhdXNl IHRoZSBkcml2ZXIgY291bGQgYWxzbwp1c2UgdGhlIG1hbmFnZW1lbnQgZmQgZm9yIG5vdGlmaWNh dGlvbnMgdGhlbi4KCkknbSBub3Qgc3VyZSBob3cgdXNlZnVsIG5vdGlmaWNhdGlvbiBzdXBwb3J0 IGFjdHVhbGx5IGlzIHRob3VnaC4KTm90aWZpY2F0aW9ucyB3aGVuIGFub3RoZXIgcGxhbmUgZ2V0 cyBtYXBwZWQgdG8gdGhlIGNydGMgc2hvdWxkIGJlIGVhc3kuCkJ1dCBJJ20gbm90IHN1cmUgaXQg aXMgcG9zc2libGUgdG8gZ2V0IG5vdGlmaWNhdGlvbnMgd2hlbiB0aGUgcGxhbmUKY29udGVudCBj aGFuZ2VzLCBlc3BlY2lhbGx5IGluIGNhc2UgdGhlIGd1ZXN0IGRvZXMgc29mdHdhcmUgcmVuZGVy aW5nIHNvCnRoZSBkaXNwbGF5IGlzIHVwZGF0ZWQgd2l0aG91dCBndnQgc2VlaW5nIGd1ZXN0IGFj dGl2aXR5IG9uIHRoZQpyZW5kZXJpbmcgcGlwZWxpbmUuICBXaXRob3V0IHRoZSBsYXRlciBxZW11 IG5lZWRzIGEgdGltZXIgZm9yIGRpc3BsYXkKdXBkYXRlcyBfYW55d2F5XyAuLi4KCmNoZWVycywK ICBHZXJkCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpJ bnRlbC1nZnggbWFpbGluZyBsaXN0CkludGVsLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0 cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZngK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755996AbdELJMO convert rfc822-to-8bit (ORCPT ); Fri, 12 May 2017 05:12:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52128 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755341AbdELJMJ (ORCPT ); Fri, 12 May 2017 05:12:09 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9E1694DD4B 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 9E1694DD4B Message-ID: <1494580325.14352.57.camel@redhat.com> Subject: Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf From: Gerd Hoffmann To: Alex Williamson Cc: "Chen, Xiaoguang" , "Tian, Kevin" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "zhenyuw@linux.intel.com" , "Lv, Zhiyuan" , "intel-gvt-dev@lists.freedesktop.org" , "Wang, Zhi A" Date: Fri, 12 May 2017 11:12:05 +0200 In-Reply-To: <20170511205829.672854c3@t450s.home> References: <1493372130-27727-1-git-send-email-xiaoguang.chen@intel.com> <1493372130-27727-7-git-send-email-xiaoguang.chen@intel.com> <1493718658.8581.82.camel@redhat.com> <20170504100833.199bc8ba@t450s.home> <1493967331.371.53.camel@redhat.com> <20170505091115.7a680636@t450s.home> <1494509273.17970.12.camel@redhat.com> <20170511094526.164985ee@w520.home> <20170511205829.672854c3@t450s.home> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 12 May 2017 09:12:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > If the contents of the framebuffer change or if the parameters of the > framebuffer change? I can't image that creating a new dmabuf fd for > every visual change within the framebuffer would be efficient, but I > don't have any concept of what a dmabuf actually does. Ok, some background: The drm subsystem has the concept of planes. The most important plane is the primary framebuffer (i.e. what gets scanned out to the physical display). The cursor is a plane too, and there can be additional overlay planes for stuff like video playback. Typically there are multiple planes in a system and only one of them gets scanned out to the crtc, i.e. the fbdev emulation creates one plane for the framebuffer console. The X-Server creates a plane too, and when you switch between X-Server and framebuffer console via ctrl-alt-fn the intel driver just reprograms the encoder to scan out the one or the other plane to the crtc. The dma-buf handed out by gvt is a reference to a plane. I think on the host side gvt can see only the active plane (from encoder/crtc register programming) not the inactive ones. The dma-buf can be imported as opengl texture and then be used to render the guest display to a host window. I think it is even possible to use the dma-buf as plane in the host drm driver and scan it out directly to a physical display. The actual framebuffer content stays in gpu memory all the time, the cpu never has to touch it. It is possible to cache the dma-buf handles, i.e. when the guest boots you'll get the first for the fbcon plane, when the x-server starts the second for the x-server framebuffer, and when the user switches to the text console via ctrl-alt-fn you can re-use the fbcon dma-buf you already have. The caching becomes more important for good performance when the guest uses pageflipping (wayland does): define two planes, render into one while displaying the other, then flip the two for a atomic display update. The caching also makes it a bit difficult to create a good interface. So, the current patch set creates: (a) A way to query the active planes (ioctl INTEL_VGPU_QUERY_DMABUF added by patch 5/6 of this series). (b) A way to create a dma-buf for the active plane (ioctl INTEL_VGPU_GENERATE_DMABUF). Typical userspace workflow is to first query the plane, then check if it already has a dma-buf for it, and if not create one. > What changes to the framebuffer require a new dmabuf fd? Shouldn't the > user query the parameters of the framebuffer through a dmabuf fd and > shouldn't the dmabuf fd have some signaling mechanism to the user > (eventfd perhaps) to notify the user to re-evaluate the parameters? dma-bufs don't support that, they are really just a handle to a piece of memory, all metadata (format, size) most be communicated by other means. > Otherwise are you imagining that the user polls the vfio region? Hmm, notification support would probably a good reason to have a separate file handle to manage the dma-bufs (instead of using driver-specific ioctls on the vfio fd), because the driver could also use the management fd for notifications then. I'm not sure how useful notification support actually is though. Notifications when another plane gets mapped to the crtc should be easy. But I'm not sure it is possible to get notifications when the plane content changes, especially in case the guest does software rendering so the display is updated without gvt seeing guest activity on the rendering pipeline. Without the later qemu needs a timer for display updates _anyway_ ... cheers, Gerd