linux-kernel - Re: [PATCH] vfio: selftests: Add vfio_dma_mapping_mmio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260109180153.GI545276@ziepe.ca>
Date: Fri, 9 Jan 2026 14:01:53 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: David Matlack <dmatlack@...gle.com>
Cc: Alex Williamson <alex@...zbot.org>, Alex Mastro <amastro@...com>,
	Shuah Khan <shuah@...nel.org>, Peter Xu <peterx@...hat.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH] vfio: selftests: Add vfio_dma_mapping_mmio_test

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.

Jason