From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 337BC224E6926 for ; Thu, 1 Mar 2018 12:34:19 -0800 (PST) Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w21Kccx7002591 for ; Thu, 1 Mar 2018 15:40:28 -0500 Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by mx0b-001b2d01.pphosted.com with ESMTP id 2gepmavyvh-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 01 Mar 2018 15:40:27 -0500 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 1 Mar 2018 20:40:25 -0000 Subject: Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory From: Benjamin Herrenschmidt Date: Fri, 02 Mar 2018 07:40:15 +1100 In-Reply-To: <1519936477.4592.23.camel@au1.ibm.com> References: <20180228234006.21093-1-logang@deltatee.com> <1519876489.4592.3.camel@kernel.crashing.org> <1519876569.4592.4.camel@au1.ibm.com> <1519936477.4592.23.camel@au1.ibm.com> Mime-Version: 1.0 Message-Id: <1519936815.4592.25.camel@au1.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: benh@au1.ibm.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Jens Axboe , Keith Busch , Oliver OHalloran , Alex Williamson , linux-nvdimm , linux-rdma , linux-pci@vger.kernel.org, Linux Kernel Mailing List , linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, =?ISO-8859-1?Q?J=E9r=F4me?= Glisse , Jason Gunthorpe , Bjorn Helgaas , Max Gurtovoy , Christoph Hellwig List-ID: On Fri, 2018-03-02 at 07:34 +1100, Benjamin Herrenschmidt wrote: > > But what happens with that PCI memory ? Is it effectively turned into > nromal memory (ie, usable for normal allocations, potentially used to > populate user pages etc...) or is it kept aside ? (What I mean is is it added to the page allocator basically) Also we need to be able to hard block MEMREMAP_WB mappings of non-RAM on ppc64 (maybe via an arch hook as it might depend on the processor family). Server powerpc cannot do cachable accesses on IO memory (unless it's special OpenCAPI or nVlink, but not on PCIe). > Also on ppc64, the physical addresses of PCIe make it so far appart > that there's no way we can map them into the linear mapping at the > normal offset of PAGE_OFFSET + (pfn << PAGE_SHIFT), so things like > page_address or virt_to_page cannot work as-is on PCIe addresses. Talking of which ... is there any documentation on the whole memremap_page ? my grep turned out empty... Cheers, Ben. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm