Enabling ARM64 CPU Capabilities in the Linux Kernel

ARM64 design defines features long before there is a CPU that can implement those features. Since the ARM ecosystem is so varied, there are many different CPU designs out there with different capabilities. A general purpose linux Kernel build put out by a major distribution has to work across a wide array of chips by a large nuymber of vendors. Thus, there is an enumeration of the capabilities inside the Kernel and mechnism for describing how to probe each of these capabilities.

Continue reading →

Finding Linux Kernel Config options in menuconfig

We have reason to believe that we should not be setting CONFIG_EFI_DISABLE_RUNTIME=y In our Kernel configs. I want to perform a controlled expereient booting two Kernel builds, one with this option set and one with it disabled. Since I have the option set, building that Kernel is trivial.

 make olddefconfig
 make -j$(nproc)  rpm-pkg

Now, to turn that option off, I could just edit the .config file. However, it is possible that there are other config options linked to that one, and there is logic to modify them together. I want to see what happens if I use make menuconfig to change the option to confirm (or deny) that only that option gets changed. But where do I find this option in the menu?

Continue reading →

Building and Running the Linux Kernel Selftests on AARCH64/ Fedora

I won’t go into checking out or building the Kernel, as that is covered elsewhere. Assuming you have a buildable Kernel, you can build the tests with:

make -C tools/testing/selftests

But you are probably going to see errors like this:

ksm_tests.c:7:10: fatal error: numa.h: No such file or directory
    7 | #include <numa.h>
      |          ^~~~~~~~
compilation terminated.

The userland test suites use several libraries and need headers to compile the tests that call those libraries. Here is the yum, line I ran to get the dependencies I needed for my system:

sudo yum install libmnl-devel fuse-devel numactl-devel libcap-ng-devel alsa-lib-devel

With those installed, the make line succeeded.

Running the test like this CRASHED THE SYSTEM. Don’t do this.

 make -C tools/testing/selftests run_tests

A more sensible test to run is the example on the Docs page:

# make -C tools/testing/selftests TARGETS=ptrace run_tests
make: Entering directory '/root/linux/tools/testing/selftests'
make --no-builtin-rules ARCH=arm64 -C ../../.. headers_install
make[1]: Entering directory '/root/linux'
  INSTALL ./usr/include
make[1]: Leaving directory '/root/linux'
make[1]: Entering directory '/root/linux/tools/testing/selftests/ptrace'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/root/linux/tools/testing/selftests/ptrace'
make[1]: Entering directory '/root/linux/tools/testing/selftests/ptrace'
TAP version 13
1..3
# selftests: ptrace: get_syscall_info
# TAP version 13
# 1..1
# # Starting 1 tests from 1 test cases.
# #  RUN           global.get_syscall_info ...
# #            OK  global.get_syscall_info
# ok 1 global.get_syscall_info
# # PASSED: 1 / 1 tests passed.
# # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
ok 1 selftests: ptrace: get_syscall_info
# selftests: ptrace: peeksiginfo
# PASS
ok 2 selftests: ptrace: peeksiginfo
# selftests: ptrace: vmaccess
# TAP version 13
# 1..2
# # Starting 2 tests from 1 test cases.
# #  RUN           global.vmaccess ...
# #            OK  global.vmaccess
# ok 1 global.vmaccess
# #  RUN           global.attach ...
 
 
# # attach: Test terminated by timeout
# #          FAIL  global.attach
# not ok 2 global.attach
# # FAILED: 1 / 2 tests passed.
# # Totals: pass:1 fail:1 xfail:0 xpass:0 skip:0 error:0
not ok 3 selftests: ptrace: vmaccess # exit=1
make[1]: Leaving directory '/root/linux/tools/testing/selftests/ptrace'
make: Leaving directory '/root/linux/tools/testing/selftests'

Next up is to write my own stub test.