linux.git/tools/testing/kunit/kunit_kernel.py, branch v7.2-rc1 Linux kernel source tree kunit: Fix spelling mistakes in comments and messages 2026-05-04T19:12:55+00:00 Jinseok Kim always.starving0@gmail.com 2026-05-01T16:27:37+00:00 c12222dcce91170a8031e03559c3e88916475f14 Fix two spelling mistakes in kunit tooling: Bascially -> Basically higer -> higher Link: https://lore.kernel.org/r/20260501162739.3861-1-always.starving0@gmail.com Signed-off-by: Jinseok Kim <always.starving0@gmail.com> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
Fix two spelling mistakes in kunit tooling:
  Bascially -> Basically
  higer     -> higher

Link: https://lore.kernel.org/r/20260501162739.3861-1-always.starving0@gmail.com
Signed-off-by: Jinseok Kim <always.starving0@gmail.com>
Reviewed-by: David Gow <david@davidgow.net>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
kunit: tool: Terminate kernel under test on SIGINT 2026-04-06T20:09:04+00:00 David Gow david@davidgow.net 2026-02-28T10:07:22+00:00 8f260b02eeeffbf2263c2b82b6e3e32fd73cde2b kunit.py will attempt to catch SIGINT / ^C in order to ensure the TTY isn't messed up, but never actually attempts to terminate the running kernel (be it UML or QEMU). This can lead to a bit of frustration if the kernel has crashed or hung. Terminate the kernel process in the signal handler, if it's running. This requires plumbing through the process handle in a few more places (and having some checks to see if the kernel is still running in places where it may have already been killed). Reported-by: Andy Shevchenko <andriy.shevchenko@intel.com> Closes: https://lore.kernel.org/all/aaFmiAmg9S18EANA@smile.fi.intel.com/ Signed-off-by: David Gow <david@davidgow.net> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Tested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
kunit.py will attempt to catch SIGINT / ^C in order to ensure the TTY isn't
messed up, but never actually attempts to terminate the running kernel (be
it UML or QEMU). This can lead to a bit of frustration if the kernel has
crashed or hung.

Terminate the kernel process in the signal handler, if it's running. This
requires plumbing through the process handle in a few more places (and
having some checks to see if the kernel is still running in places where it
may have already been killed).

Reported-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Closes: https://lore.kernel.org/all/aaFmiAmg9S18EANA@smile.fi.intel.com/
Signed-off-by: David Gow <david@davidgow.net>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Tested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
kunit: tool: skip stty when stdin is not a tty 2026-04-06T20:07:29+00:00 Shuvam Pandey shuvampandey1@gmail.com 2026-02-27T12:31:36+00:00 e42c349f4cdfa43cb39a68c8f764f8cafc23a9a9 run_kernel() cleanup and signal_handler() invoke stty unconditionally. When stdin is not a tty (for example in CI or unit tests), this writes noise to stderr. Call stty only when stdin is a tty. Add regression tests for these paths: - run_kernel() with non-tty stdin - signal_handler() with non-tty stdin - signal_handler() with tty stdin Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
run_kernel() cleanup and signal_handler() invoke stty unconditionally.
When stdin is not a tty (for example in CI or unit tests), this writes
noise to stderr.

Call stty only when stdin is a tty.

Add regression tests for these paths:
- run_kernel() with non-tty stdin
- signal_handler() with non-tty stdin
- signal_handler() with tty stdin

Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com>
Reviewed-by: David Gow <david@davidgow.net>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
kunit: tool: copy caller args in run_kernel to prevent mutation 2026-03-02T17:02:06+00:00 Shuvam Pandey shuvampandey1@gmail.com 2026-02-26T15:29:10+00:00 40804c4974b8df2adab72f6475d343eaff72b7f6 run_kernel() appended KUnit flags directly to the caller-provided args list. When exec_tests() calls run_kernel() repeatedly (e.g. with --run_isolated), each call mutated the same list, causing later runs to inherit stale filter_glob values and duplicate kunit.enable flags. Fix this by copying args at the start of run_kernel(). Add a regression test that calls run_kernel() twice with the same list and verifies the original remains unchanged. Fixes: ff9e09a3762f ("kunit: tool: support running each suite/test separately") Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
run_kernel() appended KUnit flags directly to the caller-provided args
list. When exec_tests() calls run_kernel() repeatedly (e.g. with
--run_isolated), each call mutated the same list, causing later runs
to inherit stale filter_glob values and duplicate kunit.enable flags.

