From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 12/21] dma-iommu: factor atomic pool allocations into helpers Date: Tue, 23 Apr 2019 16:52:36 +0200 Message-ID: <20190423145236.GA22253@lst.de> References: <20190327080448.5500-1-hch@lst.de> <20190327080448.5500-13-hch@lst.de> <20190410061157.GA5278@lst.de> <20190417063358.GA24139@lst.de> <83615173-a8b4-e0eb-bac3-1a58d61ea4ef@arm.com> <20190418163512.GA25347@lst.de> <228ee57a-d7b2-48e0-a34e-81d5fba0a090@arm.com> <20190419082348.GA22299@lst.de> <0a6b3f53-79e5-af83-be39-f04c9acd8384@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <0a6b3f53-79e5-af83-be39-f04c9acd8384@arm.com> Sender: linux-kernel-owner@vger.kernel.org To: Robin Murphy Cc: Christoph Hellwig , Joerg Roedel , Catalin Marinas , Will Deacon , Tom Lendacky , iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org List-Id: iommu@lists.linux-foundation.org On Tue, Apr 23, 2019 at 11:01:44AM +0100, Robin Murphy wrote: > On 19/04/2019 09:23, Christoph Hellwig wrote: >> On Thu, Apr 18, 2019 at 07:15:00PM +0100, Robin Murphy wrote: >>> Still, I've worked in the vm_map_pages() stuff pending in MM and given them >>> the same treatment to finish the picture. Both x86_64_defconfig and >>> i386_defconfig do indeed compile and link fine as I expected, so I really >>> would like to understand the concern around #ifdefs better. >> >> This looks generally fine to me. One thing I'd like to do is to >> generally make use of the fact that __iommu_dma_get_pages returns NULL >> for the force contigous case as that cleans up a few things. Also >> for the !DMA_REMAP case we need to try the page allocator when >> dma_alloc_from_contiguous does not return a page. What do you thing >> of the following incremental diff? If that is fine with you I can >> fold that in and add back in the remaining patches from my series >> not obsoleted by your patches and resend. > > Wouldn't this suffice? Since we also use alloc_pages() in the coherent > atomic case, the free path should already be able to deal with it. Yepp, that is about what I've done in v3, except that I've also folded that coherent atomic case in a way very similar to dma-direct. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27189C282E1 for ; Tue, 23 Apr 2019 14:52:55 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F1457217D9 for ; Tue, 23 Apr 2019 14:52:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1457217D9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id B1E6DB43; Tue, 23 Apr 2019 14:52:54 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4E6A07F6 for ; Tue, 23 Apr 2019 14:52:53 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B552A82B for ; Tue, 23 Apr 2019 14:52:52 +0000 (UTC) Received: by newverein.lst.de (Postfix, from userid 2407) id C167F68AFE; Tue, 23 Apr 2019 16:52:36 +0200 (CEST) Date: Tue, 23 Apr 2019 16:52:36 +0200 From: Christoph Hellwig To: Robin Murphy Subject: Re: [PATCH 12/21] dma-iommu: factor atomic pool allocations into helpers Message-ID: <20190423145236.GA22253@lst.de> References: <20190327080448.5500-1-hch@lst.de> <20190327080448.5500-13-hch@lst.de> <20190410061157.GA5278@lst.de> <20190417063358.GA24139@lst.de> <83615173-a8b4-e0eb-bac3-1a58d61ea4ef@arm.com> <20190418163512.GA25347@lst.de> <228ee57a-d7b2-48e0-a34e-81d5fba0a090@arm.com> <20190419082348.GA22299@lst.de> <0a6b3f53-79e5-af83-be39-f04c9acd8384@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0a6b3f53-79e5-af83-be39-f04c9acd8384@arm.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Tom Lendacky , Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Christoph Hellwig , linux-arm-kernel@lists.infradead.org X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org Message-ID: <20190423145236.z8Xd57qe38myCKh-1mX8DvEuLeCMBLB1N1KRYbGQdb0@z> On Tue, Apr 23, 2019 at 11:01:44AM +0100, Robin Murphy wrote: > On 19/04/2019 09:23, Christoph Hellwig wrote: >> On Thu, Apr 18, 2019 at 07:15:00PM +0100, Robin Murphy wrote: >>> Still, I've worked in the vm_map_pages() stuff pending in MM and given them >>> the same treatment to finish the picture. Both x86_64_defconfig and >>> i386_defconfig do indeed compile and link fine as I expected, so I really >>> would like to understand the concern around #ifdefs better. >> >> This looks generally fine to me. One thing I'd like to do is to >> generally make use of the fact that __iommu_dma_get_pages returns NULL >> for the force contigous case as that cleans up a few things. Also >> for the !DMA_REMAP case we need to try the page allocator when >> dma_alloc_from_contiguous does not return a page. What do you thing >> of the following incremental diff? If that is fine with you I can >> fold that in and add back in the remaining patches from my series >> not obsoleted by your patches and resend. > > Wouldn't this suffice? Since we also use alloc_pages() in the coherent > atomic case, the free path should already be able to deal with it. Yepp, that is about what I've done in v3, except that I've also folded that coherent atomic case in a way very similar to dma-direct. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B73F4C10F03 for ; Tue, 23 Apr 2019 14:53:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7A15221738 for ; Tue, 23 Apr 2019 14:53:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="N2n4Dih5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7A15221738 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tIMmIcMqMRvxAe4YMgPHjuhC4J+ywB3B3z5xUh1uF5w=; b=N2n4Dih5JSWP+r tjgkuEMA1mnkKvCPcGhzh7ovScrZ+VwlVfUwuKh2yxOXiTu/uWMNo73z5jHDxzkehQtkFQu8WomyA 2FoGZonL/orocPHaDmWt3FqCL2OV8ZhOd6SBgP2wEFCkwLl73RQngNhDIC2gN2+8VgqEzVUQ/R05H 384VtxNPKVeAR/Jcb0ydolnTfqIVgHa/NkMWD+KA8ehIikv42fqOetOLQZPZ7gkkd67SSWSH4fJtx KuGKg1vab4j9YGwBSdF4RlJ3HCzk4TKiBPItzt3mxUN4jTFxrT8Gdkwqr8xftqLRpHBNiiXHteqAJ eA0rvrITD4JosdUQXMUQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hIwn2-0007Yj-JZ; Tue, 23 Apr 2019 14:52:56 +0000 Received: from verein.lst.de ([213.95.11.211] helo=newverein.lst.de) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hIwmz-0007Xg-6B for linux-arm-kernel@lists.infradead.org; Tue, 23 Apr 2019 14:52:55 +0000 Received: by newverein.lst.de (Postfix, from userid 2407) id C167F68AFE; Tue, 23 Apr 2019 16:52:36 +0200 (CEST) Date: Tue, 23 Apr 2019 16:52:36 +0200 From: Christoph Hellwig To: Robin Murphy Subject: Re: [PATCH 12/21] dma-iommu: factor atomic pool allocations into helpers Message-ID: <20190423145236.GA22253@lst.de> References: <20190327080448.5500-1-hch@lst.de> <20190327080448.5500-13-hch@lst.de> <20190410061157.GA5278@lst.de> <20190417063358.GA24139@lst.de> <83615173-a8b4-e0eb-bac3-1a58d61ea4ef@arm.com> <20190418163512.GA25347@lst.de> <228ee57a-d7b2-48e0-a34e-81d5fba0a090@arm.com> <20190419082348.GA22299@lst.de> <0a6b3f53-79e5-af83-be39-f04c9acd8384@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0a6b3f53-79e5-af83-be39-f04c9acd8384@arm.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190423_075253_381329_FFA518AF X-CRM114-Status: GOOD ( 13.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tom Lendacky , Catalin Marinas , Joerg Roedel , Will Deacon , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Christoph Hellwig , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Apr 23, 2019 at 11:01:44AM +0100, Robin Murphy wrote: > On 19/04/2019 09:23, Christoph Hellwig wrote: >> On Thu, Apr 18, 2019 at 07:15:00PM +0100, Robin Murphy wrote: >>> Still, I've worked in the vm_map_pages() stuff pending in MM and given them >>> the same treatment to finish the picture. Both x86_64_defconfig and >>> i386_defconfig do indeed compile and link fine as I expected, so I really >>> would like to understand the concern around #ifdefs better. >> >> This looks generally fine to me. One thing I'd like to do is to >> generally make use of the fact that __iommu_dma_get_pages returns NULL >> for the force contigous case as that cleans up a few things. Also >> for the !DMA_REMAP case we need to try the page allocator when >> dma_alloc_from_contiguous does not return a page. What do you thing >> of the following incremental diff? If that is fine with you I can >> fold that in and add back in the remaining patches from my series >> not obsoleted by your patches and resend. > > Wouldn't this suffice? Since we also use alloc_pages() in the coherent > atomic case, the free path should already be able to deal with it. Yepp, that is about what I've done in v3, except that I've also folded that coherent atomic case in a way very similar to dma-direct. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel