mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®