From nobody Mon Feb 9 07:19:15 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9977DC001DF for ; Thu, 13 Jul 2023 04:34:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233734AbjGMEew (ORCPT ); Thu, 13 Jul 2023 00:34:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233767AbjGMEer (ORCPT ); Thu, 13 Jul 2023 00:34:47 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC052E69; Wed, 12 Jul 2023 21:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689222886; x=1720758886; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=A/qWNNFdf7RmjwCwpIRIp2QIj/P5FBdLOofsL04ks3Q=; b=OXL7JpVvy2vPwg09rYRQH67ow4Xtx0emRWMhAhpvhKTaKi5VIUc3x9Qr QjSiAAAblxeN/ZuyxcLFdkDnJgIN1GpDIn8SEkui6ekyUTmX9W6H5KNNe o+lutEEs3C/0oSILBSWK5sfbPLVLWuhWEK4IQWBtcY2O8SfygWjelB8HH H6Ri4mFsYGF8uJZYPWwt2dV3CpLRL7ubYXHPBg5xorgUtb5moxK3Pjf83 YjJkeqt1NMYabEutYSwM+OiKP+wiVefUvEqGPmIMO2+n5FkAfHuETjbZj 7IszNE4PnbslZWDKNzxA0hoDj2LCb2nxoCSI72Xu49Z9ZLo0uq0wjOLYx w==; X-IronPort-AV: E=McAfee;i="6600,9927,10769"; a="344677984" X-IronPort-AV: E=Sophos;i="6.01,201,1684825200"; d="scan'208";a="344677984" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2023 21:34:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10769"; a="866400219" X-IronPort-AV: E=Sophos;i="6.01,201,1684825200"; d="scan'208";a="866400219" Received: from allen-box.sh.intel.com ([10.239.159.127]) by fmsmga001.fm.intel.com with ESMTP; 12 Jul 2023 21:34:43 -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 v2 1/2] iommu: Prevent RESV_DIRECT devices from blocking domains Date: Thu, 13 Jul 2023 12:32:47 +0800 Message-Id: <20230713043248.41315-2-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230713043248.41315-1-baolu.lu@linux.intel.com> References: <20230713043248.41315-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" 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/BN9PR11MB5276E84229B5BD952D78E959= 8C639@BN9PR11MB5276.namprd11.prod.outlook.com Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe --- include/linux/iommu.h | 2 ++ drivers/iommu/iommu.c | 37 +++++++++++++++++++++++++++---------- 2 files changed, 29 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; }; =20 int iommu_device_register(struct iommu_device *iommu, diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index da340f11c5f5..db9494f8cf75 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -959,14 +959,12 @@ static int iommu_create_device_direct_mappings(struct= iommu_domain *domain, unsigned long pg_size; int ret =3D 0; =20 - if (!iommu_is_dma_domain(domain)) - return 0; - - BUG_ON(!domain->pgsize_bitmap); - - pg_size =3D 1UL << __ffs(domain->pgsize_bitmap); + pg_size =3D domain->pgsize_bitmap ? 1UL << __ffs(domain->pgsize_bitmap) := 0; INIT_LIST_HEAD(&mappings); =20 + if (WARN_ON_ONCE(iommu_is_dma_domain(domain) && !pg_size)) + return -EINVAL; + iommu_get_resv_regions(dev, &mappings); =20 /* We need to consider overlapping regions for different devices */ @@ -974,13 +972,17 @@ static int iommu_create_device_direct_mappings(struct= iommu_domain *domain, dma_addr_t start, end, addr; size_t map_size =3D 0; =20 + if (entry->type =3D=3D IOMMU_RESV_DIRECT) + dev->iommu->requires_direct =3D 1; + + if ((entry->type !=3D IOMMU_RESV_DIRECT && + entry->type !=3D IOMMU_RESV_DIRECT_RELAXABLE) || + !iommu_is_dma_domain(domain)) + continue; + start =3D ALIGN(entry->start, pg_size); end =3D ALIGN(entry->start + entry->length, pg_size); =20 - if (entry->type !=3D IOMMU_RESV_DIRECT && - entry->type !=3D IOMMU_RESV_DIRECT_RELAXABLE) - continue; - for (addr =3D start; addr <=3D end; addr +=3D pg_size) { phys_addr_t phys_addr; =20 @@ -2121,6 +2123,21 @@ static int __iommu_device_set_domain(struct iommu_gr= oup *group, { int ret; =20 + /* + * 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 =3D=3D IOMMU_DOMAIN_BLOCKED || + new_domain =3D=3D group->blocking_domain)) { + dev_warn(dev, + "Firmware has requested this device have a 1:1 IOMMU mapping, rejectin= g configuring the device without a 1:1 mapping. Contact your platform vendo= r.\n"); + return -EINVAL; + } + if (dev->iommu->attach_deferred) { if (new_domain =3D=3D group->default_domain) return 0; --=20 2.34.1 From nobody Mon Feb 9 07:19:15 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7751EB64DD for ; Thu, 13 Jul 2023 04:34:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233846AbjGMEe4 (ORCPT ); Thu, 13 Jul 2023 00:34:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233753AbjGMEeu (ORCPT ); Thu, 13 Jul 2023 00:34:50 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7902712F; Wed, 12 Jul 2023 21:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689222889; x=1720758889; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=cRzfvAiOqEbmCFSTbcVQKw4zrRuJSvtgRbGD2txDVfY=; b=QZiQbnDbditJz2FlouSLe07SDGOxbJwA8LInrh+G1rerwDJ9hygQoJWk mnrrCTJIYtmFPmEvZGniJ+rsuAdt3jo7S1GMjnNUpEZmmZaJ8HEPLaeZv Z1j37JVosdc01gLIrvZwWHBBMlheddhKMjJZ/PWzl9paTHzmCqnCN2BHN kBbu7fM1vaNEcCQwHiaY269MFhaWvbMrnRtR4vUd4DXQOmJQ/FMcJpHDi uQ3Gqs6Sumwo6ec5q06xM/z5VJA0UtlewnKJ5FT7ljKtf1FciLsT4tors 1GwxdUE8hPt3HOoQBmn0np873UlZGO67mtSWwfuZlxN9SQE1w1swl/IPG g==; X-IronPort-AV: E=McAfee;i="6600,9927,10769"; a="344677994" X-IronPort-AV: E=Sophos;i="6.01,201,1684825200"; d="scan'208";a="344677994" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2023 21:34:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10769"; a="866400244" X-IronPort-AV: E=Sophos;i="6.01,201,1684825200"; d="scan'208";a="866400244" Received: from allen-box.sh.intel.com ([10.239.159.127]) by fmsmga001.fm.intel.com with ESMTP; 12 Jul 2023 21:34:46 -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 v2 2/2] iommu/vt-d: Remove rmrr check in domain attaching device path Date: Thu, 13 Jul 2023 12:32:48 +0800 Message-Id: <20230713043248.41315-3-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230713043248.41315-1-baolu.lu@linux.intel.com> References: <20230713043248.41315-1-baolu.lu@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" 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 5c8c5cdc36cf..43a28bc60ce1 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_dom= ain *domain, return 0; } =20 -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 =3D=3D 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; } =20 -/* - * There are a couple cases where we need to restrict the functionality of - * devices associated with RMRRs. The first is when evaluating a device f= or - * identity mapping because problems exist when devices are moved in and o= ut - * of domains and their respective RMRR information is lost. This means t= hat - * 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 cann= ot - * 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 restrict= ion. - * 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. * @@ -4139,12 +4087,6 @@ static int intel_iommu_attach_device(struct iommu_do= main *domain, struct device_domain_info *info =3D dev_iommu_priv_get(dev); int ret; =20 - if (domain->type =3D=3D IOMMU_DOMAIN_UNMANAGED && - device_is_rmrr_locked(dev)) { - dev_warn(dev, "Device is ineligible for IOMMU domain attach due to platf= orm RMRR requirement. Contact your platform vendor.\n"); - return -EPERM; - } - if (info->domain) device_block_translation(dev); =20 --=20 2.34.1