Re: [PATCH v4 2/2] iommufd: Add IOMMU_GET_PCI_MMIO_WINDOWS ioctl

[Jason Gunthorpe <jgg@ziepe.ca>]

On Sun, Oct 25, 2026 at 09:30:00PM +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.  These are PCI bus addresses (what appears in the TLP).
> + * A PCIe switch could misinterpret DMA to these addresses as
> + * peer-to-peer traffic and route it to the wrong device.
> + */
> +struct iommu_pci_mmio_window {
> +	__aligned_u64 start;
> +	__aligned_u64 last;
> +};

We already have struct iommu_iova_range, don't need another one.

> +
> +/**
> + * 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
> + * @out_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).
> + *
> + * Windows are reported in host bridge resource list order.  They are
> + * typically non-overlapping (host bridge address decoders are exclusive)
> + * but no sorting guarantee is made.  Userspace should treat them as a
> + * set and compute the union if needed.
> + *
> + * If an IOAS has devices behind multiple host bridges, query each device
> + * and take the union of the results.
> + *
> + * On input num_windows is the length of the out_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 out_windows;
> +};
> +#define IOMMU_GET_PCI_MMIO_WINDOWS \
> +	_IO(IOMMUFD_TYPE, IOMMUFD_CMD_GET_PCI_MMIO_WINDOWS)
>  #endif

I wonder if this should have the word PCI in it..

Maybe this is 'recommended reserved regions' or something?

This is also lacking a way to send the ranges back in so they create a
restriction for the allocator.

Jason