On Mon, Nov 10, 2025 at 1:11 PM Alex Mastro <[email protected]> wrote: > > Not all IOMMUs support the same virtual address width as the processor, > for instance older Intel consumer platforms only support 39-bits of > IOMMU address space. On such platforms, using the virtual address as > the IOVA and mappings at the top of the address space both fail. > > VFIO and IOMMUFD have facilities for retrieving valid IOVA ranges, > VFIO_IOMMU_TYPE1_INFO_CAP_IOVA_RANGE and IOMMU_IOAS_IOVA_RANGES, > respectively. These provide compatible arrays of ranges from which > we can construct a simple allocator and record the maximum supported > IOVA address. > > Use this new allocator in place of reusing the virtual address, and > incorporate the maximum supported IOVA into the limit testing. This > latter change doesn't test quite the same absolute end-of-address space > behavior but still seems to have some value. Testing for overflow is > skipped when a reduced address space is supported as the desired errno > is not generated. > > This series is based on Alex Williamson's "Incorporate IOVA range info" > [1] along with feedback from the discussion in David Matlack's "Skip > vfio_dma_map_limit_test if mapping returns -EINVAL" [2]. > > Given David's plans to split IOMMU concerns from devices as described in > [3], this series' home for `struct iova_allocator` is likely to be short > lived, since it resides in vfio_pci_device.c. I assume that the rework > can move this functionality to a more appropriate location next to other > IOMMU-focused code, once such a place exists.
Yup, I'll rebase my iommu rework on top of this once it goes in, and move the iova allocator to a new home. And thanks for getting this out so quickly. We've had an unstaffed internal task to get rid of iova=vaddr open for a few months now, so I'm very happy to see it get fixed.
