Quoting Guenter Roeck (2024-10-03 21:52:09)
On 10/3/24 17:42, Stephen Boyd wrote:
Can you please describe how you run the kunit test? And provide the qemu
command you run to boot arm64 with acpi?
Example command line:
qemu-system-aarch64 -M virt -m 512 \
-kernel arch/arm64/boot/Image -no-reboot -nographic \
-snapshot \
-bios /opt/buildbot/rootfs/arm64/../firmware/QEMU_EFI-aarch64.fd \
-device virtio-blk-device,drive=d0 \
-drive file=rootfs.ext2,if=none,id=d0,format=raw \
-cpu cortex-a57 -serial stdio -monitor none -no-reboot \
--append "kunit.stats_enabled=2 kunit.filter=speed>slow root=/dev/vda rootwait earlycon=pl011,0x9000000 console=ttyAMA0"
That works fine for me. Configuration is arm64 defconfig plus various
debug and kunit options. I built the efi image myself from sources.
The root file system is from buildroot with modified init script.
kunit tests are all built into the kernel and run during boot.
Thanks. I figured out that I was missing enabling CONFIG_ACPI. Here's my
commandline
./tools/testing/kunit/kunit.py run --arch=arm64 \
--kunitconfig=drivers/of \
--qemu_args="-bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -smp 2" \
--kconfig_add="CONFIG_ACPI=y" \
--kernel_args="earlycon=pl011,0x9000000"
Now I can boot and reproduce the failure, but there's another problem.
ACPI disables itself when it fails to find tables.
ACPI: Unable to load the System Description Tables
This calls disable_acpi() which sets acpi_disabled to 1. This happens
before the unit test runs, meaning we can't reliably use 'acpi_disabled'
as a method to skip.
The best I can come up with then is to test for a NULL of_root when
CONFIG_ARM64 and CONFIG_ACPI are enabled, because the tests
intentionally don't work when both those configs are enabled and the
'of_root' isn't populated. In all other cases the 'of_root' missing is a
bug. I'll probably make this into some sort of kunit helper function in
of_private.h and send it to DT maintainers.