Processor Virtualization

Modern processor architectures feature two different execution modes. In the problem mode for application tasks, also known as user mode, only a subset of the instruc-tion set can be executed. In the supervisor mode for system software, also known as kernel mode or privileged mode, the entire instruction set can be executed. The subset of the instruction set that is only available in supervisor mode is called the set of privileged instructions and it provides full access to processor state and func-tionality. [Stallings, 2005] Robust virtualization requires that the hypervisor retains control of the hardware, so only the hypervisor can be executed in supervisor mode.

The guest systems have to be executed entirely in problem mode, including guest operating system. [Smith and Nair, 2005a]

When executed in problem mode, a privileged instruction causes a trap, a syn-chronous interrupt that results in a switch to supervisor mode, wherein the system software handles the privileged instruction. An example for a privileged instruction from the Power ISA is mtmsr (move to machine state register) [IBM, 2010].

An instruction is sensitive, if it either affects the state of the hardware or if its execution directly depends on the processor mode or the memory location where it is executed. An example for a sensitive instruction is again mtmsr, since it directly af-fects the machine state register. Popek and Goldberg defined privileged and sensitive instructions in a formal manner and stated the following fundamental theorem:

Theorem 2.2.1. (Trap-and-emulate) Virtualizable Instruction Set Archi-tecture. For any conventional third generation computer², a virtual machine mon-itor may be constructed if the set of sensitive instructions for that computer is a subset of the set of privileged instructions [Popek and Goldberg, 1974b].

Figure 2.5 depicts the condition of this theorem. On the right, the ISA is virtual-izable according to their theorem. The ISA on the left is not. Non-virtualvirtual-izable are instructions that are sensitive, but non-privileged: executed by a guest system, they can manipulate the hardware state without being noticed by the hypervisor, since they do not trap when executed in problem mode. An example for such an ISA is x86 [Robin and Irvine, 2000]: the instruction popf (pop flags) may change processor flags (e.g., IF, which controls interrupt delivery), but executed in user modes does not cause a trap [Adams and Agesen, 2006].

If Theorem 2.2.1 is fulfilled, as it is for example the case for the Power ISA, full virtualization is possible: unmodified guests (compared to the direct execution on hardware) can be executed on top of the hypervisor. The hypervisor is able to intercept and emulate all sensitive instructions. This has the significant advantage that the guest operating system does not have to be aware of whether being executed on bare hardware or by a hypervisor. The virtualization is transparent to it.

But system virtualization can be applied as well if the condition of Popek and Goldberg’s theorem is not fulfilled. It is actually not a theorem for virtualizability in general, but only for the ability to virtualize a system by trap-and-emulate. Binary translation, paravirtualization, and hardware virtualization assistance all make non-virtualizable (i.e., non-privileged and sensitive) instructions trap when executed in

2Popek and Goldberg address a computer with a processor with two modes of operation and linear, uniformly addressable memory.

2.2 Hypervisor-based Virtualization 27

instruction set

non-privileged privileged

sensitive

(a)

instruction set

non-privileged privileged

sensitive

(b)

Figure 2.5: Popek and Goldberg’s requirement for a virtualizable instruction set architecture: is the set of sensitive instructions a subset of the set of privileged instructions? (a) not fulfilled; (b) fulfilled

user mode.

Binary translation implements the emulation of an instruction set (the source) by another one (the target) by translating executable binary code (sequences of machine code instructions) [Sites et al., 1993]. VMware applied dynamic binary translation for x86 virtualization [Adams and Agesen, 2006]. Source instruction set is the given x86 ISA, translated to a target ISA that does not have x86’s obstacles to virtualization. The guest is executed by an interpreter instead of directly by a physical CPU and the interpreter correctly intercepts and implements sensitive and non-trapping instructions like popf. The translation replaces these instructions by a sequence of instructions with the intended effect.

Hardware-assisted virtualization enables full virtualization by explicit virtualiza-tion support from the processor (e.g., Intel Virtualizavirtualiza-tion Technology [Uhlig et al., 2005]). Architectural extensions include for example a third privileged mode, re-sulting in different modes for hypervisor (host mode), guest operating system (guest mode), and guest application tasks (user mode). The new data structure virtual machine control block (VMCB) stores control state and the state of a virtual CPU.

The hypervisor specifies within the VMCB under which conditions the guest system is interrupted in order to execute the hypervisor. For example, each execution of the sensitive and non-trapping instruction popf could cause a context switch from guest to host mode. This overcomes x86’s virtualization obstacle, but results in a large overhead. The number of context switches can be reduced by maintaining a guest-specific shadow of the register and including it in the VMCB [Adams and

Age-sen, 2006]. Hardware-assisted virtualization has a great potential to provide efficient virtualization for embedded systems. However, it does not eliminate the challenge to guarantee that the real-time requirements of guest systems are met, which is of major importance for this thesis.

Paravirtualization refers to the porting of the guest OS to an interface provided by the hypervisor, the paravirtualization application programming interface (API) and application binary interface (ABI) [Whitaker et al., 2002, Barham et al., 2003].

The interface is similar but not identical to the ISA. The guest OS is aware of being executed by a hypervisor and uses hypercalls to request hypervisor services (e.g., for memory management or inter-VM communication). A hypercall is a trap from guest OS to the hypervisor, just as a system call is a trap from an application task to the OS. The source code of an OS is modified in order to paravirtualize it and sensitive and non-trapping instructions can be replaced by hypercalls to virtualize an ISA that is not virtualizable by trap-and-emulate.

The major drawback compared to binary translation and hardware-assisted vir-tualization is the lack of transparency. Only ported operating systems can be run. If legal or technical issues preclude the modification of an OS, it is not possible to host it. A specific advantage of paravirtualization for real-time systems is the possibility to schedule in a cooperative manner and according to dynamic policies, which in general requires a passing of scheduling information from guest OS to hypervisor.

A fully virtualized OS cannot cooperate with the hypervisor, since it does not even know that there is a hypervisor running below it.