Re: [PATCH 00/33] vfio: Introduce selftests for VFIO

[David Matlack <dmatlack@google.com>]

On Mon, Aug 18, 2025 at 12:37 PM Alex Williamson
<alex.williamson@redhat.com> wrote:
>
> On Mon, 18 Aug 2025 11:59:39 -0700
> David Matlack <dmatlack@google.com> wrote:
>
> > On Thu, Jul 31, 2025 at 1:55 PM David Matlack <dmatlack@google.com> wrote:
> > >
> > > On Tue, Jul 29, 2025 at 3:26 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
> > > >
> > > > On Mon, Jul 28, 2025 at 10:27:37AM -0600, Alex Williamson wrote:
> > > > > On Fri, 25 Jul 2025 09:47:48 -0700
> > > > > David Matlack <dmatlack@google.com> wrote:
> > > > > > I also was curious about your thoughts on maintenance of VFIO
> > > > > > selftests, since I don't think we discussed that in the RFC. I am
> > > > > > happy to help maintain VFIO selftests in whatever way makes the most
> > > > > > sense. For now I added tools/testing/selftests/vfio under the
> > > > > > top-level VFIO section in MAINTAINERS (so you would be the maintainer)
> > > > > > and then also added a separate section for VFIO selftests with myself
> > > > > > as a Reviewer (see PATCH 01). Reviewer felt like a better choice than
> > > > > > Maintainer for myself since I am new to VFIO upstream (I've primarily
> > > > > > worked on KVM in the past).
> > > > >
> > > > > Hi David,
> > > > >
> > > > > There's a lot of potential here and I'd like to see it proceed.
> > > >
> > > > +1 too, I really lack time at the moment to do much with this but I'm
> > > > half inclined to suggest Alex should say it should be merged in 6
> > > > weeks (to motivate any reviewing) and we can continue to work on it
> > > > in-tree.
> > > >
> > > > As they are self tests I think there is alot more value in having the
> > > > tests than having perfect tests.
> > >
> > > They have been quite useful already within Google. Internally we have
> > > something almost identical to the RFC and have been using that for
> > > testing our 6.6-based kernel continuously since March. Already they
> > > have caught one (self-inflicted) regression where 1GiB HugeTLB pages
> > > started getting mapped with 2MiB mappings in the IOMMU, and have been
> > > very helpful with new development (e.g. Aaron's work, and Live Update
> > > support).
> > >
> > > So I agree, it's probably net positive to merge early and then iterate
> > > in-tree. Especially since these are only tests and not e.g.
> > > load-bearing kernel code (although I still want to hold a high bar for
> > > the selftests code).
> > >
> > > The only patches to hold off merging would be 31-33, since those
> > > should probably go through the KVM tree? And of course we need Acks
> > > for the drivers/dma/{ioat,idxd} changes, but the changes there are
> > > pretty minor.
> >
> > Alex, how would you like to proceed?
>
> I think we need an ack from Shuah for the overall inclusion in
> tools/testing/selftests/
>
> AFAICT the tools include files don't seem to have any central
> authority, so maybe we just need to chase those ioat/idxd acks, along
> with Shuah's and we can get this rolling and follow-up with the latter
> KVM patches once the base is merged.  Thanks,

Sounds good.

And yeah, I also don't see any maintainers listed for tools/include/
or tools/arch/x86/include/. Jason left some comments on the RFC that
reduced the delta in v1, but that's the only feedback I've gotten so
far there.

I will try emailing Shuah and the ioat/idxd maintainers directly as a
next step, since it has been about 2 months since I posted this series
and we haven't heard anything yet.

Thanks for the help.