On Mon, 18 Aug 2025 11:59:39 -0700
David Matlack <dmatl...@google.com> wrote:
> On Thu, Jul 31, 2025 at 1:55 PM David Matlack <dmatl...@google.com> wrote:
> >
> > On Tue, Jul 29, 2025 at 3:26 PM Jason Gunthorpe <j...@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 <dmatl...@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,
Alex
