From: Guanghui Feng <guanghuifeng@linux.alibaba.com>
To: jgg@ziepe.ca
Cc: alex@shazbot.org, iommu@lists.linux.dev, joro@8bytes.org,
kevin.tian@intel.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, robin.murphy@arm.com,
will@kernel.org
Subject: [PATCH v5 0/3] iommufd: Recommended reservations query and opt-in IOAS reservation
Date: Wed, 28 Oct 2026 15:19:03 +0800 [thread overview]
Message-ID: <20261028071906.2325378-1-guanghuifeng@linux.alibaba.com> (raw)
In-Reply-To: <20261027183418.GJ1685504@ziepe.ca>
This series lets userspace learn which IOVA ranges the kernel
recommends avoiding for a device, and optionally feed them back so
the IOAS allocator enforces them.
The motivating case is a PCI device behind a PCIe switch: DMA using
IOVAs that fall inside the host bridge MMIO windows may be misrouted
as peer-to-peer traffic instead of reaching the root complex for IOMMU
translation. The DMA IOVA layer already avoids these windows
internally, but passthrough userspace had no way to learn about them.
Per commit cd2c9fcf5c66 ("iommu/dma: Move PCI window region reservation back into dma specific path.")
this information must not be forced through the IOMMU reserved-region
API, so the series is fully opt-in:
Patch 1 adds iommu_for_each_pci_mmio_window(), a callback-based
iterator in the IOMMU core, and refactors dma-iommu.c to share it.
Patch 2 adds IOMMU_GET_RECOMMENDED_RESERVATIONS, a per-device query
returning recommended ranges (currently PCI host bridge MMIO
windows) as struct iommu_iova_range entries. Advisory only.
Patch 3 adds IOMMU_IOAS_RESERVE_IOVAS, letting userspace send
chosen ranges back in to restrict the IOAS allocator: reserved
ranges disappear from IOMMU_IOAS_IOVA_RANGES and are rejected by
mapping. Overlapping reservations are permitted, so the same
ranges recommended for several devices behind one host bridge can
each be reserved independently.
Typical flow: bind device -> query recommendations -> reserve chosen
ranges -> map. Userspace that ignores the new ioctls sees no
behaviour change.
[1] https://lore.kernel.org/all/20260921115513.GK11599@ziepe.ca/
[2] https://lore.kernel.org/all/20261027182947.GI1685504@ziepe.ca/
[3] https://lore.kernel.org/all/20261027183418.GJ1685504@ziepe.ca/
v4: https://lore.kernel.org/all/20261025133000.205508-1-guanghuifeng@linux.alibaba.com/
v3: https://lore.kernel.org/all/20261004162213.3787623-1-guanghuifeng@linux.alibaba.com/
v2: https://lore.kernel.org/all/20260921103922.1113752-1-guanghuifeng@linux.alibaba.com/
v1: https://lore.kernel.org/all/20260921070234.897736-1-guanghuifeng@linux.alibaba.com/
Changes since v4 (all per Jason's review [2][3]):
- Patch 1: drop the single-pointer wrapper struct in dma-iommu.c and
pass the iova_domain directly as callback data.
- Patch 1: drop the typedef kdoc and trim the iterator kdoc to the
essential description.
- Patch 1: WARN_ON(!bridge) instead of a silent check; inline the
start/end temporaries.
- Patch 2: reuse struct iommu_iova_range instead of adding a new
per-window struct.
- Patch 2: rename away from PCI-specific naming: the interface is now
IOMMU_GET_RECOMMENDED_RESERVATIONS reporting recommended reserved
regions, with PCI host bridge MMIO windows as the first source.
- Patch 3 (new): add IOMMU_IOAS_RESERVE_IOVAS so userspace can send
the ranges back in to create a restriction for the allocator, as
requested in [3]. The NULL-owner cleanup in iopt_destroy_table()
is no longer conditional on CONFIG_IOMMUFD_TEST since production
userspace can now create such reservations.
Changes since v3:
- Helper redesigned as a callback iterator shared with dma-iommu.c
(v4 changes).
Changes since v2:
- Redesign from forced reservation to opt-in query (v3 changes).
Guanghui Feng (3):
iommu: Add iommu_for_each_pci_mmio_window() iterator
iommufd: Add IOMMU_GET_RECOMMENDED_RESERVATIONS ioctl
iommufd: Add IOMMU_IOAS_RESERVE_IOVAS ioctl
drivers/iommu/dma-iommu.c | 22 +++++---
drivers/iommu/iommu-priv.h | 17 ++++++
drivers/iommu/iommu.c | 37 +++++++++++++
drivers/iommu/iommufd/device.c | 65 ++++++++++++++++++++++
drivers/iommu/iommufd/io_pagetable.c | 7 ++-
drivers/iommu/iommufd/ioas.c | 49 +++++++++++++++++
drivers/iommu/iommufd/iommufd_private.h | 2 +
drivers/iommu/iommufd/main.c | 7 +++
include/uapi/linux/iommufd.h | 71 +++++++++++++++++++++++++
9 files changed, 267 insertions(+), 10 deletions(-)
--
2.43.7
next prev parent reply other threads:[~2026-10-28 7:19 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 7:02 [PATCH] iommu: Reserve PCI host bridge MMIO windows in group reserved regions Guanghui Feng
2026-09-21 10:39 ` [PATCH v2 0/2] iommu: Reserve PCI host bridge MMIO windows for IOVA Guanghui Feng
2026-09-21 10:39 ` [PATCH v2 1/2] iommu: Reserve PCI host bridge MMIO windows in group reserved regions Guanghui Feng
2026-09-21 10:39 ` [PATCH v2 2/2] iommufd: Reserve PCI host bridge MMIO windows in IOAS " Guanghui Feng
2026-09-21 11:24 ` [PATCH v2 0/2] iommu: Reserve PCI host bridge MMIO windows for IOVA Robin Murphy
2026-09-21 11:55 ` Jason Gunthorpe
2026-10-04 16:22 ` [PATCH v3 0/2] iommu/iommufd: Expose PCI host bridge MMIO windows for opt-in IOVA avoidance Guanghui Feng
2026-10-04 16:22 ` [PATCH v3 1/2] iommu: Add iommu_get_pci_resv_windows() helper Guanghui Feng
2026-10-22 19:35 ` Jason Gunthorpe
2026-10-04 16:22 ` [PATCH v3 2/2] iommufd: Add IOMMU_GET_PCI_MMIO_WINDOWS ioctl Guanghui Feng
2026-10-22 19:33 ` Jason Gunthorpe
2026-10-25 13:29 ` [PATCH v4 0/2] iommu/iommufd: Expose PCI host bridge MMIO windows for opt-in IOVA avoidance Guanghui Feng
2026-10-25 13:29 ` [PATCH v4 1/2] iommu: Add iommu_for_each_pci_mmio_window() iterator Guanghui Feng
2026-10-27 18:29 ` Jason Gunthorpe
2026-10-25 13:30 ` [PATCH v4 2/2] iommufd: Add IOMMU_GET_PCI_MMIO_WINDOWS ioctl Guanghui Feng
2026-10-27 18:34 ` Jason Gunthorpe
2026-10-28 7:19 ` Guanghui Feng [this message]
2026-10-28 7:19 ` [PATCH v5 1/3] iommu: Add iommu_for_each_pci_mmio_window() iterator Guanghui Feng
2026-10-28 7:19 ` [PATCH v5 2/3] iommufd: Add IOMMU_GET_RECOMMENDED_RESERVATIONS ioctl Guanghui Feng
2026-10-28 7:19 ` [PATCH v5 3/3] iommufd: Add IOMMU_IOAS_RESERVE_IOVAS ioctl Guanghui Feng
2026-10-28 9:04 ` [PATCH v6 0/3] iommufd: Recommended reservations query and opt-in IOAS reservation Guanghui Feng
2026-10-28 9:04 ` [PATCH v6 1/3] iommu: Add iommu_for_each_pci_mmio_window() iterator Guanghui Feng
2026-10-28 9:04 ` [PATCH v6 2/3] iommufd: Add IOMMU_GET_RECOMMENDED_RESERVATIONS ioctl Guanghui Feng
2026-10-28 9:04 ` [PATCH v6 3/3] iommufd: Add IOMMU_IOAS_RESERVE_IOVAS ioctl Guanghui Feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261028071906.2325378-1-guanghuifeng@linux.alibaba.com \
--to=guanghuifeng@linux.alibaba.com \
--cc=alex@shazbot.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®