From: Alex Mastro <amastro@fb.com>
To: Alex Williamson <alex@shazbot.org>
Cc: David Matlack <dmatlack@google.com>,
Alex Williamson <alex.williamson@redhat.com>,
Jason Gunthorpe <jgg@ziepe.ca>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] vfio: selftests: Skip vfio_dma_map_limit_test if mapping returns -EINVAL
Date: Sat, 8 Nov 2025 17:20:10 -0800 [thread overview]
Message-ID: <aQ/sShi4MWr6+f5l@devgpu015.cco6.facebook.com> (raw)
In-Reply-To: <20251108143710.318702ec.alex@shazbot.org>
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.
- 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().
Alex
next prev parent reply other threads:[~2025-11-09 1:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-07 22:20 [PATCH] vfio: selftests: Skip vfio_dma_map_limit_test if mapping returns -EINVAL David Matlack
2025-11-08 0:17 ` Alex Mastro
2025-11-08 20:19 ` Alex Mastro
2025-11-08 21:37 ` Alex Williamson
2025-11-09 1:20 ` Alex Mastro [this message]
2025-11-10 15:17 ` Alex Williamson
2025-11-10 16:48 ` Alex Mastro
2025-11-10 18:00 ` David Matlack
2025-11-10 18:37 ` Alex Williamson
2025-11-10 19:45 ` David Matlack
2025-11-10 23:10 ` 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=aQ/sShi4MWr6+f5l@devgpu015.cco6.facebook.com \
--to=amastro@fb.com \
--cc=alex.williamson@redhat.com \
--cc=alex@shazbot.org \
--cc=dmatlack@google.com \
--cc=jgg@ziepe.ca \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox