Virtualization — type 1 and type 2 hypervisors: Exercises

Before we start, one picture ties the whole page together — the layer stack. Everything we grade below is really a question about how many boxes sit between a guest and the silicon. Study it now; almost every solution points back to it.

Figure — Virtualization — type 1 and type 2 hypervisors

Intuition Reading the figure (full text description, no colour needed)

The figure shows two vertical stacks of labelled boxes, drawn side by side. Read each stack top to bottom; the box names are printed inside every box, so you never need to rely on colour.

Left stack — "TYPE 1 (bare-metal)", three boxes:

top box labelled Guest OS (VM)
middle box labelled Hypervisor
bottom box labelled Hardware (metal) A single downward arrow runs from the Guest OS box, through the Hypervisor box, to the Hardware box. Text beside it reads "1 arrow below guest".

Right stack — "TYPE 2 (hosted)", four boxes:

top box labelled Guest OS (VM)
box labelled Hypervisor (app)
box labelled Host OS ← the extra box that Type 1 does not have
bottom box labelled Hardware (metal) Two downward arrows ("crossing 1", "crossing 2") take a request from Guest OS down through Hypervisor, then through Host OS, to Hardware. Text beside it reads "2 arrows below guest (+1 host hop)".

The one idea: the only structural difference is the extra Host OS box in Type 2, which adds exactly one more downward arrow on the path to the hardware. That single extra arrow is the entire performance story of this page.

Level 1 — Recognition

Recall Solution L1.1

ESXi booted the machine itself — it is the base software on the metal. There is no general-purpose host OS underneath it. Answer: Type 1 (bare-metal). ESXi sits on the metal. In the figure this is the left (Type 1) stack: the Hypervisor box sits straight on the Hardware (metal) box, with no Host OS box in between. Count down-arrows below the guest: guest → ESXi → hardware = 1 crossing.

Recall Solution L1.2

Path: Ubuntu guest → VirtualBox hypervisor → Windows 11 host OS → CPU. This is the right (Type 2) stack in the figure — the Host OS box is present. Two down-arrows sit below the guest, so 2 crossings (hypervisor + host OS). Answer: Type 2 (hosted), 2 layers.

Recall Solution L1.3

Type 1 (bare-metal, left stack — no Host OS box): Xen, Hyper-V, VMware ESXi.
Type 2 (hosted, right stack — has a Host OS box): VirtualBox, VMware Workstation, Parallels. The tell: Type 1 names are things you install as the machine's base; Type 2 names are things you double-click inside a desktop OS.

Level 2 — Application

Recall Solution L2.1

KVM is a kernel module that turns the running Linux kernel itself into the hypervisor. The Linux kernel is both the bare-metal OS and the VMM — there is no separate host-OS application layer between the hypervisor and the metal. In figure terms, the Hypervisor box and the (would-be) Host OS box fuse into one box sitting on the metal, giving the left (Type 1) stack shape. So the guest talks to a privileged hypervisor directly. Answer: effectively Type 1 (the classic "hybrid"). Exam-safe phrasing: "Type 1 hybrid — the kernel is the hypervisor."

Recall Solution L2.2

Guest B's I/O path has an extra host-OS hop — the extra Host OS down-arrow in the figure's right stack: B → hypervisor → Windows → hardware, while A's path is A → Hyper-V → hardware. One fewer down-arrow = one fewer crossing = less per-request latency, and I/O is where that overhead concentrates. Answer: Guest A (Hyper-V, Type 1) is faster.

Recall Solution L2.3

They cannot dedicate the whole laptop, and they want convenience over raw speed. Answer: Type 2 (hosted) — e.g. VirtualBox or VMware Workstation Player. It installs like any app on top of Windows (the Host OS box in the figure stays) and coexists with it. This is exactly the dev/test use case.

Level 3 — Analysis

Recall Solution L3.1

