Received: by 2002:a05:6358:701b:b0:131:369:b2a3 with SMTP id 27csp2720331rwo; Sun, 23 Jul 2023 23:23:35 -0700 (PDT) X-Google-Smtp-Source: APBJJlECkkUkY1Zl/yk7Ie0EiviAVMZKHSroomosACwwhd0YvahNyPtMGrZwLHp5kfZ4CjWGkwyx X-Received: by 2002:ac2:47f1:0:b0:4fb:763c:af54 with SMTP id b17-20020ac247f1000000b004fb763caf54mr3956326lfp.62.1690179814896; Sun, 23 Jul 2023 23:23:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690179814; cv=none; d=google.com; s=arc-20160816; b=UeKSbeqF5Fmizv2NBhaLPEBaE6ZxUK9CgXrmWGCb6E0h+CrDaWCCvkEYi+SNHiIBPK dLtqWAZgbwBSQesWEjBsFjQrKoswk9yGPc05WvTcjfyzw5K/wJiVAjChUenoEepQCn7P +eFTTFP9C7Z/3pXIaGgsUv54Kjp7XfnoXU/sNgfG8oHOuYe6nmwrxq1zPmYHpG7TYBAw H+d94I4QYNR742cSLCdEk4m0L+IVYz4mYkg3axp9JGRDaNc+8VzyQmwgSJhDpoZakzzO RdTVGCWu0AbSFj/HEjXbcj9+qoJy0W5pwigKnebk9T7StW5LA24rTACwaOsEFHjoITAw M9WA== 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=ehI0rUcMtTENAptOUklB2vq1oWOTG2GoEUL6A0aGb48=; fh=ZcdpLkRRkgn5/BJ8ChvQjxiWxpQTELXYQQfklWPXSRs=; b=LQMvuyXH93igdKb/LsmzGAFnBlGrWAOe8UhIndgegPp0dpj1SO5jYHHyb5+xPYqGPG V3SiHXtFqVA5G2tD34HXnCOMuTmy0cDpbBdGWXDLg1zF5PFaqXtMqejbnDaaP35CsyZY UF3xwaNz00kODFlC2R92dzug4tEevAOTRF3W2xsCi9LnLuI7rnxoJ7viiyzgl144OBWk hQm6nwG9Lj3T4zQbAbAWBnLtvgKPBr8GndOxBBN9c9NtybfQHR0FA2+nCj7d+3sytMZ3 HQqesCf0kz7eSjrfm8JmoujK+oWEW2I5AI2qzdJ8mgaAuK4CxzXk2gvGHvZ4lc4IpsTL uTNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=A5rcAAHb; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bc6-20020a056402204600b0051e0d936760si6077858edb.14.2023.07.23.23.23.11; Sun, 23 Jul 2023 23:23:34 -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=A5rcAAHb; 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 S230237AbjGXGGH (ORCPT + 99 others); Mon, 24 Jul 2023 02:06:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230212AbjGXGGD (ORCPT ); Mon, 24 Jul 2023 02:06:03 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EBCA71BC; Sun, 23 Jul 2023 23:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690178760; x=1721714760; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HLjU3QgSA6TPGmviy//Ll0K/qMQxNQQQeUIIIynZXqY=; b=A5rcAAHbMTRHAThYmgmotRJFrICJY+5M8cx6j2OMQE4HrHOcXjNFKJUi MFMQ5SLlMm4H0GKN+Uq+8u5FXXGTDr2ygruAXHnmZsTrqNUBlpQJ2Gjno H0J5oJu5ScRZ3aOCxDLxEVZAFYcna6D1xBAIgirrwpj6MDjOtYio6yDhd 3m1U3fikzqfaT5bYbeaQWou7CivqRhvknZAMe8W/Yassn0VWw+Eiiq1N1 OnKUDHMoa/GZUd7WTmD/Kqdwh8RCsfmrjtXAX+Ft0bRgutbHmpN6lgbHJ oywS6VNgCsLv3JEKybfzPu2EwOKeqI7+4debHyQj++79rZyCwMO5vTYe9 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10780"; a="346955274" X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="scan'208";a="346955274" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2023 23:06:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10780"; a="972134581" X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="scan'208";a="972134581" Received: from allen-box.sh.intel.com ([10.239.159.127]) by fmsmga006.fm.intel.com with ESMTP; 23 Jul 2023 23:05:57 -0700 From: Lu Baolu To: Jason Gunthorpe , Kevin Tian , Joerg Roedel , Will Deacon , Robin Murphy , Alex Williamson , Nicolin Chen Cc: iommu@lists.linux.dev, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Lu Baolu , Jason Gunthorpe Subject: [PATCH v3 2/2] iommu/vt-d: Remove rmrr check in domain attaching device path Date: Mon, 24 Jul 2023 14:03:52 +0800 Message-Id: <20230724060352.113458-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230724060352.113458-1-baolu.lu@linux.intel.com> References: <20230724060352.113458-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE 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 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 --- 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 d5ca2387e65c..de529d522b03 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -2446,30 +2446,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) @@ -2499,34 +2475,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. * @@ -4132,12 +4080,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); -- 2.34.1