On 8/18/25 13:37, Alex Williamson wrote:
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/
Acked-by: Shuah Khan <sk...@linuxfoundation.org>
Glad to see these test in the kselftest suite.
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,
thanks,
-- Shuah
