Message ID | 20230318024824.124542-1-baolu.lu@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp103062wrt; Fri, 17 Mar 2023 20:07:53 -0700 (PDT) X-Google-Smtp-Source: AK7set+hMPDbx6T/oMH5AyfB9KsujxbWmHy4PC6luCySFEnaWirFN9jvgxWy2RLkAANOv//x7q5O X-Received: by 2002:a17:902:ef8d:b0:19d:1e21:7f59 with SMTP id iz13-20020a170902ef8d00b0019d1e217f59mr12176847plb.0.1679108873423; Fri, 17 Mar 2023 20:07:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679108873; cv=none; d=google.com; s=arc-20160816; b=1H035WfRWQ5CJvQJMVVhXf6dalFjylg3DreO8CRIVhNWZPPo7pJOLCdsj+/09ossgE eoGM/CxsoKSrTD/oW79TwL1QTdW1x5RHvPNQjW6AI5tX4Rom8HU4HH5lKNK8k/NXNN0w cCtpTt2ph4QFAakISPwRi+MpiMcF0Z8aBB9+d1m2RBL1Fii8+ETxf6a4iR4NTgxghU4v T5Vk7VfwX3PowWcS7PGjwGe/UhNq6LAQZKegPWEQlRZkfaoxRdrpnMturpeJta/3q/Rk mKN3eD8pouS7+orM9E4LjLdk12Gx1CUuzRBuRiMQbSIWGetR1DiildeWwixguycRrpqE MHsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=qhNr2Z3Bl83isxOZrjWRt7YgzgsK48Y7pk9ES7bWYXc=; b=mC9LA8azDZpo/7I89LnuGysjwu3CvlEMiZ0cAsU9uYeKm31de3bGSvYYY/DKggCWoV Ofh8PSolx8Kchk1j6fsML9bDZtmNP4TT9T4u39x6lQwV1fjzDxCcl7UmdBgHn2/iNkmx azra0B9liPAj+Vp2oZb6hG2VM/YMWk6uYzm/NxzxHD7phI5WLIFWLmfr3jQnwjWfiR9o 7bIFs6pQ4c2toci5UuqaWoc91YyE/WLbBBWb+OrpjyO0zE9h/qyQekTL9G2vZFLemBe8 qtdJ/s9V2sPYAbnUIgWLwtb9YbFQmh5stwYr9BFuyxlpH6vG18ZzHCK25w+Z50TuV5JW sN0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=NKQDt9Gl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m7-20020a170902db0700b001a11cf69a5csi4167825plx.612.2023.03.17.20.07.37; Fri, 17 Mar 2023 20:07:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=NKQDt9Gl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230030AbjCRCtm (ORCPT <rfc822;chrisfriedt@gmail.com> + 99 others); Fri, 17 Mar 2023 22:49:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229488AbjCRCtk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 17 Mar 2023 22:49:40 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3278FC1BC6 for <linux-kernel@vger.kernel.org>; Fri, 17 Mar 2023 19:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679107779; x=1710643779; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=bor+dPTiKtTketea02WkL7osfgsHnY/28a55n4Zq0YM=; b=NKQDt9GlyWTZScJnFZp7A+T/YMurgSv4Q6jv5eY3qcvTJ3kyOWx0cZeV 8Z3o+gNnMU6T2XlxLB7SHVW4ndM2fZMSLFAfDTnOtS2jb1ithS69vKJsD 98SGEPWS6lWfwjc06ZYjpnIjBCyviZRF6E8JHO3u4VEJNnGl1OjXd8PWq LuwDPMAT1KxbZSl+/sWv1QZ7Wb/6unxgbllimp58m5FFSU9UymuTRiPK3 eOeJyhyBllcubJm2+n3Y9l+oInGYJpXVF/pYVavgAj3ZOpp0a+Cj/Hog5 hApVvCfhKdSxd1t3Pw8OFb8ulUD4G5tG2PkIAxxipklQIl5UC5l9M40xg g==; X-IronPort-AV: E=McAfee;i="6600,9927,10652"; a="340756734" X-IronPort-AV: E=Sophos;i="5.98,270,1673942400"; d="scan'208";a="340756734" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2023 19:49:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10652"; a="673777714" X-IronPort-AV: E=Sophos;i="5.98,270,1673942400"; d="scan'208";a="673777714" Received: from allen-box.sh.intel.com ([10.239.159.48]) by orsmga007.jf.intel.com with ESMTP; 17 Mar 2023 19:49:36 -0700 From: Lu Baolu <baolu.lu@linux.intel.com> To: iommu@lists.linux.dev Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>, Robin Murphy <robin.murphy@arm.com>, Kevin Tian <kevin.tian@intel.com>, Raghunathan Srinivasan <raghunathan.srinivasan@intel.com>, Jacob Pan <jacob.jun.pan@linux.intel.com>, linux-kernel@vger.kernel.org, Lu Baolu <baolu.lu@linux.intel.com> Subject: [PATCH 1/1] iommu/vt-d: Allow zero SAGAW if second-stage not supported Date: Sat, 18 Mar 2023 10:48:24 +0800 Message-Id: <20230318024824.124542-1-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760673266278300978?= X-GMAIL-MSGID: =?utf-8?q?1760673266278300978?= |
Series |
[1/1] iommu/vt-d: Allow zero SAGAW if second-stage not supported
|
|
Commit Message
Baolu Lu
March 18, 2023, 2:48 a.m. UTC
The VT-d spec states (section 11.4.2) that hardware implementations reporting second-stage translation support (SSTS) field as Clear also report the SAGAW field as 0. Reflect this in the sanity check of alloc_iommu(). Fixes: 792fb43ce2c9 ("iommu/vt-d: Enable Intel IOMMU scalable mode by default") Suggested-by: Raghunathan Srinivasan <raghunathan.srinivasan@intel.com> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> --- drivers/iommu/intel/dmar.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Comments
> From: Lu Baolu <baolu.lu@linux.intel.com> > Sent: Saturday, March 18, 2023 10:48 AM > > The VT-d spec states (section 11.4.2) that hardware implementations > reporting second-stage translation support (SSTS) field as Clear also > report the SAGAW field as 0. Reflect this in the sanity check of > alloc_iommu(). > > Fixes: 792fb43ce2c9 ("iommu/vt-d: Enable Intel IOMMU scalable mode by > default") > Suggested-by: Raghunathan Srinivasan <raghunathan.srinivasan@intel.com> > Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > --- > drivers/iommu/intel/dmar.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c > index 6acfe879589c..23828d189c2a 100644 > --- a/drivers/iommu/intel/dmar.c > +++ b/drivers/iommu/intel/dmar.c > @@ -1071,7 +1071,8 @@ static int alloc_iommu(struct dmar_drhd_unit > *drhd) > } > > err = -EINVAL; > - if (cap_sagaw(iommu->cap) == 0) { > + if (!cap_sagaw(iommu->cap) && > + (!ecap_smts(iommu->ecap) || ecap_slts(iommu->ecap))) { > pr_info("%s: No supported address widths. Not attempting > DMA translation.\n", > iommu->name); > drhd->ignored = 1; Reviewed-by: Kevin Tian <kevin.tian@intel.com> btw I wonder whether it's cleaner to record separate agaw values for stage1/stage2 instead of picking a minimal set from both in __iommu_calculate_sagaw().
On 2023/3/24 12:49, Tian, Kevin wrote: >> From: Lu Baolu <baolu.lu@linux.intel.com> >> Sent: Saturday, March 18, 2023 10:48 AM >> >> The VT-d spec states (section 11.4.2) that hardware implementations >> reporting second-stage translation support (SSTS) field as Clear also >> report the SAGAW field as 0. Reflect this in the sanity check of >> alloc_iommu(). >> >> Fixes: 792fb43ce2c9 ("iommu/vt-d: Enable Intel IOMMU scalable mode by >> default") >> Suggested-by: Raghunathan Srinivasan <raghunathan.srinivasan@intel.com> >> Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> >> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> >> --- >> drivers/iommu/intel/dmar.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c >> index 6acfe879589c..23828d189c2a 100644 >> --- a/drivers/iommu/intel/dmar.c >> +++ b/drivers/iommu/intel/dmar.c >> @@ -1071,7 +1071,8 @@ static int alloc_iommu(struct dmar_drhd_unit >> *drhd) >> } >> >> err = -EINVAL; >> - if (cap_sagaw(iommu->cap) == 0) { >> + if (!cap_sagaw(iommu->cap) && >> + (!ecap_smts(iommu->ecap) || ecap_slts(iommu->ecap))) { >> pr_info("%s: No supported address widths. Not attempting >> DMA translation.\n", >> iommu->name); >> drhd->ignored = 1; > > Reviewed-by: Kevin Tian <kevin.tian@intel.com> > > btw I wonder whether it's cleaner to record separate agaw values for > stage1/stage2 instead of picking a minimal set from both in > __iommu_calculate_sagaw(). That's better. The agaw could be picked according to which stage the domain is used for translation. Best regards, baolu
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index 6acfe879589c..23828d189c2a 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -1071,7 +1071,8 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd) } err = -EINVAL; - if (cap_sagaw(iommu->cap) == 0) { + if (!cap_sagaw(iommu->cap) && + (!ecap_smts(iommu->ecap) || ecap_slts(iommu->ecap))) { pr_info("%s: No supported address widths. Not attempting DMA translation.\n", iommu->name); drhd->ignored = 1;