Fix this by copying args at the start of run_kernel(). Add a regression
test that calls run_kernel() twice with the same list and verifies the
original remains unchanged.

Fixes: ff9e09a3762f ("kunit: tool: support running each suite/test separately")
Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com>
Reviewed-by: David Gow <david@davidgow.net>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
kunit: tool: Implement listing of available architectures 2025-04-15T16:54:50+00:00 Thomas Weißschuh thomas.weissschuh@linutronix.de 2025-04-15T07:03:06+00:00 6cf6b0a6f204e8b10e2b69e74953f029ea83a8a9 To implement custom scripting around kunit.py it is useful to get a list of available architectures. While it is possible to manually inspect tools/testing/kunit/qemu_configs/, this is annoying to implement and introduces a dependency on a kunit.py implementation detail. Introduce 'kunit.py run --arch help' which lists all known architectures in an easy to parse list. This is equivalent on how QEMU implements listing of possible argument values. Link: https://lore.kernel.org/r/20250415-kunit-list-v2-1-aa452cd317ae@linutronix.de Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Rae Moar <rmoar@google.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
To implement custom scripting around kunit.py it is useful to get a list of
available architectures. While it is possible to manually inspect
tools/testing/kunit/qemu_configs/, this is annoying to implement and
introduces a dependency on a kunit.py implementation detail.

Introduce 'kunit.py run --arch help' which lists all known architectures
in an easy to parse list. This is equivalent on how QEMU implements
listing of possible argument values.