Each down-arrow adds $δ$ ; count the down-arrows below the guest in the figure. $T_{1} = t_{h w} + 1 \cdot δ = 1 + 0.2 = 1.2 μ s (1 arrow)$ $T_{2} = t_{h w} + 2 \cdot δ = 1 + 0.4 = 1.4 μ s (2 arrows)$ Why percent-extra and not the raw $0.2 μ s$ gap? The raw gap is meaningless on its own — $0.2 μ s$ is huge next to a $1 μ s$ op but negligible next to a $1 s$ op. The fraction $\frac{T _{2} - T _{1}}{T _{1}}$ normalises the extra cost against the work you were going to pay anyway, so it answers the physically meaningful question: "per unit of Type 1 time, how much more does Type 2 charge?" — a scale-free number you can compare across workloads. $\frac{T _{2} - T _{1}}{T _{1}} = \frac{1.4 - 1.2}{1.2} = \frac{0.2}{1.2} \approx 0.1667 = 16.67%$ Type 2 is ≈ 16.7% slower on this modelled op. The extra 0.2 μs is literally the price of the one extra Host OS down-arrow in the figure — that is the whole story.

Recall Solution L3.2

Here $n$ counts exactly the down-arrows below the guest — the same crossings we defined at the top of the page. One arrow per crossing, so $n$ crossings cost $n δ$ : $T (n) = t_{h w} + n δ$ Extra fraction of Type 2 ( $n = 2$ ) over Type 1 ( $n = 1$ ):

=\frac{\delta}{t_{hw}+\delta}$$ As $\delta \to \infty$, $f \to 1$, i.e. **100\%**. Physically: when crossing an arrow costs far more than the actual hardware work in the *Hardware* box, that one extra *Host OS* arrow *doubles* the time — Type 2 becomes twice as slow. **This is why I/O-heavy, crossing-dominated workloads punish Type 2 hardest** (I/O forces many trips down and back up the whole stack).

Recall Solution L3.3

Hypervisor (trap-and-emulate): $T_{h y p} = 999000 \cdot 1 ns + 1000 \cdot 500 ns = 999000 + 500000 = 1, 499, 000 ns$ Pure emulator: $T_{e m u} = 1000000 \cdot 500 ns = 500, 000, 000 ns$ Ratio $= \frac{500 , 000 , 000}{1 , 499 , 000} \approx 333.6 \times$ . A hypervisor here is ≈ 334× faster than a pure emulator, because it runs the 99.9% of safe instructions directly on the metal and only traps the rare privileged ones. That is the whole point of "trap-and-emulate."

Level 4 — Synthesis

Definition Two instruction

kinds for L4 (Popek & Goldberg, 1974), plus their rule The two kinds of instruction you must name are:

Privileged instruction — an instruction that traps (hands control up to the supervisor) whenever it runs outside kernel mode. In figure terms, running it from a demoted guest box forces an up-arrow into the hypervisor. Example: writing the page-table base register.
Sensitive instruction — an instruction that reads or changes machine state (interrupt flags, real vs virtual mode, etc.) — the kind the hypervisor must intercept to keep the illusion consistent.

The rule that ties the two kinds together (this is a rule, not a third kind of instruction): trap-and-emulate works cleanly iff every sensitive instruction is also privileged (so it always traps up). The danger case is a sensitive instruction that is not privileged — it changes state but never traps, so the hypervisor never sees it.

Recall Solution L4.1

(a) What breaks: the guest kernel is demoted to a less-privileged ring (see CPU Privilege Rings). POPF is sensitive (it quietly reads/writes the interrupt flag) but not privileged, so it does not trap — no up-arrow fires; it just silently does the wrong thing. This violates the Popek & Goldberg rule "every sensitive instruction must be privileged," so the hypervisor never gets an up-arrow to intercept, and the guest's view of machine state is corrupted. (b) The three fixes:

Binary translation — the hypervisor rewrites bad instruction sequences on the fly (early VMware). Who changes: the hypervisor's execution engine.
Paravirtualization — the guest OS is modified to call the hypervisor explicitly via "hypercalls" instead of running the naughty instruction (Xen). Who changes: the guest.
Hardware-assisted (Intel VT-x / AMD-V) — the CPU adds a real guest mode so even nasty instructions trap cleanly. Who changes: the silicon. This is the modern default.

Recall Solution L4.2

