Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp388539ybb; Wed, 25 Mar 2020 01:38:18 -0700 (PDT) X-Google-Smtp-Source: ADFU+vt/vcjS/iVpQyt2nor3jJrefuRAtRptPoaSwcUmp/KMQECkYp8+F4qZKl3aT935c0YNnuq2 X-Received: by 2002:aca:ddc4:: with SMTP id u187mr1703712oig.129.1585125498472; Wed, 25 Mar 2020 01:38:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585125498; cv=none; d=google.com; s=arc-20160816; b=EyWGrPgfZqAY0Hq5DBWHXs05afETk13dt6ZKriWdePJR0RAS4Uf8NIvPQ3NsDWa+6E UEvhwbGKd1M+M/n24/VnRt3QlYR5y6Cs4sspszed0D/tQVYUfwj6WFa41cZ8QrUX7b21 M679lAo5PbAAPqtLYJjU84G5w8q3AWoUgp15wsANIg+d7YKBTWcu+vw2OdVo1eAhvdBa BX9iBt300PL1r9sYJNL7sRm3aTkBCC8qsRFfQfAX552TFGB+0gjdmIRJoUpIKMBGZzv4 JHT/8jxK9oWCOvUdgPVc7kZZT6M/D2YK716CPW4Gt5QQvJUoNOl5KDgl4JJ8zwqqnsTQ E1BA== 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:message-id:subject:cc :to:from:date; bh=+I53QTCMhSjCM2SXpkpiKE74/glE7XXr0mCEa3sZ4RQ=; b=XyA6FIPaYuZVLefmZTyZPAmFVTG6AtJNUK56N2XBQQJFNVeW0/UKxyc18OH7BlMRr3 FPmYcHc9FajGtalBF5zejawHu1sfmVEOKRJqRDgbLmKThVXnnxsFoDVnMe9qMPHxPvKY B8Gm0K+64T9dNhV/iIvoheJuz02MpliaxeFWfuQsXkDbq+ftyDM8oiYryLaFssWFRU4w S9Kvolc3ktpa6hmYJup1TRhuMNmurzAWty92Tedav4FoG9asbvuMenwqFoseU6cMt6O8 4Zq8a/ScCVOotAh+ue0RfNt6iw+57eUwtmijK7WGgx7dt5+kkIL1kEJJRnCTcAb6NASF F44w== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 141si9444687oii.44.2020.03.25.01.38.06; Wed, 25 Mar 2020 01:38:18 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727320AbgCYIhn (ORCPT + 99 others); Wed, 25 Mar 2020 04:37:43 -0400 Received: from verein.lst.de ([213.95.11.211]:39686 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726105AbgCYIhn (ORCPT ); Wed, 25 Mar 2020 04:37:43 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 8C21B68BFE; Wed, 25 Mar 2020 09:37:40 +0100 (CET) Date: Wed, 25 Mar 2020 09:37:40 +0100 From: Christoph Hellwig To: Alexey Kardashevskiy Cc: Christoph Hellwig , "Aneesh Kumar K.V" , iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org, Lu Baolu , Greg Kroah-Hartman , Joerg Roedel , Robin Murphy , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device Message-ID: <20200325083740.GC21605@lst.de> References: <20200320141640.366360-1-hch@lst.de> <20200320141640.366360-2-hch@lst.de> <2f31d0dd-aa7e-8b76-c8a1-5759fda5afc9@ozlabs.ru> <20200323083705.GA31245@lst.de> <20200323085059.GA32528@lst.de> <87sghz2ibh.fsf@linux.ibm.com> <20200323172256.GB31269@lst.de> <20200324075402.GJ23447@lst.de> <41975da3-3a4a-fc3c-2b90-8d607cf220e6@ozlabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41975da3-3a4a-fc3c-2b90-8d607cf220e6@ozlabs.ru> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 25, 2020 at 03:51:36PM +1100, Alexey Kardashevskiy wrote: > >> This is for persistent memory which you can DMA to/from but yet it does > >> not appear in the system as a normal memory and therefore requires > >> special handling anyway (O_DIRECT or DAX, I do not know the exact > >> mechanics). All other devices in the system should just run as usual, > >> i.e. use 1:1 mapping if possible. > > > > On other systems (x86 and arm) pmem as long as it is page backed does > > not require any special handling. This must be some weird way powerpc > > fucked up again, and I suspect you'll have to suffer from it. > > > It does not matter if it is backed by pages or not, the problem may also > appear if we wanted for example p2p PCI via IOMMU (between PHBs) and > MMIO might be mapped way too high in the system address space and make > 1:1 impossible. How can it be mapped too high for a direct mapping with a 64-bit DMA mask?