linux-kernel - Re: [PATCH] vfio: selftests: Skip vfio_dma_map_limit

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: <20251110081709.53b70993.alex@shazbot.org>
Date: Mon, 10 Nov 2025 08:17:09 -0700
From: Alex Williamson <alex@...zbot.org>
To: Alex Mastro <amastro@...com>
Cc: David Matlack <dmatlack@...gle.com>, Alex Williamson
 <alex.williamson@...hat.com>, Jason Gunthorpe <jgg@...pe.ca>,
 <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] vfio: selftests: Skip vfio_dma_map_limit_test if
 mapping returns -EINVAL

On Sat, 8 Nov 2025 17:20:10 -0800
Alex Mastro <amastro@...com> wrote:

> On Sat, Nov 08, 2025 at 02:37:10PM -0700, Alex Williamson wrote:
> > On Sat, 8 Nov 2025 12:19:48 -0800
> > Alex Mastro <amastro@...com> wrote:  
> > > Here's my attempt at adding some machinery to query iova ranges, with
> > > normalization to iommufd's struct. I kept the vfio capability chain stuff
> > > relatively generic so we can use it for other things in the future if needed.  
> > 
> > Seems we were both hacking on this, I hadn't seen you posted this
> > before sending:
> > 
> > https://lore.kernel.org/kvm/20251108212954.26477-1-alex@shazbot.org/T/#u
> > 
> > Maybe we can combine the best merits of each.  Thanks,  
> 
> Yes! I have been thinking along the following lines
> - Your idea to change the end of address space test to allocate at the end of
>   the supported range is better and more general than my idea of skipping the
>   test if ~(iova_t)0 is out of bounds. We should do that.
> - Introducing the concept iova allocator makes sense.
> - I think it's worthwhile to keep common test concepts like vfio_pci_device
>   less opinionated/stateful so as not to close the door on certain categories of
>   testing in the future. For example, if we ever wanted to test IOVA range
>   contraction after binding additional devices to an IOAS or vfio container.

Yes, fetching the IOVA ranges should really occur after all the devices
are attached to the container/ioas rather than in device init.  We need
another layer of abstraction for the shared IOMMU state.  We can
probably work on that incrementally.

I certainly like the idea of testing range contraction, but I don't
know where we can reliably see that behavior.

> - What do you think about making the concept of an IOVA allocator something
>   standalone for which tests that need it can create one? I think it would
>   compose pretty cleanly on top of my vfio_pci_iova_ranges().

Yep, that sounds good.  Obviously what's there is just the simplest
possible linear, aligned allocator with no attempt to fill gaps or
track allocations for freeing.  We're not likely to exhaust the address
space in an individual unit test, I just wanted to relieve the test
from the burden of coming up with a valid IOVA, while leaving some
degree of geometry info for exploring the boundaries.

Are you interested in generating a combined v2?

TBH I'm not sure that just marking a test as skipped based on the DMA
mapping return is worthwhile with a couple proposals to add IOVA range
support already on the table.  Thanks,

Alex