Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3373124ybi; Fri, 19 Jul 2019 02:12:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqxVmP4xO5kqSo+bhNtWwVkrIkR6xahZFYjJSuUHpEUEktzW9IxuhOeYHCQT3InAdf9gmGPy X-Received: by 2002:a63:4846:: with SMTP id x6mr16388244pgk.332.1563527533596; Fri, 19 Jul 2019 02:12:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563527533; cv=none; d=google.com; s=arc-20160816; b=nuLRSGwUadyRz9KFU3+4P8JwZkBKcxjyeBtXIKI4ODTIv/tt1KTvncGV0756BNk+kc txmFGUFA+ANWf9H86m4hjDI0tpIuqqfk+uYlk29x4eSbxk4CxLv3vY70u9E8ewhE7q1t a0OJ2w8nr8ejRR5hvQ14uOB3/fG/oLgz6H56bmLb92eJwB+A1owNWvz5Imk0tW+TYmsi kTZe/K/V+q57HyECw9eQt5TPLBdfb3PTSUgL2u3WLTpLxPdBBwAbCdHxvfroL5l6vHRj 1UEqeZhyl39QA4NUezHIF0IM+7IAh4NHlNx3P3L6p+3lu0xKsODNT4swlvvtgvbWL35u Vf8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=QtZzlBozAbYs33LVUIdgRKWQT4+nE9KuwH2UHVZgB3w=; b=FvyvDnHwVh6Xw5mxWbfTfzkbMwtELq3Rvob8V/R2uBVcQTfgyqTv/84QmzjNRf+ktL i8PZRQfuNeoDg9OZMr40J2sH3GFhkoJaFWCpmCUioxIWvt3bFPTxGs3NJPD6h2n0kgKE 7tt3gyFMJLeE3pmYLynhh5CTjfr2bBmZeUxQhBurFsoVWX/k8x7yKeinYToTydJu+Qxc 0OdbFU0RoEGL5FpMESmHlSSjht1IpPQ+gOSjNEA9IOfL0UvhSdSHJUvn5vCi5HAkw1OS Xcod8zLj/d4oRFA47jHUI5UqT3NKpajunAY7PwF1qlnNvc646SsuiLH/1+UFGl23Oycm I+gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=ZjHqBp9z; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e129si1524955pgc.344.2019.07.19.02.11.57; Fri, 19 Jul 2019 02:12:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@ffwll.ch header.s=google header.b=ZjHqBp9z; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727056AbfGSJJz (ORCPT + 99 others); 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-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