Modern CPUs have a built-in security model to protect the operating system from misbehaving applications. This model is often visualised as a series of concentric circles, called protection rings. The innermost ring has the highest privilege, and the outermost has the least. On the popular x86 architecture, there are four rings, but most operating systems like Windows and Linux only use two of them.

Ring 0 (Kernel Mode): This is the most trusted level. The operating system kernel lives here. It has direct access to all hardware, memory, and CPU instructions. It's the absolute boss.

Ring 3 (User Mode): This is where your applications run, like your web browser or a video game. They have limited privileges and cannot directly access hardware. If an application needs something from the hardware, like reading a file from the disk, it must ask the kernel by making a 'system call'.

Now, let's consider virtualisation. A guest operating system expects to run in Ring 0. It believes it's the boss of the machine. But in a virtualised environment, the hypervisor (or Virtual Machine Monitor) is the real boss, occupying Ring 0.

So how can a guest OS, which needs to execute sensitive, Ring 0 commands, run without having direct Ring 0 access? If we just put the guest OS in Ring 3, it would crash the moment it tried to do anything important.

The solution is a clever technique managed by the Virtual Machine Monitor (VMM). The guest OS is placed in a less privileged ring (typically Ring 1, or sometimes Ring 3), and the VMM orchestrates a process of interception and simulation.

The core mechanism that makes this work is called trap-and-emulate. It's a two-step dance between the CPU and the VMM.

1. Trap: When the guest OS attempts to execute a privileged instruction (one that can only run in Ring 0), the CPU doesn't execute it. Instead, because the guest isn't actually in Ring 0, the CPU hardware generates a 'trap' or 'fault'. This immediately halts the guest OS and transfers control to the VMM.

2. Emulate: The VMM inspects the instruction that caused the trap. It figures out what the guest OS was trying to do (e.g., access a specific piece of hardware). The VMM then performs the action on the guest's behalf, but in a safe, controlled way. It emulates the effect of the instruction on the virtual hardware. Once finished, it returns control to the guest OS, which continues on, completely unaware that anything unusual happened.

This process ensures the guest OS can function correctly without ever getting the dangerous, direct hardware access that Ring 0 provides. The VMM acts as a strict but fair intermediary, fulfilling the guest's requests while maintaining total control over the physical machine.

This trap-and-emulate model is foundational to both Type 1 (bare-metal) and Type 2 (hosted) hypervisors, as the architectural challenge of managing Ring 0 access is the same in both cases.

Time to check your understanding of these core concepts.

Understanding how the CPU and VMM work together to manage privilege levels is key to seeing how an entire guest operating system can run as just another process on a host.