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: Wed, 10 Apr 2019 08:11:58 +0200 Message-ID: <20190410061157.GA5278@lst.de> References: <20190327080448.5500-1-hch@lst.de> <20190327080448.5500-13-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: 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 09, 2019 at 06:59:32PM +0100, Robin Murphy wrote: > On 27/03/2019 08:04, Christoph Hellwig wrote: >> This keeps the code together and will simplify compiling the code >> out on architectures that are always dma coherent. > > And this is where things take a turn in the direction I just can't get on > with - I'm looking at the final result and the twisty maze of little > disjoint helpers all overlapping each other in functionality is really > difficult to follow. And I would *much* rather have things rely on > compile-time constant optimisation than spend the future having to fix the > #ifdefed parts for arm64 whenever x86-centric changes fail to test them. Can you draft up a patch on top of my series to show me what you want? I can take care of finishing it up and moving the changes into the right patches in the series. > Conceptually, everything except the iommu_dma_alloc_remap() case is more or > less just dma_direct_alloc() with an IOMMU mapping on top - if we could > pass that an internal flag to say "don't fail or bounce because of masks" > it seems like that approach could end up being quite a bit simpler (I did > once have lofty plans to refactor the old arm64 code in such a way...) I've been wanting to share more code between DMA direct and the iommu allocators. But this series already is huge and has been pending far too long. I'll eventually get to it.. 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 68661C10F11 for ; Wed, 10 Apr 2019 06:12:29 +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 4181F20850 for ; Wed, 10 Apr 2019 06:12:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4181F20850 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 0F4C814EA; Wed, 10 Apr 2019 06:12:29 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C877114E7 for ; Wed, 10 Apr 2019 06:12:12 +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 843D817E for ; Wed, 10 Apr 2019 06:12:11 +0000 (UTC) Received: by newverein.lst.de (Postfix, from userid 2407) id 7047968B05; Wed, 10 Apr 2019 08:11:58 +0200 (CEST) Date: Wed, 10 Apr 2019 08:11:58 +0200 From: Christoph Hellwig To: Robin Murphy Subject: Re: [PATCH 12/21] dma-iommu: factor atomic pool allocations into helpers Message-ID: <20190410061157.GA5278@lst.de> References: <20190327080448.5500-1-hch@lst.de> <20190327080448.5500-13-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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: <20190410061158.YbAWl9MKn_xCFZPHg1jc4KaZKXCtEDPtrvSgX-HRzCA@z> On Tue, Apr 09, 2019 at 06:59:32PM +0100, Robin Murphy wrote: > On 27/03/2019 08:04, Christoph Hellwig wrote: >> This keeps the code together and will simplify compiling the code >> out on architectures that are always dma coherent. > > And this is where things take a turn in the direction I just can't get on > with - I'm looking at the final result and the twisty maze of little > disjoint helpers all overlapping each other in functionality is really > difficult to follow. And I would *much* rather have things rely on > compile-time constant optimisation than spend the future having to fix the > #ifdefed parts for arm64 whenever x86-centric changes fail to test them. Can you draft up a patch on top of my series to show me what you want? I can take care of finishing it up and moving the changes into the right patches in the series. > Conceptually, everything except the iommu_dma_alloc_remap() case is more or > less just dma_direct_alloc() with an IOMMU mapping on top - if we could > pass that an internal flag to say "don't fail or bounce because of masks" > it seems like that approach could end up being quite a bit simpler (I did > once have lofty plans to refactor the old arm64 code in such a way...) I've been wanting to share more code between DMA direct and the iommu allocators. But this series already is huge and has been pending far too long. I'll eventually get to it.. _______________________________________________ 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 10C11C10F11 for ; Wed, 10 Apr 2019 06:12:23 +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 D56A520850 for ; Wed, 10 Apr 2019 06:12:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="COI4jEyO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D56A520850 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=/vIUY6KY/Rv88u2Gdc7SprbUD4P+zpczXCYJGH5J5Sk=; b=COI4jEyOX0Utw/ po4871npW0lUHY35gnT44OIRWkDhOt/ebC20ulQIT/dODOZ//u2tGtCiLu34i6uW3/iszraQwLLZ/ A36TJFeHlVK/zRGIAAopjzT9WkQ6wOl9pbekCHfeyeMmm+XN/xkhJ0f4N1E1ZUMjoTO0i9gRc3Zgj tDBbMfUR91n8nRIS1/EEGTa8d8BSPfbkc1nz/NCTl6kp1hpYgSYK0Lx9YGfVx4kOxRhmMXYDWSMqE am3lThcLKC92J+iV11ypwJjI2f180j3zJRi40h7LeEfizTFP6CBsRHUwdeQV5P9WD9ULwWHqGtbXw /OBiqvcyOzdE31flz5Ug==; 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 1hE6T2-0007tq-Ka; Wed, 10 Apr 2019 06:12:16 +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 1hE6Sz-0007hW-EJ for linux-arm-kernel@lists.infradead.org; Wed, 10 Apr 2019 06:12:15 +0000 Received: by newverein.lst.de (Postfix, from userid 2407) id 7047968B05; Wed, 10 Apr 2019 08:11:58 +0200 (CEST) Date: Wed, 10 Apr 2019 08:11:58 +0200 From: Christoph Hellwig To: Robin Murphy Subject: Re: [PATCH 12/21] dma-iommu: factor atomic pool allocations into helpers Message-ID: <20190410061157.GA5278@lst.de> References: <20190327080448.5500-1-hch@lst.de> <20190327080448.5500-13-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20190409_231213_632001_AA3132EB X-CRM114-Status: GOOD ( 16.79 ) 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 09, 2019 at 06:59:32PM +0100, Robin Murphy wrote: > On 27/03/2019 08:04, Christoph Hellwig wrote: >> This keeps the code together and will simplify compiling the code >> out on architectures that are always dma coherent. > > And this is where things take a turn in the direction I just can't get on > with - I'm looking at the final result and the twisty maze of little > disjoint helpers all overlapping each other in functionality is really > difficult to follow. And I would *much* rather have things rely on > compile-time constant optimisation than spend the future having to fix the > #ifdefed parts for arm64 whenever x86-centric changes fail to test them. Can you draft up a patch on top of my series to show me what you want? I can take care of finishing it up and moving the changes into the right patches in the series. > Conceptually, everything except the iommu_dma_alloc_remap() case is more or > less just dma_direct_alloc() with an IOMMU mapping on top - if we could > pass that an internal flag to say "don't fail or bounce because of masks" > it seems like that approach could end up being quite a bit simpler (I did > once have lofty plans to refactor the old arm64 code in such a way...) I've been wanting to share more code between DMA direct and the iommu allocators. But this series already is huge and has been pending far too long. I'll eventually get to it.. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel