Re: [PATCH] vfio: selftests: Skip vfio_dma_map_limit_test if mapping returns -EINVAL

Alex Mastro
2025-11-10T16:49:29Z

On Mon, Nov 10, 2025 at 08:17:09AM -0700, Alex Williamson wrote:
> On Sat, 8 Nov 2025 17:20:10 -0800
> Alex Mastro <amastro@fb.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@fb.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.

I'm not sure about the exact testing strategy for that yet either actually.

> > - 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.

Keeping the simple linear allocator makes sense to me.

> Are you interested in generating a combined v2?

Sure -- I can put up a v2 series which stages like so
- adds stateless low level iova ranges queries
- adds iova allocator utility object
- fixes end of ranges tests, uses iova allocator instead of iova=vaddr

> 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,

I'll put up the new series rooted on linux-vfio/next soon.