Linux KVM as a Learning Tool

Low-level system programming is a difficult task, but with Linux KVM, it's a whole lot easier.

16-Bit Real-Address Mode

Processors compatible with the x86 architecture can support different
operating modes. Two of them are 16-bit real-address mode. The most
frequently used, these days at least, is 32-bit protected mode. The processor starts
in real-address mode after a power-up or reset (so platform initialization
code has to be written for this mode) and jumps to the instruction at
address 0xFFFF0. Usually, the BIOS's initialization routine is located
here. The first instruction of our simple kernel will be located there
to take control of the platform as soon as it boots. Although with KVM
it is possible to start a virtual machine directly in protected mode,
our launcher won't do that in order to learn how to manipulate a PC just
after power-up.

The 16-bit real-address mode is a legacy mode inherited from the Intel
8086 processor, which is able to address up to 1Mb of memory. 1Mb is
220
bytes, so addresses require 20 bits. Given that the 8086's registers
are only 16-bit wide, addresses are built by pairing two values. The
first value is used as a selector (stored in a segment register), and
the second value is used as an offset. With these, physical addresses
are computed by the formula: 16 * selector + offset.

For example, the selector:offset 0xDEAD:0xBEEF represents the physical address 0xEA9BF.
To multiply the selector (0xDEAD) by 16, simply add a 0 to the right side
of the number (0xDEAD0). The addition then becomes the following:

0xDEAD0
+ 0x0BEEF
-------
0xEA9BF

Note that given a fixed value for the selector, it is possible to
reference only 64Kb of memory (the offset's allowed range). Programs bigger
than 64Kb must use multi-segment code. We will keep our kernel simple
and make it fit into a single 64Kb segment. Our launcher will put the
kernel image in the last segment (where the 0xFFFF0 entry point resides).
The last segment starts at 0xF0000 as shown by the following calculation:

We now can write a kernel in assembler with its first instruction at offset 0xFFFF0.
Note that unlike many processors, the x86 processor does not have a
reset “vector”. It does not use the value at 0xFFFF0 as the location
of the reset code; rather, it begins executing the code that is
at 0xFFFF0.
Therefore, the “normal” code to place at 0xFFFF0 is a jump to the actual reset code.

Our first kernel is shown in Listing 4.
It merely sets the AX register to 0 and then loops forever.

In the second to the last line, the dot (.) refers to the current location counter.
Therefore, when we write:

. = 0xfff0

we instruct the assembler to set the current location to address 0xFFF0. In
real-mode, address 0xFFF0 is relative to the current segment.
Where does the segment offset get specified?
It comes from the call to load_file() in Listing 3. It loads the kernel
at offset 0xF0000. This, combined with the assembler offset,
will place the ljmp at address 0xFFFF0, as required.

How to Build It

The kernel binary should be a raw 64Kb 16-bit real-address mode image, and
not a normal ELF binary (the standard binary format used by Linux).
To do this, we need a special linker script.
We use GNU ld for this, of course, which
accepts script files to provide explicit control over the linking process.

A linker is a program that combines input binary files into a single
output file. Each file is expected to have, among other things, a list
of sections, sometimes with an associated block of data. The linker's function
is to map input sections into output sections. GNU ld uses,
by default, a linker script specific for the host platform, which you
can view by using the -verbose flag:

$ gcc -Wl,-verbose hello-world.c

To build our kernel, we don't use the default script but instead the
simple script kernel16.lds, shown in Listing 5.

Comment viewing options

Thanks for this excellent article. I've tested out the sample but the program never returns after the kvm_run() call. I guess this is because the vcpu is halted in the last instruction of the test program. But how do I exit the KVM altogether and resume execution from kvm_run() onwards? Is there any documentation for libkvm somewhere I can consult?

See the userspace git tree. Is this the lib we need to be building to follow this article? I've been looking to do something like this with KVM for a while to create my own forth-like environment without having to screw around with low level hardware (or at least put it off til something interesting already works). Look forward to the follow up article. When is it scheduled?

My attempt to follow this tutorial died on page 2, when it announced that all of the examples would be using the LibKVM library. Several hours of searching on Google and I've found nothing; no way to install or use the LibKVM library unless I'm on BSD.

If anyone has a workaround for this, I'd love to hear it. I was really looking forward to following the tutorial.

That's a different library. You need to install the qemu-kvm-devel package. Note you will probably have to get it directly from sourceforge since it does not appear to be in the Ubuntu repos. I don't use Ubuntu much so maybe I'm overlooking something, however, I know that openSUSE does not have a package for it either (at least in the standard places at 11.0). Make sure that you get the version that corresponds to the version of kvm that you have installed. For example, here is a link to the -devel package for release 88.

If you have to install it from sourceforge some fiddling around will probably be required. First, you'll have to build it, then install it, and then potentially modify your include/library paths to find the needed items.

Trending Topics

Upcoming Webinar

Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report

August 27, 2015
12:00 PM CDT

DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.