Virtualization — type 1 and type 2 hypervisors: Visual walkthrough

4.2.40 · D2 · Coding › Operating Systems › Virtualization — type 1 and type 2 hypervisors

Hum parent ke central claim tak pahunchenge:

$T_{overhead} = n_{layers} \cdot δ$

Ab is equation ki chinta mat karo — tumhare paas pieces abhi nahi hain. Chalte hain, inhe earn karte hain.

Step 1 — "The metal" actually hai kya

YUN se shuru kyun karein: har layer jo hum baad mein stack karenge wo metal ke relative define hoti hai. Agar "bottom" kya hai yeh fix nahi kiya, toh "Type 1" aur "Type 2" ke koi mayne nahi — yeh literally is baat ke naam hain ki hypervisor metal se kitna door baitha hai.

PICTURE:

Figure — Virtualization — type 1 and type 2 hypervisors

Neeche grey slab dekho. CPU block mein ek chhoti notch hai jis par privilege pins likha hai — ise yaad rakho, yeh Step 3 mein pura game ban jaata hai.

Step 2 — Kyun ek CPU do kingdoms ko honestly serve nahi kar sakta

YEH kyun matter karta hai: yahi takraav poori wajah hai ki hypervisor exist karta hai. Agar do OSes hardware share kar sakte politely apne aap, toh humein koi naya software nahi chahiye tha. Nahi kar sakte, kyunki dono ko pata hi nahi ki doosra bhi wahan hai.

PICTURE:

Do guest OSes (lavender aur coral boxes) dono ek hi disk ke liye haath badhate hain. Beech mein red clash-mark wo problem hai jo hume solve karni hai. Gaur karo: koi bhi guest "galat" nahi hai — har ek exactly waise behave kar raha hai jaise ek akele OS ko karna chahiye. (Yahi clash hai jo context switching ek OS ke andar processes ke liye solve karta hai — yahan hume yeh ek level upar, poore OSes ke liye chahiye.)

Recall Hum har OS ko "polite raho" kyun nahi bol sakte?

Kyunki ek OS ka pura design yeh maanta hai ki wo akela hai. ::: Har OS ko cooperate karne ke liye rewrite karna compatibility tod dega — parent note ka pura selling point yahi hai. Hume unke neeche ek referee chahiye jo unhe pata bhi na ho.

Step 3 — Privilege rings: CPU khud hi instructions ko danger level se sort karta hai

CPU mein yeh kyun hai: taaki Ring 3 ke ordinary apps machine ko crash na kar sakein. Agar koi app privileged instruction try kare, CPU refuse karta hai aur trap karta hai — app ko rok deta hai aur kernel ke paas jump karta hai decide karne ke liye ki kya karna hai (yeh jump ek trap hai).

PICTURE:

Do concentric rings: andar lavender = Ring 0 (trusted), bahar mint = Ring 3 (untrusted). Coral arrow dikhata hai Ring-3 instruction wall se takraake andar trap ki tarah bounce karti hui.

Step 4 — Trick yeh hai: guest ko demote karo, hypervisor ko Ring 0 mein bithao

YEH pura solution kyun hai: guest sochta hai usne instruction run ki. Actually hypervisor ne use pakda, check kiya, aur believable result fake kiya — phir control wapas de diya. Guest ko kabhi pata nahi chala ki wo akela nahi hai. Ise trap-and-emulate kehte hain.

PICTURE:

Numbered arrows follow karo: (1) guest disable interrupts run karta hai; (2) CPU Ring 0 mein hypervisor ke paas trap karta hai; (3) hypervisor ise sirf is guest ke liye emulate karta hai; (4) control wapas aata hai. Guest ka arrow aur "real" arrow kabhi nahi milte — wo gap hi illusion hai.

Step 5 — Edge case: jab ek dangerous instruction trap karne se mana kar de

YEH sab kuch kyun tod deta hai: agar koi sensitive instruction trap nahi karti, hypervisor ko kabhi call nahi hota, toh wo use emulate nahi kar sakta. Guest silently galat kaam karta hai — illusion toot jaata hai. Yahi woh gap hai jo parent ki Popek & Goldberg condition name karti hai.

PICTURE:

Left path (green): ek well-behaved sensitive instruction — sensitive aur privileged dono, toh trap hoti hai. Right path (red): rogue instruction — sensitive lekin not privileged, toh Ring 0 se slip ho jaati hai aur guest ka view corrupt karti hai. Upar set diagram condition dikhata hai: "sensitive" circle andar honi chahiye "privileged" circle ke.

Step 6 — Layers count karna: jahan do Types alag hote hain

YEH time kyun lagta hai: har layer crossing ek context switch hai — registers save karo, privilege change karo, restore karo (yeh context switch machinery hai). Iska ek fixed toll lagta hai, ise $δ$ kaho.

