Summary

We have described some key low-level mechanisms to implement CPU virtualization, a set of techniques that we collectively refer to as limited direct execution. The basic idea is straightforward: just run the program you want to run on the CPU, but first, make sure to set up the hardware so as to limit what the process can do without OS assistance.

ASIDE: HOW LONG CONTEXT SWITCHES TAKE

A natural question you might have is: how long does something like a context switch take? Or even a system call? For those of you that are curious, there is a tool called lmbench“lmbench: Portable tools for performance analysis” by Larry McVoy and Carl Staelin. USENIX Annual Technical Conference, January 1996. A fun paper about how to measure a number of different things about your OS and its performance. Download lmbench and give it a try. that measures exactly those things, as well as a few other performance measures that might be relevant. Results have improved quite a bit over time, roughly tracking processor performance. For example, in 1996 running Linux 1.3.37 on a 200-MHz P6 CPU, system calls took roughly 4 microseconds and a context switch roughly 6 microseconds“lmbench: Portable tools for performance analysis” by Larry McVoy and Carl Staelin. USENIX Annual Technical Conference, January 1996. A fun paper about how to measure a number of different things about your OS and its performance. Download lmbench and give it a try.. Modern systems perform almost an order of magnitude better, with sub-microsecond results on systems with 2- or 3-GHz processors. It should be noted that not all operating-system actions track CPU performance. As Ousterhout observed, many OS operations are memory intensive, and memory bandwidth has not improved as dramatically as processor speed over time“Why Aren’t Operating Systems Getting Faster as Fast as Hardware?” by J. Ousterhout. USENIX Summer Conference, June 1990. A classic paper on the nature of operating system performance.. Thus, depending on your workload, buying the latest and greatest processor may not speed up your OS as much as you might hope.

This general approach is taken in real life as well. For example, those of you who have children, or, at least, have heard of children, may be familiar with the concept of baby proofing a room: locking cabinets containing dangerous stuff and covering electrical sockets. When the room is thus readied, you can let your baby roam freely, secure in the knowledge that the most dangerous aspects of the room have been restricted.

In an analogous manner, the OS “baby proofs” the CPU, by first (during boot time) setting up the trap handlers and starting an interrupt timer, and then by only running processes in a restricted mode. By doing so, the OS can feel quite assured that processes can run efficiently, only requiring OS intervention to perform privileged operations or when they have monopolized the CPU for too long and thus need to be switched out.

We thus have the basic mechanisms for virtualizing the CPU in place. But a major question is left unanswered: which process should we run at a given time? It is this question that the scheduler must answer, and thus the next topic of our study.

ASIDE: KEY CPU VIRTUALIZATION TERMS (MECHANISMS)

• The CPU should support at least two modes of execution: a restricted user mode and a privileged (non-restricted) kernel mode.

• Typical user applications run in user mode, and use a system call to trap into the kernel to request operating system services.

• The trap instruction saves the register state carefully, changes the hardware status to kernel mode, and jumps into the OS to a pre-specified destination: the trap table.

• When the OS finishes servicing a system call, it returns to the user program via another special return-from-trap instruction, which reduces privilege and returns control to the instruction after the trap that jumped into the OS.

• The trap tables must be set up by the OS at boot time, and make sure that they cannot be readily modified by user programs. All of this is part of the limited direct execution protocol which runs programs efficiently but without loss of OS control.

• Once a program is running, the OS must use hardware mechanisms to ensure the user program does not run forever, namely the timer interrupt. This approach is a non-cooperative approach to CPU scheduling.

• Sometimes the OS, during a timer interrupt or system call, might wish to switch from running the current process to a different one, a low-level technique known as a context switch.