Received: by 10.192.165.148 with SMTP id m20csp394545imm; Wed, 25 Apr 2018 00:58:15 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+GfOrPlWQnzeLzLkaQnXV6Lzw/GhhCPPqCU1t/BMNwooMxhT8zY9GL1iEAWjPR14gCbcQK X-Received: by 10.99.119.195 with SMTP id s186mr22113683pgc.296.1524643095223; Wed, 25 Apr 2018 00:58:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524643095; cv=none; d=google.com; s=arc-20160816; b=gpMJKL6wa7ReVFAzXO9cjHOEmOTC09uzCpQqZepLzTqSehjLQNaGiVHxOvqSDaX6gw nRyKuTie45cgdYuKYMCfMOuYrpw5Cg7jEjzZqCmpk3A3aLL9WLVLBcrQ7gSjsmpBHuDM +YMhqo1ywGFjMxgTAIgloFJGx61b63doXkfKcV24crKz6V44FS9o1O7nXULbXpBWZITx KInn87GCwdZmT5MbAbqlq72+KNzEYNCO0IBhKlQefLINg+aal8xAjx9DxUYTlp7RIbA4 5bBZ+bFpzu0lgDZ5NBNu7uiBlvF3Hv+9Fia/1QtOYzdoXt6VXQ3l1DtGVKExBkMg99jr AR4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition:user-agent :in-reply-to:mime-version:references:message-id:subject:to:from:date :arc-authentication-results; bh=UE6PlPHk+9DaBoITGjEWs+8lKxO4AA3gf6nCOe+OG3Q=; b=ulotxnOE0VWJSuvdRHFNjp26Z/iIOarmO4HDVn+gg5TvpcCG5fd/2zdEVx37rtEtX4 xA1CnS6heI9YayeaCVS9jjBn0eoRnjlsYfI/W4zhfVasq1iHwzobr5NhGTjthY+X5eqn DaDdft+iZ4VfXt8Gr2JXTT5csJtI4MsfcAajXslhDwdsSRTj0H0+sThwAfrzE9rkdjGG eK7Q8h5tGmkfm7pD/3WEgzOG/7nu/4MWEzhYKce6uYEgc/YZaOTCs/JN97QzHThBSjGx qPshkXMD4E+q/9Sr1tVK8tKwR5oM/25uOqx9+bM7JGoUA38NNhq8CZ2wbcvxmGxoorKw +ndw== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f34-v6si15961985plf.362.2018.04.25.00.58.00; Wed, 25 Apr 2018 00:58:15 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751276AbeDYH4x (ORCPT + 99 others); Wed, 25 Apr 2018 03:56:53 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:4441 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750882AbeDYH4u (ORCPT ); Wed, 25 Apr 2018 03:56:50 -0400 Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com id ; Wed, 25 Apr 2018 00:57:03 -0700 Received: from HQMAIL107.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Wed, 25 Apr 2018 00:56:48 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Wed, 25 Apr 2018 00:56:48 -0700 Received: from UKMAIL101.nvidia.com (10.26.138.13) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 25 Apr 2018 07:56:49 +0000 Received: from localhost (10.21.62.231) by UKMAIL101.nvidia.com (10.26.138.13) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 25 Apr 2018 07:56:45 +0000 Date: Wed, 25 Apr 2018 09:56:43 +0200 From: Thierry Reding To: Christoph Hellwig , Christian =?utf-8?B?S8O2bmln?= , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Linux Kernel Mailing List , amd-gfx list , Jerome Glisse , dri-devel , Dan Williams , Logan Gunthorpe , "open list:DMA BUFFER SHARING FRAMEWORK" Subject: Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag Message-ID: <20180425075643.GC2271@ulmo> References: <20180420152111.GR31310@phenom.ffwll.local> <20180424184847.GA3247@infradead.org> <20180425054855.GA17038@infradead.org>

