From nobody Thu Sep 24 20:03:14 2026 Received: from out30-98.freemail.mail.aliyun.com (out30-98.freemail.mail.aliyun.com [115.124.30.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C2943ACEEC; Mon, 21 Sep 2026 07:02:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.98 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789974182; cv=none; b=fz+d3U2+ds8wEjy0yNXGSMIXxx/LUzbU6Kfk+vRhEVRgQoHpMEeJ/UaJVgp306icJDRjxOgiNfJGhy8/5xdAQqZQFFP3W17rDxrar53beI7Dhv1ACUfAesXaZGYJdP/QVCraKyUfZG5cKcoassmpFH+WVgnMt1q0e6+BOdtykVU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789974182; c=relaxed/simple; bh=3U4Ovp0ynC0fulSiroEpUMxha2GMqQD2AFLocjFCzrI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=dMZ13a0j1htl+vmI9uaXp4ghgCtYvjrASvIG7m6JY62/ViW/c2Od09pTUYmSQYcGj8H6K/HmyeSog+p+3e463DH8gWoyyDnzY78sqITOdowCX/wlTTCrvLLhYqbFZK7k/N0nng6pJM0pu1X61jCgHISoXX+xE+1wHl10tk1mDYc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=qGEK/0Bv; arc=none smtp.client-ip=115.124.30.98 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="qGEK/0Bv" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1789974169; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=8ymtIVnhU6dCbTrVvPdPOmUpJ0Opv2VSNX9iXSB+xPQ=; b=qGEK/0Bvf62pKvoOr6e1AkDMNvWbV9jnt/1kse/l9Ev00GL04MR7x5mvvrc0GgfXPFRWTNEJE8d3BvI+hdGEtSCkgwfmhIC/eKOEI9g7v8I29kOuxmSmDiWVEk++EVIoIc6ejMAQKuD7IAqu11YVt0gLqZzL8L+LU62OnNVNwAQ= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=guanghuifeng@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0XBJEbq-_1789974154; Received: from VM20241011-104.tbsite.net(mailfrom:guanghuifeng@linux.alibaba.com fp:SMTPD_---0XBJEbq-_1789974154 cluster:ay36) by smtp.aliyun-inc.com; Mon, 21 Sep 2026 15:02:49 +0800 From: Guanghui Feng To: robin.murphy@arm.com, joro@8bytes.org, will@kernel.org Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, alex@shazbot.org, kvm@vger.kernel.org Subject: [PATCH] iommu: Reserve PCI host bridge MMIO windows in group reserved regions Date: Mon, 21 Sep 2026 15:02:34 +0800 Message-ID: <20260921070234.897736-1-guanghuifeng@linux.alibaba.com> X-Mailer: git-send-email 2.43.7 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The DMA IOVA layer reserves PCI host bridge MMIO windows via iova_reserve_pci_windows() to prevent IOVA allocations from overlapping with those address ranges. As commit fade1ec055dc ("iommu/dma: Avoid PCI host bridge windows") explains, a host bridge may interpret addresses falling within its MMIO windows as peer-to-peer DMA, leading to faults, data corruption, or DMA transactions being misrouted to the wrong PCIe device. However, VFIO type1 obtains reserved regions through iommu_get_group_resv_regions() and reports the available IOVA ranges to userspace via VFIO_IOMMU_GET_INFO. Previously iommu_get_group_resv_regions() only returned IOMMU driver-level reserved regions (RMRR, Unity Maps, MSI regions, etc.) and did not include PCI host bridge MMIO windows. This allowed userspace to choose IOVA addresses that overlap with bridge windows. The problem is especially dangerous when a device sits behind a PCIe switch and ACS Upstream Forwarding is not fully enabled: the switch may route DMA TLPs as peer-to-peer traffic to other downstream devices instead of forwarding them upstream to the root complex for IOMMU translation. Fix this by: - Introducing iommu_get_pci_resv_windows(), a common helper that walks a PCI host bridge's MMIO windows and creates IOMMU_RESV_RESERVED region entries for each one. - Calling iommu_resv_pci_windows() from iommu_get_group_resv_regions() so that all group-level consumers (VFIO type1, sysfs reserved_regions) automatically receive the PCI window reservations. - Refactoring iova_reserve_pci_windows() to reuse iommu_get_pci_resv_windows(), eliminating the duplicated bridge window enumeration logic. Signed-off-by: Guanghui Feng --- drivers/iommu/dma-iommu.c | 21 +++++++---- drivers/iommu/iommu-priv.h | 11 ++++++ drivers/iommu/iommu.c | 73 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 99 insertions(+), 6 deletions(-) diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c index 58c624513cd4..bccb53043462 100644 --- a/drivers/iommu/dma-iommu.c +++ b/drivers/iommu/dma-iommu.c @@ -37,6 +37,7 @@ =20 #include "dma-iommu.h" #include "iommu-pages.h" +#include "iommu-priv.h" =20 struct iommu_dma_msi_page { struct list_head list; @@ -508,18 +509,26 @@ static int iova_reserve_pci_windows(struct pci_dev *d= ev, struct iova_domain *iovad) { struct pci_host_bridge *bridge =3D pci_find_host_bridge(dev->bus); + struct iommu_resv_region *region, *next; struct resource_entry *window; unsigned long lo, hi; phys_addr_t start =3D 0, end; + LIST_HEAD(pci_windows); + int ret; =20 - resource_list_for_each_entry(window, &bridge->windows) { - if (resource_type(window->res) !=3D IORESOURCE_MEM) - continue; + ret =3D iommu_get_pci_resv_windows(dev, &pci_windows); =20 - lo =3D iova_pfn(iovad, window->res->start - window->offset); - hi =3D iova_pfn(iovad, window->res->end - window->offset); - reserve_iova(iovad, lo, hi); + list_for_each_entry_safe(region, next, &pci_windows, list) { + if (!ret) { + lo =3D iova_pfn(iovad, region->start); + hi =3D iova_pfn(iovad, region->start + region->length - 1); + reserve_iova(iovad, lo, hi); + } + list_del(®ion->list); + kfree(region); } + if (ret) + return ret; =20 /* Get reserved DMA windows from host bridge */ list_sort(NULL, &bridge->dma_ranges, iommu_dma_ranges_sort); diff --git a/drivers/iommu/iommu-priv.h b/drivers/iommu/iommu-priv.h index aaffad5854fc..bc7fab0c827e 100644 --- a/drivers/iommu/iommu-priv.h +++ b/drivers/iommu/iommu-priv.h @@ -123,4 +123,15 @@ static inline void iommu_debug_init(void) =20 #endif /* CONFIG_IOMMU_DEBUG_PAGEALLOC */ =20 +#ifdef CONFIG_PCI +struct pci_dev; +int iommu_get_pci_resv_windows(struct pci_dev *dev, struct list_head *head= ); +#else +static inline int iommu_get_pci_resv_windows(struct pci_dev *dev, + struct list_head *head) +{ + return 0; +} +#endif /* CONFIG_PCI */ + #endif /* __LINUX_IOMMU_PRIV_H */ diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index cd1bca7ede9a..de675ed27753 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -945,6 +945,72 @@ iommu_insert_device_resv_regions(struct list_head *dev= _resv_regions, return ret; } =20 +#ifdef CONFIG_PCI +/** + * iommu_get_pci_resv_windows - collect PCI host bridge MMIO windows as + * reserved regions + * @dev: PCI device whose host bridge to scan + * @head: list head to append iommu_resv_region entries to + * + * Walks the MMIO windows of @dev's PCI host bridge and creates an + * IOMMU_RESV_RESERVED region for each one. The caller must free the + * returned entries with kfree() when done. + * + * Returns 0 on success, negative errno on failure. + */ +int iommu_get_pci_resv_windows(struct pci_dev *dev, struct list_head *head) +{ + struct pci_host_bridge *bridge =3D pci_find_host_bridge(dev->bus); + struct resource_entry *window; + + resource_list_for_each_entry(window, &bridge->windows) { + struct iommu_resv_region *region; + phys_addr_t start; + size_t length; + + if (resource_type(window->res) !=3D IORESOURCE_MEM) + continue; + + start =3D window->res->start - window->offset; + length =3D window->res->end - window->res->start + 1; + + region =3D iommu_alloc_resv_region(start, length, 0, + IOMMU_RESV_RESERVED, + GFP_KERNEL); + if (!region) + return -ENOMEM; + + list_add_tail(®ion->list, head); + } + return 0; +} +EXPORT_SYMBOL_GPL(iommu_get_pci_resv_windows); + +/* + * Reserve PCI host bridge MMIO windows as IOMMU_RESV_RESERVED regions. + * This prevents IOVA allocations from overlapping with PCI MMIO address + * ranges, which could cause PCIe switches to misroute DMA transactions. + * + * All PCI devices within the same IOMMU group share the same host bridge, + * so we only need to find the first PCI device. + * + * Caller must hold group->mutex. + */ +static int iommu_resv_pci_windows(struct iommu_group *group, + struct list_head *head) +{ + struct group_device *gdev; + + for_each_group_device(group, gdev) { + if (!dev_is_pci(gdev->dev)) + continue; + return iommu_get_pci_resv_windows(to_pci_dev(gdev->dev), + head); + } + return 0; +} +#endif /* CONFIG_PCI */ + int iommu_get_group_resv_regions(struct iommu_group *group, struct list_head *head) { @@ -969,6 +1035,13 @@ int iommu_get_group_resv_regions(struct iommu_group *= group, if (ret) break; } + + /* Reserve PCI host bridge MMIO windows to prevent IOVA conflicts */ +#ifdef CONFIG_PCI + if (!ret) + ret =3D iommu_resv_pci_windows(group, head); +#endif + mutex_unlock(&group->mutex); return ret; } --=20 2.43.7