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: <CALzav=eRa49+2wSqrDL1gSw8MpMwXVxb9bx4hvGU0x_bOXypuw@mail.gmail.com>
Date: Thu, 8 Jan 2026 10:24:19 -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 Thu, Jan 8, 2026 at 7:45 AM Alex Williamson <alex@...zbot.org> wrote:
>
> On Thu, 8 Jan 2026 10:10:44 -0400
> Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> > On Wed, Jan 07, 2026 at 06:41:10PM -0800, Alex Mastro wrote:
> > > On Wed, Jan 07, 2026 at 08:54:06PM -0400, Jason Gunthorpe wrote:
> > > > On Wed, Jan 07, 2026 at 11:54:09PM +0000, David Matlack wrote:
> > > > > On 2026-01-07 02:13 PM, Alex Mastro wrote:
> > > > > > Test MMIO-backed DMA mappings by iommu_map()-ing mmap'ed BAR regions.
> > > > >
> > > > > Thanks for adding this!
> > > > >
> > > > > > Also update vfio_pci_bar_map() to align BAR mmaps for efficient huge
> > > > > > page mappings.
> > > > > >
> > > > > > Only vfio_type1 variants are tested; iommufd variants can be added
> > > > > > once kernel support lands.
> > > > >
> > > > > Are there plans to support mapping BARs via virtual address in iommufd?
> > > > > I thought the plan was only to support via dma-bufs. Maybe Jason can
> > > > > confirm.
> > > >
> > > > Only dmabuf.
> > >
> > > Ack. I got confused. I had thought iommufd's vfio container compatibility mode
> > > was going to support this, but realized that doesn't make sense given past
> > > discussions about the pitfalls of achieving these mappings the legacy way.
> >
> > 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.

Is the plan to address all the gaps so IOMMUFD_VFIO_CONTAINER can be
made the default and the type1 code can be dropped from the upstream
kernel?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