Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5102448imu; Tue, 15 Jan 2019 11:13:19 -0800 (PST) X-Google-Smtp-Source: ALg8bN6qA3JRVRRC3W16ow8OY1Ekm8jjCTEQiMN4HB/w3vvLlbc1wdQsFivZxCs0ymsVAuIsFRbC X-Received: by 2002:a62:5003:: with SMTP id e3mr5722698pfb.23.1547579599508; Tue, 15 Jan 2019 11:13:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547579599; cv=none; d=google.com; s=arc-20160816; b=akkXfLyLwKftvotBffGLh9W+fr3JLosybteLhg4jvSqaybj71zjDuO28yXYFIhNnqV /x5fwmoSuIcC9NBjOsnqG1+qGLsWkrvq2/vK/O7FYC+zz8Oos58RlQf+0HJag+iXHL4B RDTav6Q65216AMo3bkFOtVZfIGtsHCXzmiCyB8kOwCLUG96R/NNs/zm+2B0E9MHxW3b6 i/hrJOSbWPQQkZ2o3bPHvDxL9qKubgfjA+YfCHst8eWh0ElLQQ9LfZYaszfDlaRHH/Tc EbuX+jO6NAl6r6pri2oGVGh96lcMKJq/F2Ks2ha1jgdB+I3ktfz+gkT8mLTYh7zhB8x/ CO0A== 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=LsZsOhUzIDsEGnYJ8AskKyX4eG2rTc0jXJG5XWPpDrQ=; b=v8oMx5WoREVm8BcWcKM0wEZWvLH3SpQxJ56ejDeIEEeUzty+EcHPT0BRd7IyjpqscG /BSNXG6pF0pZxF+cClYdjC6hc3SPqJxL3DD9u5YtGNLctZQ8joacCwyeAfyWiSeQ/xh2 LWJ7fmkKHZF/jt4HHiDcFCYKR3y8rz3+isuj7ENi6OP2Azq/9gjkbQEvgcmulayC99Lo 16ZRDGhSnW/Nc3r1Rom/slSKbZEOuWaKcLRg7nHTlvEP5MbOmYUSJCbGUG9gnnb2pWJC oLREYJVpGunRjarbwF09HPntMt1cNklnzO5oo/5EKplcNCaon3VZJHLdQmUCgem8WlYS Ztxg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id d125si4074680pfc.114.2019.01.15.11.13.00; Tue, 15 Jan 2019 11:13:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1731466AbfAOQXY (ORCPT + 99 others); Tue, 15 Jan 2019 11:23:24 -0500 Received: from 8bytes.org ([81.169.241.247]:57836 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728911AbfAOQXY (ORCPT ); Tue, 15 Jan 2019 11:23:24 -0500 Received: by theia.8bytes.org (Postfix, from userid 1000) id 18D90477; Tue, 15 Jan 2019 17:23:23 +0100 (CET) Date: Tue, 15 Jan 2019 17:23:22 +0100 From: Joerg Roedel To: Christoph Hellwig Cc: "Michael S . Tsirkin" , Jason Wang , Konrad Rzeszutek Wilk , Jens Axboe , virtualization@lists.linux-foundation.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, jfehlig@suse.com, jon.grimm@amd.com, brijesh.singh@amd.com, jroedel@suse.de Subject: Re: [PATCH 2/3] dma: Introduce dma_max_mapping_size() Message-ID: <20190115162322.GA4681@8bytes.org> References: <20190115132257.6426-1-joro@8bytes.org> <20190115132257.6426-3-joro@8bytes.org> <20190115133754.GB29225@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190115133754.GB29225@lst.de> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 15, 2019 at 02:37:54PM +0100, Christoph Hellwig wrote: > > +size_t dma_direct_max_mapping_size(struct device *dev) > > +{ > > + /* > > + * Return the minimum of the direct DMA limit and the SWIOTLB limit. > > + * Since direct DMA has no limit, it is fine to just return the SWIOTLB > > + * limit. > > + */ > > + return swiotlb_max_mapping_size(dev); > > Well, if we don't actually use the swiotlb buffers despite it being > compiled in or even allocated we don't need the limit. Right, I thought about that too, but didn't find a generic way to check for all the cases. There are various checks that could be done: 1) Check if SWIOTLB is initialized at all, if not, return SIZE_MAX as the limit. This can't be checked from dma-direct code right now, but could be easily implemented. 2) Check for swiotlb=force needs to be done. 3) Check whether the device can access all of available RAM. I have no idea how to check that in an architecture independent way. It also has to take memory hotplug into account as well as the DMA mask of the device. An easy approximation could be to omit the limit if the dma-mask covers all of the physical address bits available on the platform. It would require to pass the dma-mask as an additional parameter like it is done in dma_supported(). Any better ideas for how to implement 3)? Regards, Joerg