From: David Matlack <dmatlack@google.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Alex Williamson <alex@shazbot.org>, Alex Mastro <amastro@fb.com>,
Shuah Khan <shuah@kernel.org>, Peter Xu <peterx@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH] vfio: selftests: Add vfio_dma_mapping_mmio_test
Date: Fri, 9 Jan 2026 00:43:32 +0000 [thread overview]
Message-ID: <aWBPNHOsaP1sNvze@google.com> (raw)
In-Reply-To: <20260109003621.GG545276@ziepe.ca>
On 2026-01-08 08:36 PM, Jason Gunthorpe wrote:
> On Thu, Jan 08, 2026 at 09:29:29PM +0000, David Matlack wrote:
> > On 2026-01-08 02:33 PM, Jason Gunthorpe wrote:
> > > On Thu, Jan 08, 2026 at 10:24:19AM -0800, David Matlack wrote:
> > > > > > Oh, I was thinking about a compatability only flow only in the type 1
> > > > > > emulation that internally magically converts a VMA to a dmabuf, but I
> > > > > > haven't written anything.. It is a bit tricky and the type 1 emulation
> > > > > > has not been as popular as I expected??
> > > > >
> > > > > In part because of this gap, I'd guess. Thanks,
> > > >
> > > > Lack of huge mappings in the IOMMU when using VFIO_TYPE1_IOMMU is
> > > > another gap I'm aware of.
> > > > vfio_dma_mapping_test.vfio_type1_iommu_anonymous_hugetlb_1gb.dma_map_unmap
> > > > fails when IOMMUFD_VFIO_CONTAINER is enabled.
> > >
> > > What is this? I'm not aware of it..
> >
> > It's one of the test cases within
> > tools/testing/selftests/vfio/vfio_dma_mapping_test.c.
> >
> > Here's the output when running with CONFIG_IOMMUFD_VFIO_CONTAINER=y:
> >
> > # RUN vfio_dma_mapping_test.vfio_type1_iommu_anonymous_hugetlb_1gb.dma_map_unmap ...
> > Mapped HVA 0x7f0480000000 (size 0x40000000) at IOVA 0x0
> > Searching for IOVA 0x0 in /sys/kernel/debug/iommu/intel/0000:6a:01.0/domain_translation_struct
> > Found IOMMU mappings for IOVA 0x0:
> > PGD: 0x0000000203475027
> > P4D: 0x0000000203476027
> > PUD: 0x0000000203477027
> > PMD: 0x00000001e7562027
> > PTE: 0x00000041c0000067
> > # tools/testing/selftests/vfio/vfio_dma_mapping_test.c:188:dma_map_unmap:Expected 0 (0) == mapping.pte (282394099815)
> > # dma_map_unmap: Test terminated by assertion
> > # FAIL vfio_dma_mapping_test.vfio_type1_iommu_anonymous_hugetlb_1gb.dma_map_unmap
>
> I can't think of any reason this would fail, I think your tests have
> found a real bug?? Can you check into it, what kernel call fails and
> where does the kernel code come from?
Oh I thought it was by design. This code in iommufd_vfio_set_iommu():
/*
* The difference between TYPE1 and TYPE1v2 is the ability to unmap in
* the middle of mapped ranges. This is complicated by huge page support
* which creates single large IOPTEs that cannot be split by the iommu
* driver. TYPE1 is very old at this point and likely nothing uses it,
* however it is simple enough to emulate by simply disabling the
* problematic large IOPTEs. Then we can safely unmap within any range.
*/
if (type == VFIO_TYPE1_IOMMU)
rc = iopt_disable_large_pages(&ioas->iopt);
git-blame says some guy named Jason Gunthorpe wrote it :P
>
> I don't think I can run these tests with the HW I have??
FWIW all you need any PCI device that can be bound to vfio-pci and
mapped by VT-d. This test does not rely on any of the VFIO selftests
drivers to trigger DMA.
next prev parent reply other threads:[~2026-01-09 0:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 22:13 [PATCH] vfio: selftests: Add vfio_dma_mapping_mmio_test Alex Mastro
2026-01-07 22:37 ` Alex Mastro
2026-01-07 23:54 ` David Matlack
2026-01-08 0:54 ` Jason Gunthorpe
2026-01-08 2:41 ` Alex Mastro
2026-01-08 14:10 ` Jason Gunthorpe
2026-01-08 15:45 ` Alex Williamson
2026-01-08 18:24 ` David Matlack
2026-01-08 18:33 ` Jason Gunthorpe
2026-01-08 21:29 ` David Matlack
2026-01-09 0:36 ` Jason Gunthorpe
2026-01-09 0:43 ` David Matlack [this message]
2026-01-09 0:54 ` Jason Gunthorpe
2026-01-09 17:04 ` David Matlack
2026-01-09 18:01 ` Jason Gunthorpe
2026-01-09 21:38 ` Alex Williamson
2026-01-13 23:47 ` David Matlack
2026-01-08 3:36 ` Alex Mastro
2026-01-08 14:38 ` Jason Gunthorpe
2026-01-08 16:25 ` Alex Mastro
2026-01-08 23:04 ` Alex Mastro
2026-01-08 15:42 ` Alex Williamson
2026-01-08 18:20 ` David Matlack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aWBPNHOsaP1sNvze@google.com \
--to=dmatlack@google.com \
--cc=alex@shazbot.org \
--cc=amastro@fb.com \
--cc=jgg@ziepe.ca \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=peterx@redhat.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.