Re: Enabling additional KUnit tests in KernelCI?

Mark Brown <[email protected]> Thu, 12 Mar 2026 23:34:51 +0000
Newsgroups dev.linux.lists.kernelci
Message-ID <[email protected]>
--RfluQZs15kmIELpL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Mar 12, 2026 at 02:51:45PM -0700, Eric Biggers wrote:
> On Thu, Mar 12, 2026 at 08:21:26PM +0000, Mark Brown wrote:

> > We should be running KUnit tests:

> >   https://github.com/kernelci/kernelci-pipeline/blob/a3b622cfee641e26bed1906b29ed7065bee45921/config/jobs.yaml#L2153

> >   https://github.com/kernelci/kernelci-pipeline/blob/a3b622cfee641e26bed1906b29ed7065bee45921/config/scheduler.yaml#L1750

> Which ones?  Does anything need to be done to add new tests to the list?

> Note that even if "all" tests are being run (via
> CONFIG_KUNIT_ALL_TESTS=y), that includes only the tests whose
> dependencies are met.  There can be additional kconfig dependencies.

Whatever is enabled by the KUnit runner tools/testing/kunit/kunit.py
(which makes x86_64 a bit of an unfortunate choice given how slim theilr
defconfig is).  The theory is that the KUnit configs will do the right
thing, it looks like we're not currently pasing --alltests though which
we should - I'll look at a patch for that tomorrow.  If you need arch
specific options that aren't enabled by the platform's defconfig that
gets a bit awkward.

> > though like you say something seems to be going AWOL with at least the
> > reporting, I can't see any results either.  The job that's configured
> > there is to run on x86_64 rather than UML so is probably what you're
> > looking for in terms of the tests?

> The kernel has optimized crypto and/or CRC code for the following
> architectures: arm, arm64, mips, powerpc, riscv, s390, sparc, x86.  In
> many cases there's also a finer division based on CPU features.

> So I'm looking for testing on as many platforms as possible.  But some
> x86_64 platform is a good start, certainly better than nothing.

The KUnit runner uses qemu as standard which I guess is probably fine
for an initial pass, we would need to do a bunch more plumbing to run on
actual hardware and pull the results out.  We'd also be restricted by
what's available to us, at the minute we've got arm, arm64, riscv and
x86 systems with a bit of an embedded focus.

--RfluQZs15kmIELpL
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmmzTZsACgkQJNaLcl1U
h9CH9Qf8CSlZcjTsoAFDzuGgeeqydONo6hEw/xauyBIen59zvdpibNC+kLbPfMMW
qYmEbcrR5mcjlDsevw3euteI2aa7TrmQ+X/4CaspUQZA7OS6dZKmoYGZJEzgMpTF
fKmVhlKHzMPDZwDBB4mWhhU+5JK4wxl1piMh8msNRX5g29Mm8g9cinOlJZ0mJ0qt
gXliC0ef/AMXYxSvBtgrS/jez4PKXyFNNiSywEvCyVfu6nm4ZM+vwkpKPt8Ch+3K
qwbSgEh34UeWmSEXijaOeUEl2wXn9uRbqTbg1g59qFPDJnjt9hCrP9BQTu5uXi4C
GvrAmB0Q0kvdobGNLJ/LioFgmFHBGA==
=ZNCA
-----END PGP SIGNATURE-----

--RfluQZs15kmIELpL--