Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1663765ybp; Wed, 9 Oct 2019 18:30:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqzN7v9PMIPSG4Tro2FC+lLRwdqH87Ktcfja9OXWUtP3uDRwGtTE/YLTE4+XhX6N8Slc1ZX3 X-Received: by 2002:a17:906:edb7:: with SMTP id sa23mr5669499ejb.263.1570671001457; Wed, 09 Oct 2019 18:30:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570671001; cv=none; d=google.com; s=arc-20160816; b=Kf/FZlqhgqqllzJPCKbizccckjfGgMcfC2FlziTx5upoULuRc8a1M3PlDN5Lyzytav QN3LJEavflM8KbHJmmtNanIQmMI7ubb4Dn3xUxu6KWMvVgr5Qp2pA9E6NVZQFqIKivVR ypzKR4jZ4KVBucEV69k+9B9LJlHrXYq0URzMeA2pDQfbDvan4ddOivgWbs94XGFzmFpV JME+Dl0mkYL8pgGLrdgeha1/ZSVmH10eUkn2P6z7W8D07azwi36uJM01mlEERUAyCzK1 +5HmIUyxF3Yu1o5Qs41IWjjJnKM7ixCjSHsF88TqIvgR+AhODAuxztLpfFZUk07LyN2K 7itQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:cc; bh=y4PNbS8oLw/cbKgmkr9JiuKmp9w1N7nLcQ+X9BRhn84=; b=wZbUNVI3JqIJb3Tjj/uBThSpFFVyMTNKU6AGSaIPTDD5tT1mp3kpSWn3GaUP2yVE1Y x+Mp41ZeP9xld5dPIwDPqszGbCXinD5GBVPmm7W6St8EeCEnEm9q0AZ1tr/e7SIEsAUS r60KwiAckvNcUHzUNQnZ74d2FHgQ4ui+dETPRKXowrFF/THtAroScyv7x0pA8E8r9riT uK/EoTX3v/HOOspmZ7gaA25r1waBFNLIE18GD976LC/YfZJeTElmGyW6KYBiNE0WOPl4 gjIgJJVvs9NKgZjov46hQJVHc3iPv47nG9kYhJ/jJNGDp5qkJDJGOYLintgQSh5+C/Ru wm2Q== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v12si2414754edf.212.2019.10.09.18.29.38; Wed, 09 Oct 2019 18:30:01 -0700 (PDT) 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732610AbfJJB24 (ORCPT + 99 others); Wed, 9 Oct 2019 21:28:56 -0400 Received: from mga07.intel.com ([134.134.136.100]:62021 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732157AbfJJB24 (ORCPT ); Wed, 9 Oct 2019 21:28:56 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2019 18:28:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,278,1566889200"; d="scan'208";a="218862856" Received: from allen-box.sh.intel.com (HELO [10.239.159.136]) ([10.239.159.136]) by fmsmga004.fm.intel.com with ESMTP; 09 Oct 2019 18:28:52 -0700 Cc: baolu.lu@linux.intel.com, Christoph Hellwig Subject: Re: [PATCH] iommu/vt-d: Return the correct dma mask when we are bypassing the IOMMU To: Arvind Sankar , linux-kernel@vger.kernel.org References: <20191008143357.GA599223@rani.riverdale.lan> From: Lu Baolu Message-ID: <85123533-2e9c-af73-3014-782dd6f925cb@linux.intel.com> Date: Thu, 10 Oct 2019 09:26:37 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191008143357.GA599223@rani.riverdale.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 10/8/19 10:33 PM, Arvind Sankar wrote: > We must return a mask covering the full physical RAM when bypassing the > IOMMU mapping. Also, in iommu_need_mapping, we need to check using > dma_direct_get_required_mask to ensure that the device's dma_mask can > cover physical RAM before deciding to bypass IOMMU mapping. > > Fixes: 249baa547901 ("dma-mapping: provide a better default ->get_required_mask") > Reported-by: Arvind Sankar > Tested-by: Arvind Sankar > Originally-by: Christoph Hellwig > Signed-off-by: Christoph Hellwig > Fixed-by: Arvind Sankar > Signed-off-by: Arvind Sankar This patch looks good to me. Reviewed-by: Lu Baolu > --- > drivers/iommu/intel-iommu.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c > index 3f974919d3bd..79e35b3180ac 100644 > --- a/drivers/iommu/intel-iommu.c > +++ b/drivers/iommu/intel-iommu.c > @@ -3471,7 +3471,7 @@ static bool iommu_need_mapping(struct device *dev) > if (dev->coherent_dma_mask && dev->coherent_dma_mask < dma_mask) > dma_mask = dev->coherent_dma_mask; > > - if (dma_mask >= dma_get_required_mask(dev)) > + if (dma_mask >= dma_direct_get_required_mask(dev)) > return false; > > /* > @@ -3775,6 +3775,13 @@ static int intel_map_sg(struct device *dev, struct scatterlist *sglist, int nele > return nelems; > } > > +static u64 intel_get_required_mask(struct device *dev) > +{ > + if (!iommu_need_mapping(dev)) > + return dma_direct_get_required_mask(dev); > + return DMA_BIT_MASK(32); > +} > + > static const struct dma_map_ops intel_dma_ops = { > .alloc = intel_alloc_coherent, > .free = intel_free_coherent, > @@ -3787,6 +3794,7 @@ static const struct dma_map_ops intel_dma_ops = { > .dma_supported = dma_direct_supported, > .mmap = dma_common_mmap, > .get_sgtable = dma_common_get_sgtable, > + .get_required_mask = intel_get_required_mask, > }; > > static void >