[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180301205315.GJ19007@ziepe.ca>
Date: Thu, 1 Mar 2018 13:53:15 -0700
From: Jason Gunthorpe <jgg@...pe.ca>
To: Benjamin Herrenschmidt <benh@....ibm.com>
Cc: Dan Williams <dan.j.williams@...el.com>,
Logan Gunthorpe <logang@...tatee.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-pci@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-rdma <linux-rdma@...r.kernel.org>,
linux-nvdimm <linux-nvdimm@...ts.01.org>,
linux-block@...r.kernel.org, Stephen Bates <sbates@...thlin.com>,
Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>,
Keith Busch <keith.busch@...el.com>,
Sagi Grimberg <sagi@...mberg.me>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Max Gurtovoy <maxg@...lanox.com>,
Jérôme Glisse <jglisse@...hat.com>,
Alex Williamson <alex.williamson@...hat.com>,
Oliver OHalloran <oliveroh@....ibm.com>
Subject: Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory
On Fri, Mar 02, 2018 at 07:40:15AM +1100, Benjamin Herrenschmidt wrote:
> 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).
I think you are right on this - even on x86 we must not create
cachable mappings of PCI BARs - there is no way that works the way
anyone would expect.
I think this series doesn't have a problem here only because it never
touches the BAR pages with the CPU.
BAR memory should be mapped into the CPU as WC at best on all arches..
Jason
Powered by blists - more mailing lists