kvm unit tests

Kernel-based Virtual Machine (KVM) is a virtualization infrastructure for the Linux kernel that turns it into a hypervisor. KVM requires a processor with hardware virtualization extensions.

This project, as its name suggests, is to provide unit tests for KVM. The unit tests are tiny guest operating systems that generally execute only tens of lines of C and assembler test code in order to obtain its PASS/FAIL/SKIP result.
Unit tests provide KVM and virtual hardware functional testing by targeting the features through minimal implementations of their use per the hardware specification. The simplicity of unit tests make them easy to verify they are correct,
easy to maintain, and easy to use in timing measurements. Unit tests are also often used for quick and dirty bug reproducers.

Build and Run

Building this project is very easy, we just need to enter the directory and run “./configure; make”. If there isn’t any mistake, it means this project is successfully built. As can be seen from its name, it is a testing program so running
it means running some tests on KVM. In addition, as other verification systems, it also has some single test cases and a whole test suite. What has to be aware is we need to install “kvm” or “qemu-kvm” before testing, otherwise, the
tests will just “SKIP” because it is just for testing KVM.

First, I will run a single test case which is in the “x86/” directory named “syscall.flat”. The result is as follows.

Then, I will run a test suite. The following picture is part of the result. I found that there are 3 status of the test results which are PASS, FAIL and SKIP.

From the picture, we can see that not all tests are PASS, which means this version of KVM may have many points to be improved.

Analyze the Test

To write a test case/suite, we first need to analyze an example. From the file “run_tests.sh”, we could find that it runs each test in “x86/unittests.cfg”. This is a section of this file. From it, we could know that when the test suite
runs to here, it will find test case “apic.flat” and run it in the x86_64 architecture within 30 seconds.

The result of every test case is printed to the screen by the “runtime.bash” script.

What’s more, we could find the detailed information of every test case from “logs/” directory.

After analyzing a test suite, let’s look at a single test case. I will choose the “syscall.flat” as an example. Let’s see the main function. There are two subfunctions which is consistent with the first screenshot.

Now I will focus on a single function as the following picture shows. It just tests some single function calls and report the results.

Write A Test

Because I can’t know about KVM clearly for such a short period of time, here I just write a simple test, in order to experience how to write a test case.

After compiling and running it, we could get this expected output.

Now I could put my test case to the test suite, adding such code to the “unittests.cfg” file.

Also, it must be PASS as expected.

Analyze the Framework

In the beginning, let’s analyze the directory structure.

• ./api/: there are three API categories 1) libc, 2) functions typical of kernel code, and 3) kvm-unit-tests specific.
• ./lib/: general architecture neutral services for the tests.
• ./x86/: the sources of the tests and the created images of X86 architecture.
• ./logs/: the output information.
• ./scripts/: helper scripts for building and running tests.
• others: configure script, top-level Makefile, and run_tests.sh.

The framework has the following components:

• Test building support
• Shared code for test setup and API
• Test running support

Test building is done through makefiles and some supporting bash scripts. Test setup code includes, for example, early system init, MMU enablement, and UART init. The API provides some common libc functions, as well as some low-level helper
functions commonly seen in kernel code and some kvm-unit-tests specific APIs. Test running is provided with a few bash scripts, using a unit tests configuration file as input. Generally tests are run from within the source root directory
using the supporting scripts, but tests may optionally be built as standalone tests as well.

本文链接： http://www.meng.uno/articles/50351d5d/ 欢迎转载！