On Fri, Jan 9, 2026 at 1:38 PM Alex Williamson <[email protected]> wrote: > > On Fri, 9 Jan 2026 14:01:53 -0400 > Jason Gunthorpe <[email protected]> wrote: > > > On Fri, Jan 09, 2026 at 09:04:30AM -0800, David Matlack wrote: > > > > If you really want to test TYPE1 you need to test what makes it > > > > unique, which is that you can map any VMA and then unmap any slice of > > > > it. Including within what should otherwise be a 1G page. > > > > > > > > But I doubt anyone cares enough to fix this, so just exclude > > > > VFIO_TYPE1_IOMMU from this test? > > > > > > Ah, ok, thanks for the explanation. So VFIO_TYPE1_IOMMU should always > > > use 4K mappings regardless of backend (VFIO or iommufd) so that unmap > > > can work as intended. > > > > IDK, I think you should just ignore testing TYPE1v0. The actual real > > semantics that it had are quite confusing and iommufd provides an > > emulation that is going to be functionally OK (indeed, functionally > > more capable) but is not the exactly the same. > > > > The old comment here is sort of enlightening: > > > > + * vfio-iommu-type1 (v1) - User mappings were coalesced together to > > + * avoid tracking individual mappings. This means that the > > granularity > > + * of the original mapping was lost and the user was allowed to > > attempt > > + * to unmap any range. Depending on the contiguousness of physical > > + * memory and page sizes supported by the IOMMU, arbitrary unmaps > > may > > + * or may not have worked. We only guaranteed unmap granularity > > + * matching the original mapping; even though it was untracked here, > > + * the original mappings are reflected in IOMMU mappings. This > > + * resulted in a couple unusual behaviors. First, if a range is not > > + * able to be unmapped, ex. a set of 4k pages that was mapped as a > > + * 2M hugepage into the IOMMU, the unmap ioctl returns success but > > with > > + * a zero sized unmap. Also, if an unmap request overlaps the first > > + * address of a hugepage, the IOMMU will unmap the entire hugepage. > > + * This also returns success and the returned unmap size reflects > > the > > + * actual size unmapped. > > > > iommufd does not try to do this "returned unmap size reflects the > > actual size unmapped" part, it always unmaps exactly what was > > requested, because it disables huge pages. > > I think there was also some splitting code in the IOMMU drivers that > has since been removed that may have made the v1 interface slightly > more sane. It certainly never restricted mappings to PAGE_SIZE in > order to allow arbitrary unmaps, it relied on users to do sane things > and examine the results. Those "sane things" sort of became the v2 > interface. > > In any case, we've had v2 for a long time and if IOMMUFD compat make v1 > more bloated and slow such that users realize they're using an old, > crappy interface, that's probably for the best. Examining what page > size is used for v1 is probably not worthwhile though. Thanks,
Ack. I'll send a patch to skip the page size checks for v1.
