From mboxrd@z Thu Jan 1 00:00:00 1970 From: daniel at ffwll.ch (Daniel Vetter) Date: Mon, 9 Apr 2018 10:21:31 +0200 Subject: [PATCH v2] Add udmabuf misc device In-Reply-To: <5d88baad-a956-6bd5-e0d6-aabae6647f3e@amd.com> References: <20180316074650.5415-1-kraxel@redhat.com> <7547e99b-0e3c-264e-e52b-40ad5d52b49a@gmail.com> <20180406093307.s7wkhpmddd5d4r7a@sirius.home.kraxel.org> <5d88baad-a956-6bd5-e0d6-aabae6647f3e@amd.com> Message-ID: <20180409082131.GF31310@phenom.ffwll.local> On Fri, Apr 06, 2018 at 02:24:46PM +0200, Christian König wrote: > Am 06.04.2018 um 11:33 schrieb Gerd Hoffmann: > > Hi, > > > > > The pages backing a DMA-buf are not allowed to move (at least not without a > > > patch set I'm currently working on), but for certain MM operations to work > > > correctly you must be able to modify the page tables entries and move the > > > pages backing them around. > > > > > > For example try to use fork() with some copy on write pages with this > > > approach. You will find that you have only two options to correctly handle > > > this. > > The fork() issue should go away with shared memory pages (no cow). > > I guess this is the reason why vgem is internally backed by shmem. > > Yes, exactly that is also an approach which should work fine. Just don't try > to get this working with get_user_pages(). > > > > > Hmm. So I could try to limit the udmabuf driver to shmem too (i.e. > > have the ioctl take a shmem filehandle and offset instead of a virtual > > address). > > > > But maybe it is better then to just extend vgem, i.e. add support to > > create gem objects from existing shmem. > > > > Comments? > > Yes, extending vgem instead of creating something new sounds like a good > idea to me as well. +1 on adding a vgem "import from shmem/memfd" ioctl. Sounds like a good idea, and generally useful. We might want to limit to memfd though for semantic reasons: dma-buf have invariant size, shmem not so much. memfd can be locked down to not change their size anymore. And iirc the core mm page invalidation protocol around truncate() is about as bad as get_user_pages vs cow :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: daniel@ffwll.ch (Daniel Vetter) Date: Mon, 9 Apr 2018 10:21:31 +0200 Subject: [PATCH v2] Add udmabuf misc device In-Reply-To: <5d88baad-a956-6bd5-e0d6-aabae6647f3e@amd.com> References: <20180316074650.5415-1-kraxel@redhat.com> <7547e99b-0e3c-264e-e52b-40ad5d52b49a@gmail.com> <20180406093307.s7wkhpmddd5d4r7a@sirius.home.kraxel.org> <5d88baad-a956-6bd5-e0d6-aabae6647f3e@amd.com> Message-ID: <20180409082131.GF31310@phenom.ffwll.local> Content-Type: text/plain; charset="UTF-8" Message-ID: <20180409082131.E_X4zRe7PURJgh4-yi0hoYx41O8M6tMaUYu5rGIOoYo@z> On Fri, Apr 06, 2018@02:24:46PM +0200, Christian König wrote: > Am 06.04.2018 um 11:33 schrieb Gerd Hoffmann: > > Hi, > > > > > The pages backing a DMA-buf are not allowed to move (at least not without a > > > patch set I'm currently working on), but for certain MM operations to work > > > correctly you must be able to modify the page tables entries and move the > > > pages backing them around. > > > > > > For example try to use fork() with some copy on write pages with this > > > approach. You will find that you have only two options to correctly handle > > > this. > > The fork() issue should go away with shared memory pages (no cow). > > I guess this is the reason why vgem is internally backed by shmem. > > Yes, exactly that is also an approach which should work fine. Just don't try > to get this working with get_user_pages(). > > > > > Hmm. So I could try to limit the udmabuf driver to shmem too (i.e. > > have the ioctl take a shmem filehandle and offset instead of a virtual > > address). > > > > But maybe it is better then to just extend vgem, i.e. add support to > > create gem objects from existing shmem. > > > > Comments? > > Yes, extending vgem instead of creating something new sounds like a good > idea to me as well. +1 on adding a vgem "import from shmem/memfd" ioctl. Sounds like a good idea, and generally useful. We might want to limit to memfd though for semantic reasons: dma-buf have invariant size, shmem not so much. memfd can be locked down to not change their size anymore. And iirc the core mm page invalidation protocol around truncate() is about as bad as get_user_pages vs cow :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH v2] Add udmabuf misc device Date: Mon, 9 Apr 2018 10:21:31 +0200 Message-ID: <20180409082131.GF31310@phenom.ffwll.local> References: <20180316074650.5415-1-kraxel@redhat.com> <7547e99b-0e3c-264e-e52b-40ad5d52b49a@gmail.com> <20180406093307.s7wkhpmddd5d4r7a@sirius.home.kraxel.org> <5d88baad-a956-6bd5-e0d6-aabae6647f3e@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) by gabe.freedesktop.org (Postfix) with ESMTPS id BD2B96E04F for ; Mon, 9 Apr 2018 08:21:35 +0000 (UTC) Received: by mail-wm0-x230.google.com with SMTP id r82so14858276wme.0 for ; Mon, 09 Apr 2018 01:21:35 -0700 (PDT) Content-Disposition: inline In-Reply-To: <5d88baad-a956-6bd5-e0d6-aabae6647f3e@amd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Tomeu Vizoso , David Airlie , Daniel Vetter , open list , dri-devel@lists.freedesktop.org, qemu-devel@nongnu.org, "moderated list:DMA BUFFER SHARING FRAMEWORK" , Gerd Hoffmann , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , "open list:DMA BUFFER SHARING FRAMEWORK" List-Id: dri-devel@lists.freedesktop.org T24gRnJpLCBBcHIgMDYsIDIwMTggYXQgMDI6MjQ6NDZQTSArMDIwMCwgQ2hyaXN0aWFuIEvDtm5p ZyB3cm90ZToKPiBBbSAwNi4wNC4yMDE4IHVtIDExOjMzIHNjaHJpZWIgR2VyZCBIb2ZmbWFubjoK PiA+ICAgIEhpLAo+ID4gCj4gPiA+IFRoZSBwYWdlcyBiYWNraW5nIGEgRE1BLWJ1ZiBhcmUgbm90 IGFsbG93ZWQgdG8gbW92ZSAoYXQgbGVhc3Qgbm90IHdpdGhvdXQgYQo+ID4gPiBwYXRjaCBzZXQg SSdtIGN1cnJlbnRseSB3b3JraW5nIG9uKSwgYnV0IGZvciBjZXJ0YWluIE1NIG9wZXJhdGlvbnMg dG8gd29yawo+ID4gPiBjb3JyZWN0bHkgeW91IG11c3QgYmUgYWJsZSB0byBtb2RpZnkgdGhlIHBh Z2UgdGFibGVzIGVudHJpZXMgYW5kIG1vdmUgdGhlCj4gPiA+IHBhZ2VzIGJhY2tpbmcgdGhlbSBh cm91bmQuCj4gPiA+IAo+ID4gPiBGb3IgZXhhbXBsZSB0cnkgdG8gdXNlIGZvcmsoKSB3aXRoIHNv bWUgY29weSBvbiB3cml0ZSBwYWdlcyB3aXRoIHRoaXMKPiA+ID4gYXBwcm9hY2guIFlvdSB3aWxs IGZpbmQgdGhhdCB5b3UgaGF2ZSBvbmx5IHR3byBvcHRpb25zIHRvIGNvcnJlY3RseSBoYW5kbGUK PiA+ID4gdGhpcy4KPiA+IFRoZSBmb3JrKCkgaXNzdWUgc2hvdWxkIGdvIGF3YXkgd2l0aCBzaGFy ZWQgbWVtb3J5IHBhZ2VzIChubyBjb3cpLgo+ID4gSSBndWVzcyB0aGlzIGlzIHRoZSByZWFzb24g d2h5IHZnZW0gaXMgaW50ZXJuYWxseSBiYWNrZWQgYnkgc2htZW0uCj4gCj4gWWVzLCBleGFjdGx5 IHRoYXQgaXMgYWxzbyBhbiBhcHByb2FjaCB3aGljaCBzaG91bGQgd29yayBmaW5lLiBKdXN0IGRv bid0IHRyeQo+IHRvIGdldCB0aGlzIHdvcmtpbmcgd2l0aCBnZXRfdXNlcl9wYWdlcygpLgo+IAo+ ID4gCj4gPiBIbW0uICBTbyBJIGNvdWxkIHRyeSB0byBsaW1pdCB0aGUgdWRtYWJ1ZiBkcml2ZXIg dG8gc2htZW0gdG9vIChpLmUuCj4gPiBoYXZlIHRoZSBpb2N0bCB0YWtlIGEgc2htZW0gZmlsZWhh bmRsZSBhbmQgb2Zmc2V0IGluc3RlYWQgb2YgYSB2aXJ0dWFsCj4gPiBhZGRyZXNzKS4KPiA+IAo+ ID4gQnV0IG1heWJlIGl0IGlzIGJldHRlciB0aGVuIHRvIGp1c3QgZXh0ZW5kIHZnZW0sIGkuZS4g YWRkIHN1cHBvcnQgdG8KPiA+IGNyZWF0ZSBnZW0gb2JqZWN0cyBmcm9tIGV4aXN0aW5nIHNobWVt Lgo+ID4gCj4gPiBDb21tZW50cz8KPiAKPiBZZXMsIGV4dGVuZGluZyB2Z2VtIGluc3RlYWQgb2Yg Y3JlYXRpbmcgc29tZXRoaW5nIG5ldyBzb3VuZHMgbGlrZSBhIGdvb2QKPiBpZGVhIHRvIG1lIGFz IHdlbGwuCgorMSBvbiBhZGRpbmcgYSB2Z2VtICJpbXBvcnQgZnJvbSBzaG1lbS9tZW1mZCIgaW9j dGwuIFNvdW5kcyBsaWtlIGEgZ29vZAppZGVhLCBhbmQgZ2VuZXJhbGx5IHVzZWZ1bC4KCldlIG1p Z2h0IHdhbnQgdG8gbGltaXQgdG8gbWVtZmQgdGhvdWdoIGZvciBzZW1hbnRpYyByZWFzb25zOiBk bWEtYnVmIGhhdmUKaW52YXJpYW50IHNpemUsIHNobWVtIG5vdCBzbyBtdWNoLiBtZW1mZCBjYW4g YmUgbG9ja2VkIGRvd24gdG8gbm90IGNoYW5nZQp0aGVpciBzaXplIGFueW1vcmUuIEFuZCBpaXJj IHRoZSBjb3JlIG1tIHBhZ2UgaW52YWxpZGF0aW9uIHByb3RvY29sIGFyb3VuZAp0cnVuY2F0ZSgp IGlzIGFib3V0IGFzIGJhZCBhcyBnZXRfdXNlcl9wYWdlcyB2cyBjb3cgOi0pCi1EYW5pZWwKLS0g CkRhbmllbCBWZXR0ZXIKU29mdHdhcmUgRW5naW5lZXIsIEludGVsIENvcnBvcmF0aW9uCmh0dHA6 Ly9ibG9nLmZmd2xsLmNoCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9w Lm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1k ZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-wm0-f41.google.com ([74.125.82.41]:37972 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751650AbeDIIVf (ORCPT ); Mon, 9 Apr 2018 04:21:35 -0400 Received: by mail-wm0-f41.google.com with SMTP id i3so14734609wmf.3 for ; Mon, 09 Apr 2018 01:21:34 -0700 (PDT) Date: Mon, 9 Apr 2018 10:21:31 +0200 From: Daniel Vetter To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Gerd Hoffmann , dri-devel@lists.freedesktop.org, Daniel Vetter , Tomeu Vizoso , David Airlie , open list , qemu-devel@nongnu.org, "moderated list:DMA BUFFER SHARING FRAMEWORK" , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , "open list:DMA BUFFER SHARING FRAMEWORK" Subject: Re: [PATCH v2] Add udmabuf misc device Message-ID: <20180409082131.GF31310@phenom.ffwll.local> References: <20180316074650.5415-1-kraxel@redhat.com> <7547e99b-0e3c-264e-e52b-40ad5d52b49a@gmail.com> <20180406093307.s7wkhpmddd5d4r7a@sirius.home.kraxel.org> <5d88baad-a956-6bd5-e0d6-aabae6647f3e@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5d88baad-a956-6bd5-e0d6-aabae6647f3e@amd.com> Sender: linux-media-owner@vger.kernel.org List-ID: On Fri, Apr 06, 2018 at 02:24:46PM +0200, Christian König wrote: > Am 06.04.2018 um 11:33 schrieb Gerd Hoffmann: > > Hi, > > > > > The pages backing a DMA-buf are not allowed to move (at least not without a > > > patch set I'm currently working on), but for certain MM operations to work > > > correctly you must be able to modify the page tables entries and move the > > > pages backing them around. > > > > > > For example try to use fork() with some copy on write pages with this > > > approach. You will find that you have only two options to correctly handle > > > this. > > The fork() issue should go away with shared memory pages (no cow). > > I guess this is the reason why vgem is internally backed by shmem. > > Yes, exactly that is also an approach which should work fine. Just don't try > to get this working with get_user_pages(). > > > > > Hmm. So I could try to limit the udmabuf driver to shmem too (i.e. > > have the ioctl take a shmem filehandle and offset instead of a virtual > > address). > > > > But maybe it is better then to just extend vgem, i.e. add support to > > create gem objects from existing shmem. > > > > Comments? > > Yes, extending vgem instead of creating something new sounds like a good > idea to me as well. +1 on adding a vgem "import from shmem/memfd" ioctl. Sounds like a good idea, and generally useful. We might want to limit to memfd though for semantic reasons: dma-buf have invariant size, shmem not so much. memfd can be locked down to not change their size anymore. And iirc the core mm page invalidation protocol around truncate() is about as bad as get_user_pages vs cow :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f5S3U-0001tN-Ev for qemu-devel@nongnu.org; Mon, 09 Apr 2018 04:21:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f5S3T-0000S1-GZ for qemu-devel@nongnu.org; Mon, 09 Apr 2018 04:21:36 -0400 Received: from mail-wm0-x22a.google.com ([2a00:1450:400c:c09::22a]:40525) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f5S3T-0000Qn-8y for qemu-devel@nongnu.org; Mon, 09 Apr 2018 04:21:35 -0400 Received: by mail-wm0-x22a.google.com with SMTP id x4so14713931wmh.5 for ; Mon, 09 Apr 2018 01:21:35 -0700 (PDT) Sender: Daniel Vetter Date: Mon, 9 Apr 2018 10:21:31 +0200 From: Daniel Vetter Message-ID: <20180409082131.GF31310@phenom.ffwll.local> References: <20180316074650.5415-1-kraxel@redhat.com> <7547e99b-0e3c-264e-e52b-40ad5d52b49a@gmail.com> <20180406093307.s7wkhpmddd5d4r7a@sirius.home.kraxel.org> <5d88baad-a956-6bd5-e0d6-aabae6647f3e@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5d88baad-a956-6bd5-e0d6-aabae6647f3e@amd.com> Subject: Re: [Qemu-devel] [PATCH v2] Add udmabuf misc device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Gerd Hoffmann , dri-devel@lists.freedesktop.org, Daniel Vetter , Tomeu Vizoso , David Airlie , open list , qemu-devel@nongnu.org, "moderated list:DMA BUFFER SHARING FRAMEWORK" , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , "open list:DMA BUFFER SHARING FRAMEWORK" On Fri, Apr 06, 2018 at 02:24:46PM +0200, Christian König wrote: > Am 06.04.2018 um 11:33 schrieb Gerd Hoffmann: > > Hi, > > > > > The pages backing a DMA-buf are not allowed to move (at least not without a > > > patch set I'm currently working on), but for certain MM operations to work > > > correctly you must be able to modify the page tables entries and move the > > > pages backing them around. > > > > > > For example try to use fork() with some copy on write pages with this > > > approach. You will find that you have only two options to correctly handle > > > this. > > The fork() issue should go away with shared memory pages (no cow). > > I guess this is the reason why vgem is internally backed by shmem. > > Yes, exactly that is also an approach which should work fine. Just don't try > to get this working with get_user_pages(). > > > > > Hmm. So I could try to limit the udmabuf driver to shmem too (i.e. > > have the ioctl take a shmem filehandle and offset instead of a virtual > > address). > > > > But maybe it is better then to just extend vgem, i.e. add support to > > create gem objects from existing shmem. > > > > Comments? > > Yes, extending vgem instead of creating something new sounds like a good > idea to me as well. +1 on adding a vgem "import from shmem/memfd" ioctl. Sounds like a good idea, and generally useful. We might want to limit to memfd though for semantic reasons: dma-buf have invariant size, shmem not so much. memfd can be locked down to not change their size anymore. And iirc the core mm page invalidation protocol around truncate() is about as bad as get_user_pages vs cow :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch