There are several x86 instructions that are not allowed in a virtualized environment. Hence, I introduced a new CPU model called virtual in the i386 branch of RTEMS, which is equal to the native branch, except sensitive instructions like hlt, cli, sli.

score/cpu, libcpu/, virtual, native and the CPU model conditional

In a virtual environment a client is not allowed to halt the CPU or mess with the interrupt flag. Therefore, we need a CPU model avoiding these instructions and using a different way to tell the hypervisor, to not deliver interrupts.

In RTEMS several CPU models can be provided for one architecture in the libcpu/ directory. Therefore the BSP defines a flag RTEMS_CPU_MODEL in the BSP’s config file, e.g. libbsp/i386/virtPok/make/custom/virtPok.cfg. In libcpu the configure.ac file contains a check for the RTEMS_CPU_MODEL name and defines a variable usable in Makefile.am. Using this method different CPU models of the same architecture can be defined.

In my configuration RTEMS_CPU_MODEL=virt-pok and the variable generated by configure.ac is VIRT_POK. The Makefile branches conditionally depending on this variable, choosing a different directory: native or virtual.

cpukit/score/cpu/i386/ contains the basic architecture files. In this directory no function containing a sensitive instruction is allowed. A list of the functions and in which files they are can be found on the wiki page.

I moved these functions to new files and placed the files containing the original functions in the native branch of the libcpu/i386/ directory and modified the virtual functions to use the virtualization layer functions defined in virtLayerCPU.h.

virtPok BSP

Actually this BSP could also be named virtualBSP or hypervisorBSP, as at the end all calls to the hardware should instead go to the virtualization layer – virtLayerBSP.h. So it is not dependent on the used host system.

virtPok/include contains both header files: virtLayerCPU.h and virtLayerBSP.h. Both header files must be considered in Makefile.am and are therefore added to include_HEADERS. The most interesting part in Makefile.am is the rule to append the library provided by the host: libpart.a, to libbsp.a. Unfortunately, libpok.a can’t be appended right away. Instead it must be extracted, the .lo files need to be renamed to .o files and then all .o files from libpart.a can be appended to libbsp.a.

This BSP doesn’t need to initialize hardware, so the start/_start.S code is much shorter than on actual hardware. Basically, it just provides the entry point calling boot_card() and if that returns a call to bsp_reset.

linkcmds is much more interesting, as it has to ensure POK gets a binary file it recognizes. Therefore, ENTRY(start) is set. The rest is the same as in pc386, but some changes will be made in the future.

The last part considered up to now is the console. As HelloWorld wants to write to the screen, we need a working console driver. However, we cannot make any assumptions about the hardware. Hence, if we want to write to the console, we call virt_charWrite(), defined in virtLayerBSP.h.