From patchwork Wed Aug 9 12:48:03 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolu Lu X-Patchwork-Id: 133233 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c44e:0:b0:3f2:4152:657d with SMTP id w14csp2792367vqr; Wed, 9 Aug 2023 06:14:57 -0700 (PDT) X-Google-Smtp-Source: AGHT+IED0Owq8QQoOlF2uGO5G3dpLCrTe5Nakw6gYjUv2c5DGk0Z6RFcHE9Wa0eY17OyR3amxetn X-Received: by 2002:a05:6a00:9a4:b0:682:2e99:9de0 with SMTP id u36-20020a056a0009a400b006822e999de0mr2678794pfg.23.1691586897098; Wed, 09 Aug 2023 06:14:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691586897; cv=none; d=google.com; s=arc-20160816; b=zUJejoc4cwQPIA82zkXeHQQjFjvWsJnHLLT3+JbkCf+bo+jBLseFEGtsma/5vDQbV3 STMgNwymNPQHCvDFSruL2Rphrk7hShr1EnEAziIPKwAy4MDPvpRuKmFM8LlzngtjB5ZO rezeYduBk5Hf3UWwALha2GLyMsnlVp18AhfjGNTAcyAVUdBYF4IchTf9sVqxOOACsqWW ylisdI13icYKoWREaReSPcnM7psDMnLkebj92I0qjUx9mwFbr5ldLZnBXMFch9zHatGg A/eIoF1i7WLB56MKbrg/LJG5WiLLjUERNY2ZV035MqIzJ+m7oHJk38QP9w42tNPj+FR0 SbHA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Nn5hZ6JjOlPrghZrr3UiEP0ATdRWRQlS5umFA+/t/pQ=; fh=o19XWoHcKD7gRUBzDd/k3VHWxrc2UY9EZqGcssdaMxU=; b=YK0tUku5HUvUoUOUfnv3mAzOILuevF2K9pRcUzq0SRnD66mY9q9Ij8XddROCWCdgjF G39mRYGUl6QJHESsb0RteYxIPhww3pWKn4CcKUQICPlfTpv3aRI+mJfJRh0MvWMjn+uW nNg9zxNPfs2xyUOvCNIroOTEqfd8kZ3anrcwEGAY9y7H0keX7GAh6NjUnJPngIyaEiUn 3WBWKrQg+9YpT/TMyXqcbL550UMUUXvuUlC16mWBuD/VlIhPvFRiZ27gePa/uCKEWmx2 A1b33qyPKKNK96bDDx+GKGF3XzDeK8eYZ2hYDnPv3m85fW4DV/arhoL+RP8RHkzIdY3G LDxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="JDNNiiM/"; 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 h4-20020a056a001a4400b006871e685bc7si9188050pfv.2.2023.08.09.06.14.44; Wed, 09 Aug 2023 06:14:57 -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="JDNNiiM/"; 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 S231220AbjHIMvG (ORCPT + 99 others); Wed, 9 Aug 2023 08:51:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232724AbjHIMvA (ORCPT ); Wed, 9 Aug 2023 08:51:00 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85B7726A6 for ; Wed, 9 Aug 2023 05:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691585443; x=1723121443; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=WIrVHdlFcP2yuyMe9xdW5lDUhBW7ZaLR8PAhwSLCIyw=; b=JDNNiiM/sYtq1Ty/+Mz1s4KLM/piOCrz++Fz9hcDKffFlj6cboojLiBt ZlNESYw97IuAJCWX/nxSr0YvGrS3tc8KVXny45x1AFLMnD1+A/IQ6PKP+ nyOyK392LQ7DKoFjq9P25Ou1pWOAIBERqGDEySRHVTjzOFVwrC4m/kxT+ i9llQsdoA2eS3BQF9H9BQSajXlTv8a+46KfIDPnu1N65af+bFG2E+D04Y LYyPEW0t4KkFCoavB51MCgfP3A5m1bMZE884WoTGUs4hlvBcL0iQBMR6W W3MtoiGxUeoKFejMjYFzAkzNRANRxMrjcj7Sc9zJva9QUTL+BQyKtjZ2S A==; X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="374821755" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="374821755" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2023 05:50:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10795"; a="855521828" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="855521828" Received: from allen-box.sh.intel.com ([10.239.159.127]) by orsmga004.jf.intel.com with ESMTP; 09 Aug 2023 05:50:41 -0700 From: Lu Baolu To: Joerg Roedel Cc: YueHaibing , Yanfei Xu , Jacob Pan , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 10/13] iommu/vt-d: Remove rmrr check in domain attaching device path Date: Wed, 9 Aug 2023 20:48:03 +0800 Message-Id: <20230809124806.45516-11-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230809124806.45516-1-baolu.lu@linux.intel.com> References: <20230809124806.45516-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773757422361846783 X-GMAIL-MSGID: 1773757422361846783 The core code now prevents devices with RMRR regions from being assigned to user space. There is no need to check for this condition in individual drivers. Remove it to avoid duplicate code. Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20230724060352.113458-3-baolu.lu@linux.intel.com --- drivers/iommu/intel/iommu.c | 58 ------------------------------------- 1 file changed, 58 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index f939fc2aa66c..1f89714ca462 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -2487,30 +2487,6 @@ static int dmar_domain_attach_device(struct dmar_domain *domain, return 0; } -static bool device_has_rmrr(struct device *dev) -{ - struct dmar_rmrr_unit *rmrr; - struct device *tmp; - int i; - - rcu_read_lock(); - for_each_rmrr_units(rmrr) { - /* - * Return TRUE if this RMRR contains the device that - * is passed in. - */ - for_each_active_dev_scope(rmrr->devices, - rmrr->devices_cnt, i, tmp) - if (tmp == dev || - is_downstream_to_pci_bridge(dev, tmp)) { - rcu_read_unlock(); - return true; - } - } - rcu_read_unlock(); - return false; -} - /** * device_rmrr_is_relaxable - Test whether the RMRR of this device * is relaxable (ie. is allowed to be not enforced under some conditions) @@ -2540,34 +2516,6 @@ static bool device_rmrr_is_relaxable(struct device *dev) return false; } -/* - * There are a couple cases where we need to restrict the functionality of - * devices associated with RMRRs. The first is when evaluating a device for - * identity mapping because problems exist when devices are moved in and out - * of domains and their respective RMRR information is lost. This means that - * a device with associated RMRRs will never be in a "passthrough" domain. - * The second is use of the device through the IOMMU API. This interface - * expects to have full control of the IOVA space for the device. We cannot - * satisfy both the requirement that RMRR access is maintained and have an - * unencumbered IOVA space. We also have no ability to quiesce the device's - * use of the RMRR space or even inform the IOMMU API user of the restriction. - * We therefore prevent devices associated with an RMRR from participating in - * the IOMMU API, which eliminates them from device assignment. - * - * In both cases, devices which have relaxable RMRRs are not concerned by this - * restriction. See device_rmrr_is_relaxable comment. - */ -static bool device_is_rmrr_locked(struct device *dev) -{ - if (!device_has_rmrr(dev)) - return false; - - if (device_rmrr_is_relaxable(dev)) - return false; - - return true; -} - /* * Return the required default domain type for a specific device. * @@ -4173,12 +4121,6 @@ static int intel_iommu_attach_device(struct iommu_domain *domain, struct device_domain_info *info = dev_iommu_priv_get(dev); int ret; - if (domain->type == IOMMU_DOMAIN_UNMANAGED && - device_is_rmrr_locked(dev)) { - dev_warn(dev, "Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor.\n"); - return -EPERM; - } - if (info->domain) device_block_translation(dev);