162 / 163 · C11 · 8 min
Virtual Machines
A virtual machine monitor inserts a transparent abstraction layer between hardware and operating systems so multiple guest OSes can run concurrently, each believing it owns the machine. This appendix covers historical background, contemporary uses, and key mechanisms for CPU virtualization.
In this lesson
Building Another Illusion Beneath the OS
Operating systems already trick applications into believing they possess a private CPU and vast virtual memory. The virtual machine monitor must repeat the same trick for operating systems: every guest OS thinks it directly owns the physical hardware while the monitor secretly multiplexes the real resources. The monitor acts as an OS for operating systems yet must stay completely transparent so guest code needs no modification.
Why Virtualization Became Popular Again
Many servers run different operating systems or versions yet sit mostly idle. Virtualization consolidates those workloads onto fewer physical machines, reducing cost and administrative effort. Desktop users run several OSes on one machine to access native applications. Developers test software behavior across many OS versions using only a single piece of hardware.
Virtualizing the CPU with Limited Direct Execution
To start a guest OS the monitor simply jumps to its first instruction. Switching among virtual machines requires saving the complete machine state—ordinary registers, program counter, and all privileged hardware state—then restoring the target VM. Most ordinary instructions execute directly on the real CPU; only privileged operations are intercepted.
Intercepting Privileged Instructions and System Calls
Any attempt by a guest OS or application to execute a privileged instruction traps into the monitor. During guest boot the monitor records the location of the guest’s trap handlers. When a user process issues a system call the trap arrives first at the VMM, which then transfers control to the guest handler. The guest’s return-from-trap instruction likewise traps again, allowing the VMM to finish the genuine mode switch.
Pitfalls
- Believing a guest OS can execute privileged instructions without the monitor intercepting them
- Omitting privileged hardware state when switching VMs, causing incorrect restoration
Run an example
This chapter is taught from the official PDF; there is no extra runnable program on this page.
CHECK YOUR UNDERSTANDING
Close the answer. Explain it.
When a process running on a guest OS issues a system call, how does the VMM let the call complete correctly while retaining control of the hardware?
Show a reference answer
The hardware trap first enters the monitor because it installed the real trap handler. The monitor then transfers control to the previously recorded guest OS trap handler. When the guest finishes and executes a return instruction, that instruction traps again into the monitor, which then performs the genuine return to user mode.
Check the sources
Drafts and official chapters change. The version mark is only the example’s minimum.