(i) Cloud provider → Type 1 (e.g. VMware ESXi, Xen, or KVM). Strongest reason: performance + smaller security surface — no host-OS down-arrow on the hot path (left stack), and a thin hypervisor is a smaller trusted computing base to defend across thousands of tenants. See Cloud Computing. (ii) Solo developer → Type 2 (e.g. VirtualBox or VMware Workstation). Strongest reason: convenience — the developer's laptop already runs a primary desktop OS they cannot wipe, and a Type 2 hypervisor installs as an ordinary app on top of it (the Host OS box in the right stack stays). Under VT-x/AMD-V the CPU-bound testing runs near-native speed, so the only real cost — a little extra I/O overhead from that one added down-arrow — is irrelevant for dev/test. Being able to snapshot and reset three guest OSes in seconds, without leaving their familiar desktop, matters far more here than raw throughput.

Recall Solution L4.3

Containers. A VM ships a whole guest OS per instance (a Guest OS box plus its own kernel) — 200 kernels' worth of RAM and boot cost. Containers share the single host kernel and isolate only user space, so 200 of them are far lighter. Since all services accept the same kernel, the isolation trade-off is acceptable. See Containers vs Virtual Machines. (If services needed different kernels or stronger isolation, VMs win.)

Level 5 — Mastery

Recall Solution L5.1

Per-op saving of Type 1 over Type 2 is $(t_{h w} + 2 δ) - (t_{h w} + δ) = δ$ (exactly one extra arrow). Over $P$ ops, Type 1 saves $P δ$ seconds of runtime, but Type 2 saved $S$ seconds of setup. Break-even is where the runtime saving equals the setup saving: $P_{b e} δ = S ⟹ P_{b e} = \frac{S}{δ}$ $P_{b e} = \frac{600}{2 \times 1 0 ^{- 7}} = 3 \times 1 0^{9} privileged ops$ Interpretation: below 3 billion privileged ops, the one-time 600 s setup saving of Type 2 dominates → just use Type 2. Above it, Type 1's per-op speed pays back the setup cost → go bare-metal. This is the quantitative heart of "Type 2 for dev, Type 1 for production."

Recall Solution L5.2

Lower bound $f (δ) \geq 0$ . The numerator is $δ \geq 0$ by assumption. The denominator is $t_{h w} + δ$ , a sum of $t_{h w} > 0$ and $δ \geq 0$ , so it is $> 0$ . A non-negative number divided by a positive number is $\geq 0$ . Hence $f (δ) \geq 0$ . ∎

Upper bound $f (δ) < 1$ . Consider the gap

= \frac{t_{hw}}{t_{hw}+\delta}.$$ The numerator $t_{hw}>0$ and the denominator $t_{hw}+\delta>0$, so $1-f(\delta) > 0$, i.e. $f(\delta) < 1$. ∎ Combining: $0 \le f(\delta) < 1$ for all $\delta\ge 0,\ t_{hw}>0$. Since $f<1$ means the extra time is less than $100\%$ of $T_1$, **Type 2 is never more than twice Type 1's time** in this model. **The two limiting cases:** - $\delta \to 0$ (free crossings): $f \to 0$ — Type 1 and Type 2 **tie**. This models CPU-bound work under VT-x/AMD-V where a guest instruction barely crosses arrows and runs near-native. - $\delta \to \infty$ (crossing dwarfs hardware work): $f \to 1$ — Type 2 approaches (but never reaches) **twice** the time. This models pathological I/O where each request pays the full extra *Host OS* down-arrow. These bracket every real case in between.

Recall Solution L5.3

The CPU has privilege rings (CPU Privilege Rings); the hypervisor sits in the most privileged mode and demotes each guest kernel below it. When a demoted guest runs a privileged instruction, the CPU traps up (System Calls and Traps) into the hypervisor, which emulates the effect — this "trap-and-emulate" is the shared engine behind both Type 1 and Type 2. The difference is only the layer count (down-arrows in the figure) on the way to hardware: Type 1's guest crosses one down-arrow to reach the metal, while Type 2's guest crosses two (hypervisor + host OS), so every privileged trap and every I/O in Type 2 pays one extra hop — which is exactly the overhead we quantified above.

Recall One-line self-test before you leave

Ask of any setup: "What booted the metal, and how many down-arrows does a guest cross to reach the CPU?" One down-arrow and no host OS → Type 1. Two down-arrows, with a full host OS below → Type 2.