From patchwork Wed Jun 7 03:51:44 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolu Lu X-Patchwork-Id: 104226 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6358:3046:b0:115:7a1d:dabb with SMTP id p6csp96622rwl; Tue, 6 Jun 2023 21:24:01 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7hmz2LaLfULeryX/Sf1EPOIizyJcs6rRCSnT2h+dP6QDMpqXKGJawkkcwoBFmCJZ10rsOT X-Received: by 2002:a17:902:c14a:b0:1af:ea40:34e6 with SMTP id 10-20020a170902c14a00b001afea4034e6mr1774170plj.60.1686111840958; Tue, 06 Jun 2023 21:24:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686111840; cv=none; d=google.com; s=arc-20160816; b=xNbk9SGKMmR8KrMWZCbtT3fOx8V9Bg1Y7YYC+IHfiQBbNqIUXXNKoEWmrQ+bipb1GH OjfTIuM8aTSRFGuQG2esw8d9ZnJOZ7QpIEuog0HzGRg/HcA4yE2+/6SdJcgi3Tzm+IGW 9AZx8IRZdewSLoeYBQUD+vcrk6nkuhRskJv+9rINy6DaokNqd0uCQLoHXn7OQa4wmndZ ZXToDPYye8F1N12zDT8VPabYWWb5xSdNck9iy9h4B/q2/U2HPgpsi6ZrA8b856zXSqeD JEg4189xswB+rLmAy3MxopkIMgpek5EarjQwzaODgclFNlkLKgvvLnDzt58nedj+tPwy WFzA== 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=D899FFOOtufTo9pqlgTtSuMbcUCoqlyWD5ls4jHBMOw=; b=dN1RYdVo58QHLCoSD9I1cfcM0KZOian3tNWDhszg3f1M5I3LiNH6LN/n8RaXVzpPFA G2vcxtE735WuTWhklachwQcHo37ZQKv/3CqG0ryQ/DcznsHyUiHG1YYRy145bsHSWArl PMh/ezb5m+0c+bJw5yNtoJ3Hi83lJYSooWopF165MYsh+9wV5yxXNSeHv3UtVqC02O++ TU51ds4/wq7Baj1suRWnEIuAork7jqpTl3ifpfEOjJmr/ldVVsGlbaEpDcHyLaU9XHP3 mhuJLe6P7i6xyahhqLqEv3qZOSIw+NGg3TmxWe9/tH2O0GXm3i7snsCivg569qMHjTA3 sqRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=iXVLB7UA; 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 q2-20020a170902edc200b001ab1fb8cc83si7903823plk.161.2023.06.06.21.23.48; Tue, 06 Jun 2023 21:24:00 -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=iXVLB7UA; 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 S240904AbjFGDyt (ORCPT + 99 others); Tue, 6 Jun 2023 23:54:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34950 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240891AbjFGDxt (ORCPT ); Tue, 6 Jun 2023 23:53:49 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 874711BC6; Tue, 6 Jun 2023 20:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686110008; x=1717646008; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=6WUAvVJQ7l32wEzpvJFBaKCQ/VSQzTnT+W3JYlZ1JaI=; b=iXVLB7UAGvqFDEx9Y0Y3zMrfxGgav3xoz3yaykrc0hc/sdzesmEImGAM 5iyWDwCe6qXqbPRGjbfXVZIrwR5vxozmDDGbWcloU+/Omp4JkjcTwVx7Y y4gXtckHygG69L+ck0BNja2rS+00kCNvYuyvO8IGXWQH5FE7GHicU1JmM pUutzVpMkLG4Jj1BHIQbpnvQ37Dzf8XfrM9OpRzrXUX5o0JjX0VDTypFY 7hGOq5uhGz5ui0BZ9QmVSeEYMVdMTUvTwdjT4UYYxW41hUknyT2jB+XMg /sUilHT8EJb4JpLlPj2C8WuX4wc/NFvtdoWuAyyCzZt9X1DLuW9K8IObB A==; X-IronPort-AV: E=McAfee;i="6600,9927,10733"; a="385186343" X-IronPort-AV: E=Sophos;i="6.00,222,1681196400"; d="scan'208";a="385186343" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jun 2023 20:53:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10733"; a="799125354" X-IronPort-AV: E=Sophos;i="6.00,222,1681196400"; d="scan'208";a="799125354" Received: from allen-box.sh.intel.com ([10.239.159.127]) by FMSMGA003.fm.intel.com with ESMTP; 06 Jun 2023 20:53:25 -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 1/2] iommu: Prevent RESV_DIRECT devices from blocking domains Date: Wed, 7 Jun 2023 11:51:44 +0800 Message-Id: <20230607035145.343698-2-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230607035145.343698-1-baolu.lu@linux.intel.com> References: <20230607035145.343698-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 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, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE,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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768016409796253410?= X-GMAIL-MSGID: =?utf-8?q?1768016409796253410?= The IOMMU_RESV_DIRECT flag indicates that a memory region must be mapped 1:1 at all times. This means that the region must always be accessible to the device, even if the device is attached to a blocking domain. This is equal to saying that IOMMU_RESV_DIRECT flag prevents devices from being attached to blocking domains. This also implies that devices that implement RESV_DIRECT regions will be prevented from being assigned to user space since taking the DMA ownership immediately switches to a blocking domain. The rule of preventing devices with the IOMMU_RESV_DIRECT regions from being assigned to user space has existed in the Intel IOMMU driver for a long time. Now, this rule is being lifted up to a general core rule, as other architectures like AMD and ARM also have RMRR-like reserved regions. This has been discussed in the community mailing list and refer to below link for more details. Other places using unmanaged domains for kernel DMA must follow the iommu_get_resv_regions() and setup IOMMU_RESV_DIRECT - we do not restrict them in the core code. Cc: Robin Murphy Cc: Alex Williamson Cc: Kevin Tian Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/linux-iommu/BN9PR11MB5276E84229B5BD952D78E9598C639@BN9PR11MB5276.namprd11.prod.outlook.com Signed-off-by: Lu Baolu --- include/linux/iommu.h | 2 ++ drivers/iommu/iommu.c | 39 +++++++++++++++++++++++++++++---------- 2 files changed, 31 insertions(+), 10 deletions(-) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index d31642596675..fd18019ac951 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -409,6 +409,7 @@ struct iommu_fault_param { * @priv: IOMMU Driver private data * @max_pasids: number of PASIDs this device can consume * @attach_deferred: the dma domain attachment is deferred + * @requires_direct: The driver requested IOMMU_RESV_DIRECT * * TODO: migrate other per device data pointers under iommu_dev_data, e.g. * struct iommu_group *iommu_group; @@ -422,6 +423,7 @@ struct dev_iommu { void *priv; u32 max_pasids; u32 attach_deferred:1; + u32 requires_direct:1; }; int iommu_device_register(struct iommu_device *iommu, diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 9e0228ef612b..e59de7852067 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -959,12 +959,7 @@ static int iommu_create_device_direct_mappings(struct iommu_domain *domain, unsigned long pg_size; int ret = 0; - if (!iommu_is_dma_domain(domain)) - return 0; - - BUG_ON(!domain->pgsize_bitmap); - - pg_size = 1UL << __ffs(domain->pgsize_bitmap); + pg_size = domain->pgsize_bitmap ? 1UL << __ffs(domain->pgsize_bitmap) : 0; INIT_LIST_HEAD(&mappings); iommu_get_resv_regions(dev, &mappings); @@ -974,13 +969,22 @@ static int iommu_create_device_direct_mappings(struct iommu_domain *domain, dma_addr_t start, end, addr; size_t map_size = 0; + if (entry->type == IOMMU_RESV_DIRECT) + dev->iommu->requires_direct = 1; + + if ((entry->type != IOMMU_RESV_DIRECT && + entry->type != IOMMU_RESV_DIRECT_RELAXABLE) || + !iommu_is_dma_domain(domain)) + continue; + + if (WARN_ON_ONCE(!pg_size)) { + ret = -EINVAL; + goto out; + } + start = ALIGN(entry->start, pg_size); end = ALIGN(entry->start + entry->length, pg_size); - if (entry->type != IOMMU_RESV_DIRECT && - entry->type != IOMMU_RESV_DIRECT_RELAXABLE) - continue; - for (addr = start; addr <= end; addr += pg_size) { phys_addr_t phys_addr; @@ -2121,6 +2125,21 @@ static int __iommu_device_set_domain(struct iommu_group *group, { int ret; + /* + * If the driver has requested IOMMU_RESV_DIRECT then we cannot allow + * the blocking domain to be attached as it does not contain the + * required 1:1 mapping. This test effectively exclusive the device from + * being used with iommu_group_claim_dma_owner() which will block vfio + * and iommufd as well. + */ + if (dev->iommu->requires_direct && + (new_domain->type == IOMMU_DOMAIN_BLOCKED || + new_domain == group->blocking_domain)) { + dev_warn(dev, + "Firmware has requested this device have a 1:1 IOMMU mapping, rejecting configuring the device without a 1:1 mapping. Contact your platform vendor.\n"); + return -EINVAL; + } + if (dev->iommu->attach_deferred) { if (new_domain == group->default_domain) return 0; From patchwork Wed Jun 7 03:51:45 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolu Lu X-Patchwork-Id: 104229 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6358:3046:b0:115:7a1d:dabb with SMTP id p6csp106768rwl; Tue, 6 Jun 2023 21:54:55 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5vyzqGKasdkqIAO0Aqs0v3N8NWXxcgR5VaUq7cjH1Em+//1YjXLL2ppL7szW0FwqQZaBqC X-Received: by 2002:a05:6358:c50f:b0:128:205a:ce6 with SMTP id fb15-20020a056358c50f00b00128205a0ce6mr2000116rwb.26.1686113695657; Tue, 06 Jun 2023 21:54:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686113695; cv=none; d=google.com; s=arc-20160816; b=nMr0ocHaTG5xehocoDtfrki+d7uhUOyO5D+hBnngVRBaWJP642KOVNuAsNR85M2VKD BVzdUM7hvvlvjZyw9hwEJceMlqV2IQS0aq9V97w7ZvzRGxQyLim8s22yMnwXZowmDoFN Ac2Ekl1PXc6C/4sEGQTQm+Zr2B4kyaRWBU5G1k9R8QCQyZp0ao6tCDOSXnL3o53JtfHJ wiIsHDYfGtFO01nnoRkMhnX7aNT9hHXxTHtarBSPf7/zY7P5kKEbIPLF7EeGEYYOuWY6 /AeXQt0sWb0dSfvB0n3ktHYNez98NEMBhetfsg7gOJq3zAn9WQhi7MqHlEOk5i3AYJp+ Dh3w== 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=cm14/neMJk5gOkJ8tk7edyUhAvCFLw7GV+7oO1FO2vI=; b=C+flJMZArnOq6nrlV5SpZCXo60vLJ0VP15sb4xRSlVGgnSq1dsL1i2qBFQJzMn2fsG C3AirP86ZpWIVJIC0673rksZm/l5olWLWh+bal0y0tBABoZFU1heDqzhgXirz1Z66AES OYI/Xn8wVUzJ9S+/DvG3X8u0JTWVHvfX0X1fLrLxaxsmdWvk1vdPlT+eZFfSBdzFmZPc 6JltCvHoVt01uNNemDM3jyrHvY5ZuUNkU8HllIF9QnPUrruVEd+TujJCJXUJ4fxZ1Vik UsQv+4XlD+Ktms9qCg5eQSc9EAnt4g97TDqHfrQs8sbgFSAIzSmOEWfd8gRF+qcB8gd5 ZC2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jxfucnoR; 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 k7-20020a635607000000b0053eedcd4d81si8238545pgb.101.2023.06.06.21.54.41; Tue, 06 Jun 2023 21:54:55 -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=jxfucnoR; 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 S240886AbjFGDza (ORCPT + 99 others); Tue, 6 Jun 2023 23:55:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240873AbjFGDxu (ORCPT ); Tue, 6 Jun 2023 23:53:50 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A199619BA; Tue, 6 Jun 2023 20:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686110011; x=1717646011; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=2oi385LpKq1ZlutXYkuJeGeLsStTSAV0zDtArWRKxVY=; b=jxfucnoRA/igVBPR7jw/5756qnPELVsXdqeTb0uL0dTlGWAtXcOz3iZA OhtioQQHPMaHRWGGIgPIqBNTUYuVKS/Mi3SG23JTcl+WRj20oAohQ4cWt x6DlFwlU8X3xXiHx599Q0IQ2fGGgnYOo74uLI5dJqHyuPHO49J4TCMMZm wBPadY0MkKeN5fpCNeP+JBk2SaTnc61uqjnhxTkAzdP9Ekq0oKiBgiA3L 9EvdyIqS6B50imPp/UBdky30yQ11SeZ3Y+aaJ7ef3GgxTUgFLlIZ1NsFE mCwE4Vm0OUHR6W9pKOmz6EoCCsg7rK65qpM/ernAJ8FUTMyB4c49oY8+3 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10733"; a="385186356" X-IronPort-AV: E=Sophos;i="6.00,222,1681196400"; d="scan'208";a="385186356" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jun 2023 20:53:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10733"; a="799125371" X-IronPort-AV: E=Sophos;i="6.00,222,1681196400"; d="scan'208";a="799125371" Received: from allen-box.sh.intel.com ([10.239.159.127]) by FMSMGA003.fm.intel.com with ESMTP; 06 Jun 2023 20:53:28 -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 Subject: [PATCH 2/2] iommu/vt-d: Remove rmrr check in domain attaching device path Date: Wed, 7 Jun 2023 11:51:45 +0800 Message-Id: <20230607035145.343698-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230607035145.343698-1-baolu.lu@linux.intel.com> References: <20230607035145.343698-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 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, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE,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: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768018354265006847?= X-GMAIL-MSGID: =?utf-8?q?1768018354265006847?= 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 --- 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 8096273b034c..4efc87e74455 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -2458,30 +2458,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) @@ -2511,34 +2487,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. * @@ -4146,12 +4094,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);