PICTURE:

Do stacks side by side. Type 1 (left): guest → hypervisor → hardware, 1 crossing marked. Type 2 (right): guest → hypervisor → host OS → hardware, 2 crossings marked. Extra butter-colored slab hi poora difference hai.

Step 7 — Numbers daalna (parent ka Example 3, dekha hua)

$T_{1} = 1 + 1 \cdot 0.2 = 1.2 μ s T_{2} = 1 + 2 \cdot 0.2 = 1.4 μ s$

$T_{1}$ : ek crossing → ek $δ$ add karo.
$T_{2}$ : do crossings → do $δ$ add karo.

Type 2 ka relative slowdown:

$\frac{T _{2} - T _{1}}{T _{1}} = \frac{1.4 - 1.2}{1.2} = \frac{0.2}{1.2} \approx 0.167 = 16.7%$

Numerator $T_{2} - T_{1} = 0.2 μ s$ — us ek extra host-OS layer ki cost.
$T_{1}$ se divide karo — ise Type-1 time ke fraction ke roop mein express karo, yani "kitna slower."

YEH punchline kyun hai: number universal nahi hai (real overhead zyaadatar I/O mein hota hai), lekin shape exact hai — Type 2 ki extra layer ek real, countable toll hai. Step-6 picture ka wo single extra slab hi 16.7% hai.

PICTURE:

Ek bar chart: $t_{h w}$ base (grey) plus $δ$ blocks stacked. Type 2 ka bar exactly ek $δ$ taller hai. Label $16.7%$ gap dikhata hai.

Ek picture mein summary

Sab kuch ek saath: neeche metal, CPU ki ring wall, Ring 0 mein baitha hypervisor, guest ki privileged instruction upar trap hoti hui aur emulate hoti hui, aur — right par — do Types bilkul ek layer ke fark se alag, har ek ke saath $n \cdot δ$ toll.

Recall Feynman: poori walkthrough kisi 12-saal ke bachche ko batao

Computer silicon ka ek tukda hai (Step 1). Ek "boss program" (OS) normally sab kuch apna samajhta hai — lekin ek slab par do boss disk aur memory ke liye ladte hain (Step 2). Acchi baat yeh hai ki CPU pehle se hi instructions ko safe aur dangerous mein sort karta hai, aur agar untrusted code koi dangerous wali try kare toh machine use freeze karke ek trusted referee ko bulati hai (Step 3). Toh hum ek chhota referee — hypervisor — top-trust code ke roop mein install karte hain, aur har boss ko uske neeche demote karte hain. Ab jab koi boss kuch dangerous karne ki koshish kare, CPU referee ko bulata hai, jo sirf us boss ke liye believable jawab fake karta hai, boss ko kabhi pata nahi chalta ki wo share kar raha hai (Step 4). Ek dikkat: kuch purani dangerous instructions freeze trigger nahi karti, toh referee sunता hi nahi — hum use binary translation, paravirtualization, ya hardware guest-mode se patch karte hain (Step 5). Aakhir mein: "hardware ko please touch karo" ki har request ko har software layer se hokar aana-jaana hota hai, har layer par ek chhota toll lagta hai. Type 1 = referee seedha metal par baitha hai → ek toll. Type 2 = referee ek normal OS ke upar app hai → do tolls (Step 6). Parent ke numbers se woh extra toll Type 2 ko yahaan kareeban 16.7% slower banata hai (Step 7). Ek picture, ek kahani: dangerous ko trap karo, result fake karo, aur apni layers gino.

Related: Memory Management (hypervisor har guest ki RAM bhi fake karta hai), Containers vs Virtual Machines (ek lighter isolation zero guest OSes ke saath), Cloud Computing (Type 1 wahi hai jo data centers run karte hain), aur parent Hinglish note Operating Systems ke andar.

Active recall

Hypervisor ko Ring 3 ki jagah Ring 0 mein kyun hona chahiye?

Taaki CPU guest ki privileged instructions ko hypervisor mein trap kare; sirf Ring-0 code ko wo traps milte hain.

Clean trap-and-emulate ke liye instruction set ke baare mein kya sach hona chahiye?

Har sensitive instruction privileged honi chahiye (Popek & Goldberg): sensitive ⊆ privileged.

T = t_{h w} + n \cdot δ

mein, Type 2 ke liye

n

kya hai aur kyun?

n = 2

, kyunki request hardware tak pahunchne se pehle hypervisor aur host OS dono cross karti hai.

Hypervisor pure emulator se faster kyun hai?

Yeh harmless guest instructions seedha real CPU par run karta hai aur sirf dangerous waalon ko trap karta hai, na ki har instruction simulate karta hai.