Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2605883ybz; Sun, 19 Apr 2020 05:27:15 -0700 (PDT) X-Google-Smtp-Source: APiQypKuVVsqAJUU1iPocW/1RE4ghpCn5QoLPvHRs20f3Ujv+xvnOk5dZFSebykG8/22uYIZYjUo X-Received: by 2002:aa7:cfc3:: with SMTP id r3mr1994252edy.342.1587299235064; Sun, 19 Apr 2020 05:27:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587299235; cv=none; d=google.com; s=arc-20160816; b=GrVZvgVI2tn1Ot+I5ovU5bhSncO4Vpwmqk0lpcSPohmJ+QdYeSOlbG71Pqaa5BiChD MRIBGHmBV4KG38WZGzT8ZmCL2AZgcJNfud6YjYlVSKwBBDgliJ+sCQunfX7Bs5CqjXe3 pUssIC+WIMVtaUKY7yNE8qKl1s2pE5bP/yWCvJ8nZ/e1W7qTKzapXpzsVBRAhjj8QjtA E0283xQ89ccop/cpcTbfDpP3xyNuwYhJfMntq/BKS/2eXLJgKOM9a9Th1jmCeBzQtQ3V wkxKRCjuMbxBZCtPmrKx2xYyakAex9+qENlhuafna/LV2RFmVuIeVcrq26qLwSpwNzO8 Eujw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=9TOufhkOJx4XgLqiUb7elFvaCwHnbgAB99kNvp/Eua8=; b=Vgkvub05LhZBamGi3NJQhZudRGxlPgjfh3nqwDKEck6bw4uKhm3X+7NY1SK1FFaQM9 N7pe2+juxOd3aQa/YBEQUQPdX0RJWkUonTVimlU7ZJ+6ifgxU5cP8e+y6FPizhzoJ7cw +5BIlDqntp6Nlk7U58XW6/RCuz2wJVkmlq6t00uAU7P08HmZNRqaGSlUvgJXTy5LEWwg wrcJSzZ7zLZ2ghyM0jmKLda7efppxugXYQxORDuCwqMbAktVlO09hmprtCsfXU1cpV2Y 6R7HnBP9siq7tUKD8vstugU5wiwO+93U9gH2tdrNhUfe9ddDi+B5wOYLd5IHOJoK0bwp 3PYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v4si1861993edx.450.2020.04.19.05.26.49; Sun, 19 Apr 2020 05:27:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725964AbgDSMZF (ORCPT + 99 others); Sun, 19 Apr 2020 08:25:05 -0400 Received: from 8bytes.org ([81.169.241.247]:36440 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725939AbgDSMZF (ORCPT ); Sun, 19 Apr 2020 08:25:05 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id EB734342; Sun, 19 Apr 2020 14:25:03 +0200 (CEST) Date: Sun, 19 Apr 2020 14:25:02 +0200 From: Joerg Roedel To: Christoph Hellwig Cc: iommu@lists.linux-foundation.org, Alexey Kardashevskiy , linuxppc-dev@lists.ozlabs.org, Lu Baolu , Greg Kroah-Hartman , Robin Murphy , linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/4] dma-mapping: add a dma_ops_bypass flag to struct device Message-ID: <20200419122502.GI21900@8bytes.org> References: <20200414122506.438134-1-hch@lst.de> <20200414122506.438134-4-hch@lst.de> <20200418124205.GD6113@8bytes.org> <20200419080058.GB12222@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200419080058.GB12222@lst.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 19, 2020 at 10:00:58AM +0200, Christoph Hellwig wrote: > The difference is that NULL ops mean imply the direct mapping is always > used, dma_ops_bypass means a direct mapping is used if no bounce buffering > using swiotlb is needed, which should also answer your first question. > The idea is to consolidate code in the core to use an opportunistic > direct mapping instead of the dynamic iommu mapping. I though the cover > letter and commit log explained this well enough, but maybe I need to > do a better job. Ah right, now I see it, when dma_ops_bypass is set it will only use direct mapping when the available memory fits into the device's dma_masks, and calls into dma_ops otherwise. I wonder how that will interact with an IOMMU driver, which has to make sure that the direct mapping is accessible for the device at all. It can either put the device into a passthrough domain for direct mapping or into a re-mapped domain, but then all DMA-API calls need to use dma-ops. When the dma_mask covers available memory but coherent_mask doesn't, the streaming calls will use dma-direct and alloc_coherent() calls into dma-ops. There is no way for the IOMMU driver to ensure both works. So what are the conditions under which an IOMMU driver would set dma_ops_bypass to 1 and get a different result as to when setting dev->dma_ops to NULL? Regards, Joerg