From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935112AbdAJKso (ORCPT ); Tue, 10 Jan 2017 05:48:44 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:63446 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932493AbdAJKsl (ORCPT ); Tue, 10 Jan 2017 05:48:41 -0500 From: Arnd Bergmann To: Christoph Hellwig Cc: Nikita Yushchenko , linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Simon Horman , linux-pci@vger.kernel.org, Bjorn Helgaas , artemi.ivanov@cogentembedded.com, Keith Busch , Jens Axboe , Sagi Grimberg , linux-nvme@lists.infradead.org Subject: Re: [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask Date: Tue, 10 Jan 2017 11:47:42 +0100 Message-ID: <1988852.3nyUoruEjG@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20170109205746.GA6274@lst.de> References: <1483044304-2085-1-git-send-email-nikita.yoush@cogentembedded.com> <20170109205746.GA6274@lst.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:93C0+7wB2PFfzsAyCtg0rIJUvfVzWaDAWjZhf1ky/ke0bcEtnc4 if5M2r5F0DiYx7dZUF3buwlH2GLKurRGFirs7zDL6O5x/qwfFdSmaT9I1qgxxVLziHj3XFq kwo8/KRBjpVuCeJDOpZ6uZFpcq65c55An4Va3WS1QUhIc4ErJ5vf31Il+aK6L1h6bG/DRIS 8dlETIZ/yFvsfm0zau6ZQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:N7mJAw5+ers=:hnRkEbR6t2Ip671qdCKpVP V+eWsx4yJE7IybLMDnN2OyJXKded5GOxuE+ARjh9sA7vu4bGj/iG88A5zIdWZXZWmPO5lzKTn L4fuFw5FjkDf2VboCpgAigdshC+JxRP3QrNNNyQl1WG9/MD6X4aFMXsFggcWm5clgz48fH+MH qfZo3zl6ewFMoD5a27KtEYPJxfHjkcJK9rv9ILdXi2kPz61Nt+UF2OAyNs9tbDenhGFrxtuFJ 79/fHui+tyTgXeQJ0OH21FqFRK0o9sMIg3a9cAdf1kVSHQJqxMSt0ilkQOgdxcOZqim87jCWe fEajCbPpskzEJ3DJQZ4o68Gfljc7VQFbsk+rXuz40P2YnBi4WE5bEsqBi7dJX8LuymPL8ERBQ VGMC6Ep5e7b2s4Rg3A6+viP3g347G84RyRwDFc04wt41SvvYqPldfTYUPD57K6XX8eYjEjSZW udqziQmag1Qu/VIzdLADLpbqydrJsQcwZEbi4o86ROstXqyiDXAqTcmEMg63MP9CcpVxP04ZD rnwIw7Mh+vmrGjDV8p/ksiCHrrhiE0d9gvDQMu3kfJSwdYjEivre4ejlLY3pglyNU9rfS5tRq sk1er2X82jYtDWaIkXVtgB98WYJkUg6e/EwqVZFY6Bq1za80oRsetGYzrbOYie6KmlwCTmEZC Gq+bncAda7Q+TygjWMjvCMsMvAaZ3o6Yi3IAMYYULYhmHZ+CKGBpx2HHWbkAtN+qtFa+lE15q ieD/+OJSEDT9MpY9 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, January 9, 2017 9:57:46 PM CET Christoph Hellwig wrote: > > - architecture should stop breaking 64-bit DMA when driver attempts to > > set 64-bit dma mask, > > > > - NVMe should issue proper blk_queue_bounce_limit() call based on what > > is actually set mask, > > Or even better remove the call to dma_set_mask_and_coherent with > DMA_BIT_MASK(32). NVMe is designed around having proper 64-bit DMA > addressing, there is not point in trying to pretent it works without that Agreed, let's just fail the probe() if DMA_BIT_MASK(64) fails, and have swiotlb work around machines that for some reason need bounce buffers. > > - and blk_queue_bounce_limit() should also be fixed to actually set > > 0xffffffff limit, instead of replacing it with (max_low_pfn << > > PAGE_SHIFT) as it does now. > > We need to kill off BLK_BOUNCE_HIGH, it just doesn't make sense to > mix the highmem aspect with the addressing limits. In fact the whole > block bouncing scheme doesn't make much sense at all these days, we > should rely on swiotlb instead. If we do this, we should probably have another look at the respective NETIF_F_HIGHDMA support in the network stack, which does the same thing and mixes up highmem on 32-bit architectures with the DMA address limit. (side note: there are actually cases in which you have a 31-bit DMA mask but 3 GB of lowmem using CONFIG_VMSPLIT_1G, so BLK_BOUNCE_HIGH and !NETIF_F_HIGHDMA are both missing the limit, causing data corruption without swiotlb). Before we rely too much on swiotlb, we may also need to consider which architectures today rely on bouncing in blk and network. I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of 32-bit architectures without swiotlb (arc, arm, some mips32), and there are several 64-bit architectures that do not have swiotlb (alpha, parisc, s390, sparc). I believe that alpha, s390 and sparc always use some form of IOMMU, but the other four apparently don't, so we would need to add swiotlb support there to remove all the bounce buffering in network and block layers. Arnd