From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 2/2] drm/vgem: use normal cached mmap'ings Date: Fri, 19 Jul 2019 11:09:49 +0200 Message-ID: <20190719090949.GG15868@phenom.ffwll.local> References: <20190716164221.15436-1-robdclark@gmail.com> <20190716164221.15436-2-robdclark@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by gabe.freedesktop.org (Postfix) with ESMTPS id 793A06E3F2 for ; Fri, 19 Jul 2019 09:09:54 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id w20so33815892edd.2 for ; Fri, 19 Jul 2019 02:09:54 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20190716164221.15436-2-robdclark@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Rob Clark Cc: Rob Clark , Deepak Sharma , Rodrigo Siqueira , Eric Biggers , David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Thomas Zimmermann , Emil Velikov List-Id: dri-devel@lists.freedesktop.org T24gVHVlLCBKdWwgMTYsIDIwMTkgYXQgMDk6NDI6MTVBTSAtMDcwMCwgUm9iIENsYXJrIHdyb3Rl Ogo+IEZyb206IFJvYiBDbGFyayA8cm9iZGNsYXJrQGNocm9taXVtLm9yZz4KPiAKPiBTaW5jZSB0 aGVyZSBpcyBubyByZWFsIGRldmljZSBhc3NvY2lhdGVkIHdpdGggdmdlbSwgaXQgaXMgaW1wb3Nz aWJsZSB0bwo+IGVuZCB1cCB3aXRoIGFwcHJvcHJpYXRlIGRldi0+ZG1hX29wcywgbWVhbmluZyB0 aGF0IHdlIGhhdmUgbm8gd2F5IHRvCj4gaW52YWxpZGF0ZSB0aGUgc2htZW0gcGFnZXMgYWxsb2Nh dGVkIGJ5IHZnZW0uICBTbywgYXQgbGVhc3Qgb24gcGxhdGZvcm1zCj4gd2l0aG91dCBkcm1fY2Zs dXNoX3BhZ2VzKCksIHdlIGVuZCB1cCB3aXRoIGNvcnJ1cHRpb24gd2hlbiBjYWNoZSBsaW5lcwo+ IGZyb20gcHJldmlvdXMgdXNhZ2Ugb2YgdmdlbSBibyBwYWdlcyBnZXQgZXZpY3RlZCB0byBtZW1v cnkuCj4gCj4gVGhlIG9ubHkgc2FuZSBvcHRpb24gaXMgdG8gdXNlIGNhY2hlZCBtYXBwaW5ncy4K PiAKPiBTaWduZWQtb2ZmLWJ5OiBSb2IgQ2xhcmsgPHJvYmRjbGFya0BjaHJvbWl1bS5vcmc+Cj4g LS0tCj4gUG9zc2libHkgd2UgY291bGQgZG1hX3N5bmNfKl9mb3Jfe2RldmljZSxjcHV9KCkgb24g ZG1hYnVmIGF0dGFjaC9kZXRhY2gsCj4gYWx0aG91Z2ggdGhlIC0+Z2VtX3ByaW1lX3twaW4sdW5w aW59KCkgQVBJIGlzbid0IHF1aXRlIGlkZWFsIGZvciB0aGF0IGFzCj4gaXQgaXMuICBBbmQgdGhh dCBkb2Vzbid0IHJlYWxseSBoZWxwIGZvciBkcml2ZXJzIHRoYXQgZG9uJ3QgYXR0YWNoLwo+IGRl dGFjaCBmb3IgZWFjaCB1c2UuCj4gCj4gQnV0IEFGQUlDVCB2Z2VtIGlzIG1haW5seSB1c2VkIGZv ciBkbWFidWYgdGVzdGluZywgc28gbWF5YmUgd2UgZG9uJ3QKPiBuZWVkIHRvIGNhcmUgdG9vIG11 Y2ggYWJvdXQgdXNlIG9mIGNhY2hlZCBtbWFwJ2luZ3MuCgpJc24ndCB0aGlzIGdvaW5nIHRvIGhv cnJpYmx5IGJyZWFrIHRlc3RpbmcgYnVmZmVyIHNoYXJpbmcgd2l0aCBTb0MKZGV2aWNlcz8gSSdk IGFzc3VtZSB0aGV5IGFsbCBleHBlY3Qgd3JpdGVjb21iaW5pbmcgbW9kZSB0byBtYWtlIHN1cmUg c3R1ZmYKaXMgY29oZXJlbnQ/CgpBbHNvIGNvdWxkIHdlIGdldCBhd2F5IHdpdGggdGhpcyBieSBz aW1wbHkgZXh0ZW5kaW5nIGRybV9jZmx1c2hfcGFnZXMgZm9yCnRob3NlIGFybSBwbGF0Zm9ybXMg d2hlcmUgd2UgZG8gaGF2ZSBhIGNsZmx1c2ggaW5zdHJ1Y3Rpb24/IFllcyBJIGtub3cKdGhhdCds bCBnZXQgcGVvcGxlIHNjcmVhbWluZywgSSdsbCBzaHJ1ZyA6LSkKCklmIGFsbCB3ZSBuZWVkIHBh dGNoIDEvMiBmb3IgaXMgdGhpcyB2Z2VtIHBhdGNoIHRoZW4gdGhlIGF1ZGl0aW5nIG5lZWRlZCBm b3IKcGF0Y2ggMSBkb2Vzbid0IGxvb2sgYXBwZWFsaW5nIC4uLgotRGFuaWVsCgo+IAo+ICBkcml2 ZXJzL2dwdS9kcm0vdmdlbS92Z2VtX2Rydi5jIHwgNyArKy0tLS0tCj4gIDEgZmlsZSBjaGFuZ2Vk LCAyIGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCj4gCj4gZGlmZiAtLWdpdCBhL2RyaXZl cnMvZ3B1L2RybS92Z2VtL3ZnZW1fZHJ2LmMgYi9kcml2ZXJzL2dwdS9kcm0vdmdlbS92Z2VtX2Ry di5jCj4gaW5kZXggMTFhOGY5OWJhMThjLi5jY2YwYzNmYmQ1ODYgMTAwNjQ0Cj4gLS0tIGEvZHJp dmVycy9ncHUvZHJtL3ZnZW0vdmdlbV9kcnYuYwo+ICsrKyBiL2RyaXZlcnMvZ3B1L2RybS92Z2Vt L3ZnZW1fZHJ2LmMKPiBAQCAtMjU5LDkgKzI1OSw2IEBAIHN0YXRpYyBpbnQgdmdlbV9tbWFwKHN0 cnVjdCBmaWxlICpmaWxwLCBzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKnZtYSkKPiAgCWlmIChyZXQp Cj4gIAkJcmV0dXJuIHJldDsKPiAgCj4gLQkvKiBLZWVwIHRoZSBXQyBtbWFwaW5nIHNldCBieSBk cm1fZ2VtX21tYXAoKSBidXQgb3VyIHBhZ2VzCj4gLQkgKiBhcmUgb3JkaW5hcnkgYW5kIG5vdCBz cGVjaWFsLgo+IC0JICovCj4gIAl2bWEtPnZtX2ZsYWdzID0gZmxhZ3MgfCBWTV9ET05URVhQQU5E IHwgVk1fRE9OVERVTVA7Cj4gIAlyZXR1cm4gMDsKPiAgfQo+IEBAIC0zODIsNyArMzc5LDcgQEAg c3RhdGljIHZvaWQgKnZnZW1fcHJpbWVfdm1hcChzdHJ1Y3QgZHJtX2dlbV9vYmplY3QgKm9iaikK PiAgCWlmIChJU19FUlIocGFnZXMpKQo+ICAJCXJldHVybiBOVUxMOwo+ICAKPiAtCXJldHVybiB2 bWFwKHBhZ2VzLCBuX3BhZ2VzLCAwLCBwZ3Byb3Rfd3JpdGVjb21iaW5lKFBBR0VfS0VSTkVMKSk7 Cj4gKwlyZXR1cm4gdm1hcChwYWdlcywgbl9wYWdlcywgMCwgUEFHRV9LRVJORUwpOwo+ICB9Cj4g IAo+ICBzdGF0aWMgdm9pZCB2Z2VtX3ByaW1lX3Z1bm1hcChzdHJ1Y3QgZHJtX2dlbV9vYmplY3Qg Km9iaiwgdm9pZCAqdmFkZHIpCj4gQEAgLTQxMSw3ICs0MDgsNyBAQCBzdGF0aWMgaW50IHZnZW1f cHJpbWVfbW1hcChzdHJ1Y3QgZHJtX2dlbV9vYmplY3QgKm9iaiwKPiAgCWZwdXQodm1hLT52bV9m aWxlKTsKPiAgCXZtYS0+dm1fZmlsZSA9IGdldF9maWxlKG9iai0+ZmlscCk7Cj4gIAl2bWEtPnZt X2ZsYWdzIHw9IFZNX0RPTlRFWFBBTkQgfCBWTV9ET05URFVNUDsKPiAtCXZtYS0+dm1fcGFnZV9w cm90ID0gcGdwcm90X3dyaXRlY29tYmluZSh2bV9nZXRfcGFnZV9wcm90KHZtYS0+dm1fZmxhZ3Mp KTsKPiArCXZtYS0+dm1fcGFnZV9wcm90ID0gdm1fZ2V0X3BhZ2VfcHJvdCh2bWEtPnZtX2ZsYWdz KTsKPiAgCj4gIAlyZXR1cm4gMDsKPiAgfQo+IC0tIAo+IDIuMjEuMAo+IAoKLS0gCkRhbmllbCBW ZXR0ZXIKU29mdHdhcmUgRW5naW5lZXIsIEludGVsIENvcnBvcmF0aW9uCmh0dHA6Ly9ibG9nLmZm d2xsLmNoCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRy aS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRw czovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbA== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31980C76188 for ; Fri, 19 Jul 2019 09:09:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 06A712184E for ; Fri, 19 Jul 2019 09:09:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="ZjHqBp9z" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727301AbfGSJJz (ORCPT ); Fri, 19 Jul 2019 05:09:55 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:33115 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725794AbfGSJJz (ORCPT ); Fri, 19 Jul 2019 05:09:55 -0400 Received: by mail-ed1-f66.google.com with SMTP id i11so33845405edq.0 for ; Fri, 19 Jul 2019 02:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=QtZzlBozAbYs33LVUIdgRKWQT4+nE9KuwH2UHVZgB3w=; b=ZjHqBp9zPU97B6yu0PFP+IpJnNJhqSs8dAS/qOWxv7eQ+p+CLwdbOkJtg1AXn9QviR u70ayX/AeTUZCV4FUoyqg4/z3MvcNG0xlQyaVtc5baUN/RgkJZq6j8tHA32joQx0H/fh 3FSXEXO0gR2Pu3A3WYc2oGTCZ5i1qL60fG3MA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=QtZzlBozAbYs33LVUIdgRKWQT4+nE9KuwH2UHVZgB3w=; b=eNp6ECg++CmNNLs+Ogma+Yfu6XF102NTqTiryH0q22aolrLRQHavxzI44ZLXfUvAKL tPNPeGSwUyuuHKryYnhD+wWJRoDteskrKJfALnBq/tcr6AQ9lMq+AoQM3cKB4cU92qzO K5CIxAd7cEy3CjaEwHBY2/GU4roOGm5MRsxEOyMab7bG1SLwxLwAze8Xd2uHuKghRY41 hY2P/BkwBcpF/3jhLTL0Cjb133xSBaXePGf8cATB9kDZ7ffttp82uj1WmZdQdk2jl0LO XBqwkiATKxjpaKkg03m2Ua9EwR0rhkx/symEnpiYvHN4k/X93mUuO4w5CvQKwbw0gM96 p0zQ== X-Gm-Message-State: APjAAAUal2stZUadaBNryiXBDFPtN731L5hF33ebL/gNijoAxcaiJZ7q BgmR4Elj4SN5x6iTFT0iTGM= X-Google-Smtp-Source: APXvYqz8f63eAZPRL6XnHtE9vjjY4sAq26Cn1bxQCf8vHh8X+UCGguYSp3llWAL+UCehKz+PuPqgWQ== X-Received: by 2002:a17:906:2599:: with SMTP id m25mr39234387ejb.177.1563527393135; Fri, 19 Jul 2019 02:09:53 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id b25sm8484369eda.38.2019.07.19.02.09.51 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 19 Jul 2019 02:09:51 -0700 (PDT) Date: Fri, 19 Jul 2019 11:09:49 +0200 From: Daniel Vetter To: Rob Clark Cc: dri-devel@lists.freedesktop.org, Rob Clark , David Airlie , Daniel Vetter , Emil Velikov , Thomas Zimmermann , Rodrigo Siqueira , Eric Biggers , Imre Deak , Deepak Sharma , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] drm/vgem: use normal cached mmap'ings Message-ID: <20190719090949.GG15868@phenom.ffwll.local> Mail-Followup-To: Rob Clark , dri-devel@lists.freedesktop.org, Rob Clark , David Airlie , Emil Velikov , Thomas Zimmermann , Rodrigo Siqueira , Eric Biggers , Imre Deak , Deepak Sharma , linux-kernel@vger.kernel.org References: <20190716164221.15436-1-robdclark@gmail.com> <20190716164221.15436-2-robdclark@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190716164221.15436-2-robdclark@gmail.com> X-Operating-System: Linux phenom 4.19.0-5-amd64 User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 16, 2019 at 09:42:15AM -0700, Rob Clark wrote: > From: Rob Clark > > Since there is no real device associated with vgem, it is impossible to > end up with appropriate dev->dma_ops, meaning that we have no way to > invalidate the shmem pages allocated by vgem. So, at least on platforms > without drm_cflush_pages(), we end up with corruption when cache lines > from previous usage of vgem bo pages get evicted to memory. > > The only sane option is to use cached mappings. > > Signed-off-by: Rob Clark > --- > Possibly we could dma_sync_*_for_{device,cpu}() on dmabuf attach/detach, > although the ->gem_prime_{pin,unpin}() API isn't quite ideal for that as > it is. And that doesn't really help for drivers that don't attach/ > detach for each use. > > But AFAICT vgem is mainly used for dmabuf testing, so maybe we don't > need to care too much about use of cached mmap'ings. Isn't this going to horribly break testing buffer sharing with SoC devices? I'd assume they all expect writecombining mode to make sure stuff is coherent? Also could we get away with this by simply extending drm_cflush_pages for those arm platforms where we do have a clflush instruction? Yes I know that'll get people screaming, I'll shrug :-) If all we need patch 1/2 for is this vgem patch then the auditing needed for patch 1 doesn't look appealing ... -Daniel > > drivers/gpu/drm/vgem/vgem_drv.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > index 11a8f99ba18c..ccf0c3fbd586 100644 > --- a/drivers/gpu/drm/vgem/vgem_drv.c > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > @@ -259,9 +259,6 @@ static int vgem_mmap(struct file *filp, struct vm_area_struct *vma) > if (ret) > return ret; > > - /* Keep the WC mmaping set by drm_gem_mmap() but our pages > - * are ordinary and not special. > - */ > vma->vm_flags = flags | VM_DONTEXPAND | VM_DONTDUMP; > return 0; > } > @@ -382,7 +379,7 @@ static void *vgem_prime_vmap(struct drm_gem_object *obj) > if (IS_ERR(pages)) > return NULL; > > - return vmap(pages, n_pages, 0, pgprot_writecombine(PAGE_KERNEL)); > + return vmap(pages, n_pages, 0, PAGE_KERNEL); > } > > static void vgem_prime_vunmap(struct drm_gem_object *obj, void *vaddr) > @@ -411,7 +408,7 @@ static int vgem_prime_mmap(struct drm_gem_object *obj, > fput(vma->vm_file); > vma->vm_file = get_file(obj->filp); > vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; > - vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); > + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); > > return 0; > } > -- > 2.21.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch