hostap/tests/hwsim/vm
Johannes Berg 18cdbb3c80 tests: Add a script to aid bisecting Linux kernel with hwsim VM
I find myself writing a version of this script every now and
then, but there's little point in that - just add one to the
tree so we can use it again.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2017-10-21 12:04:53 +03:00
..
.gitignore hwsim tests: Add scripts to run in a VM 2013-10-31 11:08:16 +02:00
bisect-run.sh tests: Add a script to aid bisecting Linux kernel with hwsim VM 2017-10-21 12:04:53 +03:00
build-codecov.sh tests: Fix --codecov cases to find correct wpa_cli/hostapd_cli 2014-12-29 15:49:04 +02:00
combine-codecov.sh tests: Remove src/common/cli.c from code coverage report 2016-12-26 14:30:50 +02:00
dbus.conf tests: Enable wpa_supplicant D-Bus support for hwsim tests 2015-01-02 22:50:27 +02:00
example-vm-setup.txt tests: Step-by-step guide for testing in VM 2017-01-29 14:32:17 +02:00
inside.sh tests: Print higher debug level on console 2017-07-08 15:19:24 +03:00
kernel-config tests: Comment out CONFIG_DEBUG_KOBJECT_RELEASE from default config 2017-01-29 16:06:44 +02:00
parallel-vm.py tests: Split proxyarp test cases into IPv4 and IPv6 parts 2017-01-29 14:32:17 +02:00
parallel-vm.sh tests: Honor HWSIM_TEST_LOG_DIR variable in VM runs 2015-11-27 21:11:53 +02:00
process-codecov.sh tests: Use new scripts for vm-run.sh codecov 2014-12-21 16:41:59 +02:00
README tests: Update vm README 2014-11-01 17:08:29 +02:00
uevent.sh tests: vm: Honor EPATH in uevent.sh 2015-12-18 00:24:51 +02:00
vm-run.sh tests: Allow passing more arguments to vm-run.sh 2015-11-30 14:03:28 +02:00

These scripts allow you to run the hwsim tests inside a KVM virtual machine.

To set it up, first compile a kernel with the kernel-config file as the
.config. You can adjust it as needed, the configuration is for a 64-bit
x86 system and should be close to minimal. The architecture must be the
same as your host since the host's filesystem is used.

Install the required tools: at least 'kvm', if you want tracing trace-cmd,
valgrind if you want, etc.

Compile the hwsim tests as per the instructions given, you may have to
install some extra development packages (e.g. binutils-dev for libbfd).

Create a vm-config file and put the KERNELDIR option into it (see the
vm-run.sh script). If you want valgrind, also increase the memory size.

Now you can run the vm-run.sh script and it will execute the tests using
your system's root filesystem (read-only) inside the VM. The options you
give it are passed through to run-all.sh, see there.

To speed up testing, it is possible to run multiple VMs concurrently and
split the test cases between all the VMs. If the host system has enough
memory and CPU resources, this can significantly speed up the full test
cycle. For example, a 4 core system with 4 GB of RAM can easily run 8
parallel VMs (assuming valgrind is not used with its higher memory
requirements). This can be run with:

./parallel-vm.sh <number of VMs> [arguments..]


--------------------------------------------------------------------------------

Code Coverage Analysis for user space code

Code coverage for wpa_supplicant and hostapd can be generated from the
test run with following command line:

./vm-run.sh --codecov [other arguments..]

This builds a separate copies of wpa_supplicant and hostapd into a
directory that is writable from the virtual machine to collect the gcov
data. lcov is then used to prepare the reports at the end of the test
run.


Code Coverage Analysis for kernel code

In order to do code coverage analysis, reconfigure the kernel to include

CONFIG_GCOV_KERNEL=y
CONFIG_GCOV_PROFILE_ALL=y

Note that for gcc 4.7, kernel version 3.13-rc1 or higher is required.

The scripts inside the VM will automatically copy the gcov data out of the
VM into the logs directory. To post-process this data, you'll want to use
lcov and run

cd /tmp/hwsim-test-logs/<timestamp>
lcov -b <path to kernel dir> -c -d gcov/ > gcov/data
genhtml -o html/ gcov/data

Then open html/index.html in your browser.

Note that in this case you need to keep your build and source directories
across the test run (otherwise, it's safe to only keep the kernel image.)