Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp363257ybp; Tue, 8 Oct 2019 19:48:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqzjfb2fvIjtBBc3QPA78YdMS0jFWRoXUOegkC3XhWad+gaYD8Y6x2X2rKtdgM45gbpQfOj1 X-Received: by 2002:a50:c304:: with SMTP id a4mr953566edb.303.1570589307338; Tue, 08 Oct 2019 19:48:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570589307; cv=none; d=google.com; s=arc-20160816; b=KJczJyYu15BwpLuN996qTME5mki5z3qjXZSkY50SDzDRkMSLxphENXBzsapvQ+deCR thpu7msjbOPSmegcwZFGL6JW4PjWYxf7LiMXttkAkjx3usg3E5lA2L4PKp8Ta0kHGI6y vy/nScKZnlmuYL57y1ID8aJazZTz+IgNorxeAhZZclYA8y4fjjetkyCzuFgyalunrKYD pNiSdDAiWZyZDuB6aXg5pOyrneNe1MdylopbCST+B4Q9KR8Ei08VMIsWbaSaoNvbvgrl eHB1w4U708Xh+ty8fU/lLe4KdUPuvmPld890BZ0EKzV6+OVkte+rwxabk/22LQZ2haZ5 dJiQ== 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=JWtUqNhFLmdl3BRfM1BTs2bfWAbScCM/LWRIzlhUXww=; b=C+384gcG5CW3q6LSQRiilpYbHgRSsSWWpG1yfxIjC820W/Mj+ZYpqsg+xMh9WyJ4kq beNXhXROHVAVrSG6cohf6zugNuNabTNV037xVEAH88WAKA9S+8aTzrAn7iby6ZVWH41R Nb2PGT5CVVYLX5u9US5QCbVtEw9qoq97q684q3nExQAdTo4cPQmLpeNmkq7eQ9Q45n12 3QWVhirdHgCAg/nJLv/iGltsppVEbjoTJKBFS49u8jzMn4MaGptQNdZgPu7yjjVuGKlJ F/U9snRbtqcmCBAIC9bybor/040vTo+tf4IzKjwVbx9KanUG/EwLjZQQV0SKeU3WYSqk o11w== 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 ha3si382018ejb.372.2019.10.08.19.48.04; Tue, 08 Oct 2019 19:48:27 -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 S1729772AbfJICrb (ORCPT + 99 others); Tue, 8 Oct 2019 22:47:31 -0400 Received: from mga02.intel.com ([134.134.136.20]:32127 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726490AbfJICrb (ORCPT ); Tue, 8 Oct 2019 22:47:31 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Oct 2019 19:47:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,273,1566889200"; d="scan'208";a="192748823" Received: from allen-box.sh.intel.com (HELO [10.239.159.136]) ([10.239.159.136]) by fmsmga008.fm.intel.com with ESMTP; 08 Oct 2019 19:47:28 -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: <76d680ab-a454-4a69-597a-c0edbfc5014b@linux.intel.com> Date: Wed, 9 Oct 2019 10:45:15 +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 > --- > 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); Do you mind explaining why we always return 32 bit here? Best regards, Baolu > +} > + > 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 >