Link: https://lore.kernel.org/r/20250415-kunit-list-v2-1-aa452cd317ae@linutronix.de
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Rae Moar <rmoar@google.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
kunit: tool: Build GDB scripts 2025-02-18T21:28:01+00:00 Brendan Jackman jackmanb@google.com 2025-01-21T13:01:40+00:00 43ebec94e1e8f6187c67bbe395b304a03ee63de5 Following a similar rationale as commit e4835f1da425f ("kunit: tool: Build compile_commands.json"), make a common developer tool available by default for KUnit users. Compared to compile_commands.json, there is a little more work to be done to build the GDB scripts. Is it enough to affect development cycle duration? Unscientific evaluation: rm -rf .kunit; time tools/testing/kunit/kunit.py build --kunitconfig ./lib/kunit/.kunitconfig --jobs 96 Without this patch it took 14.77s, with this patch it took 14.83. So, although `make scripts_gdb` is pretty slow, presumably most of that is just the overhead of running Kbuild at all, actually building the scripts is approximately free. Note also, to actually get the GDB scripts the user needs to enable CONFIG_SCRIPTS_GDB, but building the scripts_gdb target without that is still harmless. Link: https://lore.kernel.org/r/20250121-kunit-gdb-v1-1-faedfd0653ef@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
Following a similar rationale as commit e4835f1da425f ("kunit: tool:
Build compile_commands.json"), make a common developer tool available by
default for KUnit users.

Compared to compile_commands.json, there is a little more work to be
done to build the GDB scripts. Is it enough to affect development cycle
duration? Unscientific evaluation:

rm -rf .kunit; time tools/testing/kunit/kunit.py build --kunitconfig ./lib/kunit/.kunitconfig --jobs 96

Without this patch it took 14.77s, with this patch it took 14.83. So,
although `make scripts_gdb` is pretty slow, presumably most of that is
just the overhead of running Kbuild at all, actually building the
scripts is approximately free.

Note also, to actually get the GDB scripts the user needs to enable
CONFIG_SCRIPTS_GDB, but building the scripts_gdb target without that is
still harmless.

Link: https://lore.kernel.org/r/20250121-kunit-gdb-v1-1-faedfd0653ef@google.com
Signed-off-by: Brendan Jackman <jackmanb@google.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
kunit: enable hardware acceleration when available 2025-01-14T21:56:56+00:00 Tamir Duberstein tamird@gmail.com 2024-11-02T12:09:49+00:00 220374e70b0b9d44ab5ec1106bc16caf20f94d80 Use KVM or HVF if supported by the QEMU binary and available on the system. This produces a nice improvement on my Apple M3 Pro running macOS 14.7: Before: ./tools/testing/kunit/kunit.py exec --arch arm64 [HH:MM:SS] Elapsed time: 10.145s After: ./tools/testing/kunit/kunit.py exec --arch arm64 [HH:MM:SS] Elapsed time: 1.773s Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
Use KVM or HVF if supported by the QEMU binary and available on the
system.

This produces a nice improvement on my Apple M3 Pro running macOS 14.7:

Before:
./tools/testing/kunit/kunit.py exec --arch arm64
[HH:MM:SS] Elapsed time: 10.145s

After:
./tools/testing/kunit/kunit.py exec --arch arm64
[HH:MM:SS] Elapsed time: 1.773s

Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
kunit: tool: Allow overriding the shutdown mode from qemu config 2024-11-19T22:26:30+00:00 Thomas Weißschuh thomas.weissschuh@linutronix.de 2024-11-11T05:29:19+00:00 0a1111d4cbaf45100e30ebd98d1e1a175b8ce22d Not all platforms support machine reboot. If it a proper reboot is not supported the machine will hang. Allow the QEMU configuration to override the necessary shutdown mode for the specific system under test. Link: https://lore.kernel.org/r/20241111-kunit-loongarch-v2-2-7676eb5f2da3@linutronix.de Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
Not all platforms support machine reboot.
If it a proper reboot is not supported the machine will hang.
Allow the QEMU configuration to override the necessary shutdown mode for
the specific system under test.

Link: https://lore.kernel.org/r/20241111-kunit-loongarch-v2-2-7676eb5f2da3@linutronix.de
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
kunit: tool: Build compile_commands.json 2024-09-12T15:52:36+00:00 Brendan Jackman jackmanb@google.com 2024-05-16T19:40:53+00:00 e4835f1da425fbc75e37ce8258c9927170de5bfe compile_commands.json is used by clangd[1] to provide code navigation and completion functionality to editors. See [2] for an example configuration that includes this functionality for VSCode. It can currently be built manually when using kunit.py, by running: ./scripts/clang-tools/gen_compile_commands.py -d .kunit With this change however, it's built automatically so you don't need to manually keep it up to date. Unlike the manual approach, having make build the compile_commands.json means that it appears in the build output tree instead of at the root of the source tree, so you'll need to add --compile-commands-dir=.kunit to your clangd args for it to be found. This might turn out to be pretty annoying, I'm not sure yet. If so maybe we can later add some hackery to kunit.py to work around it. [1] https://clangd.llvm.org/ [2] https://github.com/FlorentRevest/linux-kernel-vscode Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
compile_commands.json is used by clangd[1] to provide code navigation
and completion functionality to editors. See [2] for an example
configuration that includes this functionality for VSCode.

It can currently be built manually when using kunit.py, by running:

  ./scripts/clang-tools/gen_compile_commands.py -d .kunit

With this change however, it's built automatically so you don't need to
manually keep it up to date.

Unlike the manual approach, having make build the compile_commands.json
means that it appears in the build output tree instead of at the root of
the source tree, so you'll need to add --compile-commands-dir=.kunit to
your clangd args for it to be found. This might turn out to be pretty
annoying, I'm not sure yet. If so maybe we can later add some hackery to
kunit.py to work around it.

[1] https://clangd.llvm.org/
[2] https://github.com/FlorentRevest/linux-kernel-vscode

Signed-off-by: Brendan Jackman <jackmanb@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
kunit: tool: Print UML command 2024-02-27T21:46:34+00:00 Mickaël Salaün mic@digikod.net 2024-01-18T15:14:22+00:00 ee8bd4a428a9c538e08aa5bc797fca19d577f667 As for the Qemu command, print the command used to run tests with UML. Cc: Brendan Higgins <brendan.higgins@linux.dev> Cc: David Gow <davidgow@google.com> Signed-off-by: Mickaël Salaün <mic@digikod.net> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> 
As for the Qemu command, print the command used to run tests with UML.

Cc: Brendan Higgins <brendan.higgins@linux.dev>
Cc: David Gow <davidgow@google.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>