Message-ID: <CALzav=cE4SQbbcWL9-bhHPEjCq3DPOWnGZnqrHcvR5mYB_t3cA@mail.gmail.com>
Date: Tue, 13 Jan 2026 15:47:53 -0800
From: David Matlack <dmatlack@...gle.com>
To: Alex Williamson <alex@...zbot.org>
Cc: Jason Gunthorpe <jgg@...pe.ca>, 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 9, 2026 at 1:38 PM Alex Williamson <alex@...zbot.org> wrote:
>
> On Fri, 9 Jan 2026 14:01:53 -0400
> Jason Gunthorpe <jgg@...pe.ca> 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.

Powered by blists - more mailing lists