Received: by 10.192.165.148 with SMTP id m20csp383924imm; Wed, 25 Apr 2018 00:43:35 -0700 (PDT) X-Google-Smtp-Source: AIpwx48ffzQFfxvfEgFhH2xJVySqY5sT6ytnTyBFDQGWmizceAUjbiHOKL1fVbUEdNQPFmGfA5eH X-Received: by 2002:a17:902:5389:: with SMTP id c9-v6mr18369158pli.143.1524642215475; Wed, 25 Apr 2018 00:43:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524642215; cv=none; d=google.com; s=arc-20160816; b=sjIEhFtKZhrX3fIzQqXVkG/4V3+S7+LPyV7bS6EMoeMSeFYSSqx7SklSwPNtG8OsFk RRWZ513ROjrsbwflC4Vpxac7+3Yd75NVHEVFLD4k+sMwVDv60iRIIudSTsOFL7e+sRPm WOWqnB+9Pvs+rJ5FwbZDeoagwBPG4H09nfkwZC8NGef3fCBN0QzqIrZM5zGIb8ra6Ffs xfKAgFI0yn3Tx7grBuRiwotLJVwfFcRnBmxCjJBgM86cSz5X6XebMkZ4R2y20vGGJaau ezAQaznQiwefuWc6af7z3QSIG5NseFRvNFdFDXY+ryXWXLjyeNkz19NKAPcLBpZbUZZe M0mg== 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:cc:to:from :date:arc-authentication-results; bh=9xk3rpZtAn8CnKG2A+oQ6tMhAM7s3C5HVQZOsCBd6cM=; b=i2s1N+gtw8jZsDuK4xIoDpSFGIK4IGTbBUarULd9aXnEW0kAkKhVCvy5VdON6UDRyL r8rE1IISF7l9q2SwaiVVR7Q+UIvzZPR8hu687VT11PoztLOMZ09/1WiaHj7zg+2wOOQu R66oX/vfcuc4SjII3dfsarUjxw601GldOh66rS5Tjs35fqDdFvsD9OnTXPS2TgjAV1Vk 2bGkRc3/B87fkenpEyWvlUcO7JdzMxrhclJoOBzVL+ny61t/4IVMmQ9NqmK1flVmCwcn HuUI178Tymu2vnQjwgkmoUTQtekohfD7YVLmqy9CznJFvaWz5ipv2VIVryNDeixm67bp ncVA== 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 a9si12758619pgu.454.2018.04.25.00.43.21; Wed, 25 Apr 2018 00:43:35 -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 S1751360AbeDYHmE (ORCPT + 99 others); Wed, 25 Apr 2018 03:42:04 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:7604 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750962AbeDYHl6 (ORCPT ); Wed, 25 Apr 2018 03:41:58 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate16.nvidia.com id ; Wed, 25 Apr 2018 00:41:40 -0700 Received: from HQMAIL104.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Wed, 25 Apr 2018 00:41:57 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Wed, 25 Apr 2018 00:41:57 -0700 Received: from UKMAIL101.nvidia.com (10.26.138.13) by HQMAIL104.nvidia.com (172.18.146.11) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 25 Apr 2018 07:41:56 +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:41:52 +0000 Date: Wed, 25 Apr 2018 09:41:51 +0200 From: Thierry Reding To: Christoph Hellwig CC: Daniel Vetter , 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: <20180425074151.GA2271@ulmo> References: <20180420101755.GA11400@infradead.org> <20180420124625.GA31078@infradead.org> <20180420152111.GR31310@phenom.ffwll.local> <20180424184847.GA3247@infradead.org> <20180425054855.GA17038@infradead.org>

<20180425064335.GB28100@infradead.org> MIME-Version: 1.0 In-Reply-To: <20180425064335.GB28100@infradead.org> 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="3MwIy2ne0vdjdPXF" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 24, 2018 at 11:43:35PM -0700, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote: > > For more fun: > >=20 > > https://www.spinics.net/lists/dri-devel/msg173630.html > >=20 > > Yeah, sometimes we want to disable the iommu because the on-gpu > > pagetables are faster ... >=20 > I am not on this list, but remote NAK from here. This needs an > API from the iommu/dma-mapping code. Drivers have no business poking > into these details. The interfaces that the above patch uses are all EXPORT_SYMBOL_GPL, which is rather misleading if they are not meant to be used by drivers directly. > Thierry, please resend this with at least the iommu list and > linux-arm-kernel in Cc to have a proper discussion on the right API. I'm certainly open to help with finding a correct solution, but the patch above was purposefully terse because this is something that I hope we can get backported to v4.16 to unbreak Nouveau. Coordinating such a backport between ARM and DRM trees does not sound like something that would help getting this fixed in v4.16. The fundamental issue here is that the DMA/IOMMU integration is something that has caused a number of surprising regressions in the past because it tends to sneak in unexpectedly. For example the current regression shows up only if CONFIG_ARM_DMA_USE_IOMMU=3Dy because the DMA API will then transparently create a second mapping and mess things up. Everything works fine if that option is disabled. This is ultimately why we didn't notice, since we don't enable that option by default. I do have a patch that I plan to apply to the Tegra tree that will always enable CONFIG_ARM_DMA_USE_IOMMU=3Dy on Tegra to avoid any such surprises in the future, but I can obviously only apply that once the above patch is applied to Nouveau, otherwise we'll break Nouveau unconditionally. Granted, this issue could've been caught with a little more testing, but in retrospect I think it would've been a lot better if ARM_DMA_USE_IOMMU was just enabled unconditionally if it has side-effects that platforms don't opt in to but have to explicitly opt out of. Thierry --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlrgMTwACgkQ3SOs138+ s6FhzxAAhAWFPLKYY1teMqCaHfPUBIUiOMRZJU7ufMMjY28rJFHHZGQoa0Tj3WzZ 2msD0RZKxdnYuRAs90G3XHtYYULICSYi3XJ31V9pLHHmptLNHmeAbzQ39lLue19L Cc+1LozOpc99zmDTW94SdXzzoIqHzaPA0Pm+020+np6ASBxfn5jnkVTbB48Wm4WF ug5gt+6n7jCX3jXOomaHJVeZKSCj57SIKb9YxJ7kconRU6J3zgVSaprku2yxKpeV /ii6IdAMlb1vpFi126ssD81aJ72e2yWBwegLkn2m+exnz7BzkL2qs82ERiTYJZ8x IeKoC8tNQcA1Ev6v8MpeUjpaGJuiTQjXXUvrBj3xh5hG+5yt8gFcRE1h4/hFHz2O /GJwPNfWZsESd82c/uOAEGhuYiRkh85mP3JqRZOXt3xryf9tdpqGf6YI0dpE6Yle Xc1hNRdDOKPswQxdSKoI75yRWD42fWEr2g3nY2KQO/FMZqPMq8Sp/vGzoBI1ZALH W3f6ACLxBzrmUtLcBWWX20FoQ+wwrQefezXXljVIU8i/ZPh1Pcn9u9PCAW3FgGV6 lSdzTjsupvbC5rFvH/JL0vKcBf1UAZdctbV5preQOGBOv0qyy/mSPDUJCRhZc3M5 A5Y0hGYKZPw4EyGyA/YzsqcOFj5EmdXS5DQVoeYk/8ENbm+WEHI= =wFUj -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF--