Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751483AbdDNERh (ORCPT ); Fri, 14 Apr 2017 00:17:37 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:43447 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750AbdDNERf (ORCPT ); Fri, 14 Apr 2017 00:17:35 -0400 Date: Thu, 13 Apr 2017 22:16:56 -0600 From: Jason Gunthorpe To: Bjorn Helgaas Cc: Logan Gunthorpe , Benjamin Herrenschmidt , Christoph Hellwig , Sagi Grimberg , "James E.J. Bottomley" , "Martin K. Petersen" , Jens Axboe , Steve Wise , Stephen Bates , Max Gurtovoy , Dan Williams , Keith Busch , linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org, linux-nvdimm@ml01.01.org, linux-kernel@vger.kernel.org, Jerome Glisse Subject: Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory Message-ID: <20170414041656.GA30694@obsidianresearch.com> References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1491974532.7236.43.camel@kernel.crashing.org> <5ac22496-56ec-025d-f153-140001d2a7f9@deltatee.com> <1492034124.7236.77.camel@kernel.crashing.org> <81888a1e-eb0d-cbbc-dc66-0a09c32e4ea2@deltatee.com> <20170413232631.GB24910@bhelgaas-glaptop.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170413232631.GB24910@bhelgaas-glaptop.roam.corp.google.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1223 Lines: 23 On Thu, Apr 13, 2017 at 06:26:31PM -0500, Bjorn Helgaas wrote: > > Ah, thanks for the tip! On my system, this translation returns the same > > address so it was not necessary. And, yes, that means this would have to > > find its way into the dma mapping routine somehow. This means we'll > > eventually need a way to look-up the p2pmem device from the struct page. > > Which means we will likely need a new flag bit in the struct page or > > something. The big difficulty I see is testing. Do you know what > > architectures or in what circumstances are these translations used? > > Any caller of pci_add_resource_offset() uses CPU addresses different from > the PCI bus addresses (unless the offset is zero, of course). All ACPI > platforms also support this translation (see "translation_offset"), though > in most x86 systems the offset is zero. I'm aware of one x86 system that > was tested with a non-zero offset but I don't think it was shipped that > way. I'd suggest just detecting if there is any translation in bus addresses anywhere and just hard disabling P2P on such systems. On modern hardware with 64 bit BARs there is very little reason to have translation, so I think this is a legacy feature. Jason