linux-kernel - Re: [PATCH 0/4] vfio: selftests: update DMA mapping tests to use queried IOVA ranges

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=e5JD4_4+vqa6udd0dSymW7W-=8Fnf-q0VaBv20+BvXBQ@mail.gmail.com>
Date: Mon, 10 Nov 2025 15:06:58 -0800
From: David Matlack <dmatlack@...gle.com>
To: Alex Mastro <amastro@...com>
Cc: Alex Williamson <alex@...zbot.org>, Shuah Khan <shuah@...nel.org>, kvm@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Jason Gunthorpe <jgg@...pe.ca>
Subject: Re: [PATCH 0/4] vfio: selftests: update DMA mapping tests to use
 queried IOVA ranges

On Mon, Nov 10, 2025 at 1:11 PM Alex Mastro <amastro@...com> wrote:
>
> Not all IOMMUs support the same virtual address width as the processor,
> for instance older Intel consumer platforms only support 39-bits of
> IOMMU address space.  On such platforms, using the virtual address as
> the IOVA and mappings at the top of the address space both fail.
>
> VFIO and IOMMUFD have facilities for retrieving valid IOVA ranges,
> VFIO_IOMMU_TYPE1_INFO_CAP_IOVA_RANGE and IOMMU_IOAS_IOVA_RANGES,
> respectively.  These provide compatible arrays of ranges from which
> we can construct a simple allocator and record the maximum supported
> IOVA address.
>
> Use this new allocator in place of reusing the virtual address, and
> incorporate the maximum supported IOVA into the limit testing.  This
> latter change doesn't test quite the same absolute end-of-address space
> behavior but still seems to have some value.  Testing for overflow is
> skipped when a reduced address space is supported as the desired errno
> is not generated.
>
> This series is based on Alex Williamson's "Incorporate IOVA range info"
> [1] along with feedback from the discussion in David Matlack's "Skip
> vfio_dma_map_limit_test if mapping returns -EINVAL" [2].
>
> Given David's plans to split IOMMU concerns from devices as described in
> [3], this series' home for `struct iova_allocator` is likely to be short
> lived, since it resides in vfio_pci_device.c. I assume that the rework
> can move this functionality to a more appropriate location next to other
> IOMMU-focused code, once such a place exists.

Yup, I'll rebase my iommu rework on top of this once it goes in, and
move the iova allocator to a new home.

And thanks for getting this out so quickly. We've had an unstaffed
internal task to get rid of iova=vaddr open for a few months now, so
I'm very happy to see it get fixed.