This is a small series to clean up the io-pgtable-arm library.

The first patch was originally part of SMMUv3 KVM driver support[1],
which was needed to factor out the kernel code from the io-pgtable-arm
library, and based on Jason’s suggestion this can taken out as a cleanup
and to converge to kunit.

The first patch just moves the code to a new file with no other changes,
so it can be easier to review it with “--color-moved”

The second patch registers the test using kunit, and converges some of
the APIs, some notes about that:

Dealing with __init:
--------------------
At the moment, all the test code and data are part of the init section.
To avoid changing all the functions and data and removing them from the
init section, we can rely on the kunit “kunit_test_init_section_suite”
to keep the test in the init section.
That will make the results only available on debugfs (there is no
possibility to run them after boot) unlike the SMMUv3 tests for example
which can run on-demand.

As the of results are saved in the kunit structs, they can’t be tagged
as __init_data, instead they are be tagged to __refdata to avoid the
modpost warning, as it’s guaranteed that kunit will only access the results,
not the test after init.

Instead, we can remove the __init constraint, and be able to run the tests
on-demand, and possibly compile it as a module.

Granularity of tests:
---------------------
To make the series easier to review, the series changes the test to run in
kunit without making intrusive changes to the test itself.
It’s possible to refactor the tests to have smaller granularity (although
I think that would make it less efficient as we might create the same io-pgtable
config multiple times) and integrate them in kunit as multiple tests, that
change would be more intrusive, if you think that is the right approach,
I can add a couple of more patches re-writing the tests.

Other changes:
--------------
- Also, to make the test changes minimal, and fail messages similar, “KUNIT_FAIL”
  is used to fail all tests instead of using KUNIT specific assertions.

- Instead of using faux device, we rely on kunit_device_register()

- The WARN is removed when a test fails, as that doesn’t seem to be a pattern
  used with kunit.


A failure at the test with the new implementation look as
[    2.115982]     # io_pgtable_arm_test_run: EXPECTATION FAILED at drivers/iommu/io-pgtable-arm-selftests.c:94
[    2.118381]     # io_pgtable_arm_test_run: selftest: test failed for fmt idx 0
[    2.118501]     # io_pgtable_arm_test_run: cfg: pgsize_bitmap 0x40201000, ias 32-bit
[    2.118863]     # io_pgtable_arm_test_run: data: 3 levels, 0x20 pgd_size, 12 pg_shift, 9 bits_per_level, pgd @ 00000000a15afb2d


[1] https://lore.kernel.org/all/20250819215156.2494305-5-smostafa@google.com/


Mostafa Saleh (2):
  iommu/io-pgtable-arm: Move selftests to a separate file
  iommu/io-pgtable-arm-selftest: Use KUnit

 drivers/iommu/Kconfig                    |   2 +-
 drivers/iommu/Makefile                   |   1 +
 drivers/iommu/io-pgtable-arm-selftests.c | 223 +++++++++++++++++++++
 drivers/iommu/io-pgtable-arm.c           | 243 -----------------------
 drivers/iommu/io-pgtable-arm.h           |  41 ++++
 5 files changed, 266 insertions(+), 244 deletions(-)
 create mode 100644 drivers/iommu/io-pgtable-arm-selftests.c

-- 
2.51.0.384.g4c02a37b29-goog

On Wed, Sep 17, 2025 at 02:02:01PM +0000, Mostafa Saleh wrote:
> Instead, we can remove the __init constraint, and be able to run the tests
> on-demand, and possibly compile it as a module.

I think you can just put the kunit in a module to avoid all this?

alloc_io_pgtable_ops() is always exported, and I didn't notice any
symbols crossing from io-pgtable-arm-selftests.c to io-pgtable-arm??

Jason

On Wed, Sep 17, 2025 at 11:44:35AM -0300, Jason Gunthorpe wrote:
> On Wed, Sep 17, 2025 at 02:02:01PM +0000, Mostafa Saleh wrote:
> > Instead, we can remove the __init constraint, and be able to run the tests
> > on-demand, and possibly compile it as a module.
> 
> I think you can just put the kunit in a module to avoid all this?

Yes, I don’t see the point of trying to run everything from __init,
relaxing that allows us to use more of the kunit infrastructure.
But, it’s more code to do so (it’s just longer to explain :)),
I can add a patch in between, modularizing the selftest before kunit.

> 
> alloc_io_pgtable_ops() is always exported, and I didn't notice any
> symbols crossing from io-pgtable-arm-selftests.c to io-pgtable-arm??

No there is not.

Thanks,
Mostafa

> 
> Jason

On Wed, Sep 17, 2025 at 03:00:55PM +0000, Mostafa Saleh wrote:
> On Wed, Sep 17, 2025 at 11:44:35AM -0300, Jason Gunthorpe wrote:
> > On Wed, Sep 17, 2025 at 02:02:01PM +0000, Mostafa Saleh wrote:
> > > Instead, we can remove the __init constraint, and be able to run the tests
> > > on-demand, and possibly compile it as a module.
> > 
> > I think you can just put the kunit in a module to avoid all this?
> 
> Yes, I don’t see the point of trying to run everything from __init,
> relaxing that allows us to use more of the kunit infrastructure.
> But, it’s more code to do so (it’s just longer to explain :)),
> I can add a patch in between, modularizing the selftest before kunit.

Sounds good, also it would be good to include the kunit.py
instructions in the commit message:

Eg this is one from my iommpt series:

    tools/testing/kunit/kunit.py run --build_dir build_kunit_arm64 --arch arm64 --make_options LLVM=-19 --kunitconfig ./drivers/iommu/generic_pt/.kunitconfig

You can run that from x86, which is really how I'd recommend anyone
actually use this kunit rather than booting a live system and trying
to run the test before the system boots enough to explode on a buggy
implementation :)

Jason