From: Jason Gunthorpe <jgg@ziepe.ca>
To: Guanghui Feng <guanghuifeng@linux.alibaba.com>
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: Re: [PATCH v3 2/2] iommufd: Add IOMMU_GET_PCI_MMIO_WINDOWS ioctl
Date: Thu, 22 Oct 2026 16:33:59 -0300 [thread overview]
Message-ID: <20261022193359.GF3381610@ziepe.ca> (raw)
In-Reply-To: <20261004162213.3787623-3-guanghuifeng@linux.alibaba.com>
On Mon, Oct 05, 2026 at 12:22:13AM +0800, Guanghui Feng wrote:
> +/**
> + * struct iommu_pci_mmio_window - a PCI host bridge MMIO window
> + * @start: First PCI bus address of the window
> + * @last: Inclusive last PCI bus address of the window
> + *
> + * A memory window claimed by the PCI host bridge that a device sits
> + * behind. Addresses are PCI bus addresses (i.e. what appears in the
> + * TLP), which differ from CPU physical addresses on platforms where the
> + * host bridge applies an address translation offset. For a device
> + * using an identity (1:1) IOVA layout the IOVA equals the bus address,
> + * so these are the IOVAs that a PCIe switch could misinterpret as
> + * peer-to-peer DMA and route to the wrong device instead of memory.
iommufd has no way to use devices that are not 1:1, don't talk about
this stuff in the kdocs.
> +/**
> + * struct iommu_pci_mmio_windows - ioctl(IOMMU_GET_PCI_MMIO_WINDOWS)
> + * @size: sizeof(struct iommu_pci_mmio_windows)
> + * @flags: Must be 0
> + * @dev_id: The device bound to iommufd to query
> + * @num_windows: Input/output number of MMIO windows
> + * @windows: Pointer to the output array of struct iommu_pci_mmio_window
> + *
> + * Query the memory windows of the PCI host bridge that @dev_id sits
> + * behind. This is advisory: the kernel does not reserve these ranges, it
> + * only reports them so userspace can choose to keep its IOVA allocations
> + * away from them and avoid accidental peer-to-peer DMA routing. The
> + * reported windows are pessimistic (the whole host bridge window, not the
> + * precise BAR ranges that may actually conflict). If a IOAS has devices
> + * behind multiple host bridges, query each device and take the union.
State clearly in the kdoc if the list is strictly non-overlapping, or
the list can have overlapping ranges. It makes a big difference to how
userspace has to process things.
> + * On input num_windows is the length of the windows array. On output it
> + * is the total number of windows. The ioctl will return -EMSGSIZE and set
> + * num_windows to the required value if num_windows is too small. In this
> + * case the caller should allocate a larger output array and re-issue the
> + * ioctl.
> + *
> + * Return: 0 on success, -EOPNOTSUPP if @dev_id is not a PCI device,
> + * -ENOENT if @dev_id is invalid, -EMSGSIZE if the output array is too
> + * small.
> + */
> +struct iommu_pci_mmio_windows {
> + __u32 size;
> + __u32 flags;
> + __u32 dev_id;
> + __u32 num_windows;
> + __aligned_u64 windows;
IIRC out_windows is the convention in iommufd
Jason
next prev parent reply other threads:[~2026-10-22 19:34 UTC|newest]
Thread overview: 29+ 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 7:15 ` sashiko-bot
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:50 ` sashiko-bot
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-04 16:31 ` sashiko-bot
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 [this message]
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 ` [PATCH v5 0/3] iommufd: Recommended reservations query and opt-in IOAS reservation Guanghui Feng
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 7:33 ` sashiko-bot
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
2026-10-28 9:14 ` sashiko-bot
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=20261022193359.GF3381610@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=alex@shazbot.org \
--cc=guanghuifeng@linux.alibaba.com \
--cc=iommu@lists.linux.dev \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.