<20180425064335.GB28100@infradead.org> <20180425070905.GA24827@infradead.org> <20180425073039.GO25142@phenom.ffwll.local> MIME-Version: 1.0 In-Reply-To: <20180425073039.GO25142@phenom.ffwll.local> X-NVConfidentiality: public User-Agent: Mutt/1.9.5 (2018-04-13) X-Originating-IP: [10.21.62.231] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FsscpQKzF/jJk6ya" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --FsscpQKzF/jJk6ya Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 25, 2018 at 09:30:39AM +0200, Daniel Vetter wrote: > On Wed, Apr 25, 2018 at 12:09:05AM -0700, Christoph Hellwig wrote: > > On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote: > > > Can we please not nack everything right away? Doesn't really motivate > > > me to show you all the various things we're doing in gpu to make the > > > dma layer work for us. That kind of noodling around in lower levels to > > > get them to do what we want is absolutely par-for-course for gpu > > > drivers. If you just nack everything I point you at for illustrative > > > purposes, then I can't show you stuff anymore. > >=20 > > No, it's not. No driver (and that includes the magic GPUs) has > > any business messing with dma ops directly. > >=20 > > A GPU driver imght have a very valid reason to disable the IOMMU, > > but the code to do so needs to be at least in the arch code, maybe > > in the dma-mapping/iommu code, not in the driver. > >=20 > > As a first step to get the discussion started we'll simply need > > to move the code Thierry wrote into a helper in arch/arm and that > > alone would be a massive improvement. I'm not even talking about > > minor details like actually using arm_get_dma_map_ops instead > > of duplicating it. > >=20 > > And doing this basic trivial work really helps to get this whole > > mess under control. >=20 > Ah ok. It did sound a bit like a much more cathegorical NAK than an "ack > in principle, but we need to shuffle the implementation into the right > place first". In the past we generally got a principled NAK on anything > funny we've been doing with the dma api, and the dma api maintainer > steaming off telling us we're incompetent idiots. I guess I've been > branded a bit on this topic :-/ >=20 > Really great that this is changing now. >=20 > On the patch itself: It might not be the right thing in all cases, since > for certain compression formats the nv gpu wants larger pages (easy to > allocate from vram, not so easy from main memory), so might need the iommu > still. But currently that's not implemented: >=20 > https://www.spinics.net/lists/dri-devel/msg173932.html To clarify: we do want to use the IOMMU, but we want to use it explicitly via the IOMMU API rather than hiding it behind the DMA API. We do the same thing in Tegra DRM where we don't want to use the DMA API because it doesn't allow us to share the same mapping between multiple display controllers in the same way the IOMMU API does. We've also been thinking about using the IOMMU API directly in order to support process isolation for devices that accept command streams from userspace. Fortunately the issue I'm seeing with Nouveau doesn't happen with Tegra DRM, which seems to be because we have an IOMMU group with multiple devices and that prevents the DMA API from "hijacking" the IOMMU domain for the group. And to add to the confusion, none of this seems to be an issue on 64-bit ARM where the generic DMA/IOMMU code from drivers/iommu/dma-iommu.c is used. Thierry --FsscpQKzF/jJk6ya Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlrgNLkACgkQ3SOs138+ s6FElA//Y4UG8175+Ww3Twe0Ng/0nU5D/3QkBRvSl+IZ1fTkAGn3XUtQVX4Ll8Wb GbFn/WLFr87S4+E+LMBIJ526piuRzgXbLqL3X7Q8IOvx7JRWtux9iSlxznCr+hDe L6u+d8oKoXjGotnmC9bZTWRRGkijAYojYYBkMWCrOS1TkMCgkiKc0g5kb1KisTaK ttVUVendpNQsHMWZzPTXhVPfkBMdVvcbHdgaim1VD+NTRJaJ70S0Q0jhIgxqa18L thYrCuJkYweE/yjlHezXo2BMGEeNTBp0khA1lXeCOp5dfv6W8Z/BcGS15OZQ+Ufg Dl1Dwfq7WPOB7YB/KQdW4V7FI/h8gSzY4c0+oPMNvESrlqmoSGUHIHp7XV/ngL+T Bq/pN7eKUImjMXa/wTzEUzjglRMxFpg6WEwV/7q1QDxgyoKWPKp5a3fa4qXonGIB Qf43OcYWBqLAlpFpY03u/UUbdjwwOglZRM7Jo2p70sN90ISu6QpV/RNo26KylJJN xEjE4CtIDRD/qHUegL6juDcC8tgCO7EPV/pqsvp6R6UmpguH0HT+TkG7TteR7lkh CZm6xle9cx/2g7C4QMxgOHXGgFhxYQdJvwzKfm/UzFbBEs4iLk4iClYctRdnJRAz 3iWTou/HjHB3lArCebHYBEAxXMIUrUGwbFZdF+gm3BeP97e2x5o= =M8KY -----END PGP SIGNATURE----- --FsscpQKzF/jJk6ya--