On 2026-07-02 11:28 PM, Narayana Murty N wrote: > This RFC adds PowerPC sPAPR TCE v2 support to VFIO selftests.
nit: Please use "vfio: selftests: ..." for commit shortlogs. > The series adds a selftest IOMMU mode for the legacy VFIO container > backend, adds helpers for default and dynamic DMA windows, and exercises > the sPAPR DDW path through the DMA mapping tests. Thanks for sending. Is there anyway I could run these tests on PowerPC, e.g. with QEMU, to try things out? I don't have access to any hardware. > sPAPR TCE v2 remains a legacy VFIO container backend. This series does > not add iommufd or VFIO cdev support for sPAPR. > > The main points are > 1. add VFIO_SELFTESTS_IOMMU_MODE for selecting a backend > 2. add vfio_spapr_tce_v2_iommu as the PowerPC VFIO backend > 3. preserve the platform default DMA window > 4. create and tear down only selftest-created DDWs > 5. prepare the DMA window before IOVA allocation > 6. exercise DDW creation for hugepage DMA mappings > 7. accept sPAPR-specific errno for invalid DMA ranges > > Example: > > VFIO_SELFTESTS_IOMMU_MODE=vfio_spapr_tce_v2_iommu > ./vfio_dma_mapping_test <BDF> > > Observed coverage includes anonymous mappings through the default window > and 2MB hugetlb mappings through a DDW. 1GB hugetlb mappings may skip when > the platform rejects the requested DDW characteristics. > > Feedback is requested from the VFIO and PowerPC communities on: > 1. whether the sPAPR TCE v2 helpers should remain in the common VFIO > selftest library or move into a sPAPR-specific test helper? Responded in the patch. Let's move to their own file. > 2. whether DDW setup through hugepage mappings is the right initial > coverage? One thing I'm not sure is how much value you get out of exercising the DDW stuff through that test specifically. Would it make more sense to have a DDW-specific test so you can test all the edge cases you care about directly instead? Then vfio_dma_mapping_test can stay generic. BTW, is that the only test that passes right now? What is the status of the other VFIO selftests on PowerPC after this series? > 3. whether the sPAPR-specific overflow errno expectation should be > accepted, skipped, or hidden behind a backend helper? Responded in the patch. Let's keep the check but base it off IOMMU mode not __powerpc__. Also it'd be good to avoid duplicating the code with a helper function or macro but that's a small thing. > 4. whether PowerPC should generate only the sPAPR TCE v2 fixture variants, > or keep the generic IOMMU-mode matrix and skip unsupported modes. For (4), I think skipping unsupported modes would be a good improvement. Even on x86 and ARM we would want that feature. e.g. It's possible for someone to run VFIO selftests on a kernel that has VFIO Type1 IOMMUs enabled but not IOMMUFD. Today that will cause all the tests to fail. But ideally it would wouldn't. Tests that just want the default IOMMU mode should use Type1, and tests that want to replicate across all IOMMU modes should skip the IOMMUFD variants. Same thing applies to the SPAPR IOMMU mode. > > TODO: vfio_spapr_tce_v1_iommu yet to be covered. > > Narayana Murty N (6): > selftests/vfio: allow selecting IOMMU backend from environment > selftests/vfio: add sPAPR TCE v2 IOMMU mode > selftests/vfio: add sPAPR TCE v2 DMA window helpers > selftests/vfio: Exercise sPAPR DDW path for hugepage DMA mappings > selftests/vfio: Accept sPAPR errno for DMA range overflow > selftests/vfio: Enable VFIO selftests on ppc64 and ppc64le > > .../selftests/vfio/lib/include/libvfio.h | 9 + > .../vfio/lib/include/libvfio/iommu.h | 26 ++ > tools/testing/selftests/vfio/lib/iommu.c | 280 +++++++++++++++++- > tools/testing/selftests/vfio/lib/libvfio.c | 37 +++ > .../selftests/vfio/vfio_dma_mapping_test.c | 30 ++ > .../selftests/vfio/vfio_pci_device_test.c | 4 +- > tools/testing/selftests/vfio/Makefile | 2 +- > 7 files changed, 382 insertions(+), 6 deletions(-) > > -- > 2.51.1 >
