 34708b4893
			
		
	
	
		34708b4893
		
	
	
	
	
		
			
			Include a defconfig for building kernel as UML. Also update the README with a few notes related to UML. Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com>
		
			
				
	
	
		
			80 lines
		
	
	
	
		
			2.9 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			80 lines
		
	
	
	
		
			2.9 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
| These scripts allow you to run the hwsim tests inside a KVM virtual machine or
 | |
| as a UML (User Mode Linux) program.
 | |
| 
 | |
| To set it up, first compile a kernel with the kernel-config[.uml] 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.
 | |
| 
 | |
| To build the regular x86_64 kernel, simply issue
 | |
| 
 | |
| yes "" | make -j <n_cpus>
 | |
| 
 | |
| or to build UML:
 | |
| 
 | |
| yes "" | ARCH=um make -j <n_cpus>
 | |
| 
 | |
| Running a UML kernel is recommended as it can optimize out any sleep()s or
 | |
| kernel timers by taking advantage of UML time travel mode, greatly increasing
 | |
| test efficiency (~3200 tests can be run in under 5 minutes using parallel-vm.py
 | |
| on a 24 core CPU).
 | |
| 
 | |
| 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.py <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.)
 |