Building Blocks

Building Blocks

Trap-and-Emulate

• Problem with VMM is that, guest OS expects to have unrestricted access to hardware, runs privileged instructions, unlike user processes. But one guest cannot Man get access, must be isolated from other guests.

• All CPUs have multiple privilege levels. There is ring 0,1,2,3 in x86 CPUs. Normally, user process in ring 3, OS in ring 0. Privileged instructions only run in vino ring 0. Now, user process in ring 3, VMM/host OS in ring 0. So guest OS must be protected from guest apps. But not fully privileged like host OS/VMM. It is run in ring 1.

• Trap and emulate VMM: Guest OS runs at lower privilege level than VMM, traps to VMM for privileged operation.

• When the kernel in the guest attempts to execute a privileged instruction, that is an error because the system is in user mode and causes a trap to the VMM in the real machine. The VMM gains control and executes the action that was attempted by the guest kernel on the part of the guest. It then returns control to the virtual machine. This is called the trap-and-emulate method.

• Fig. 7.3.1 shows trap-and-emulate method.

• All non-privileged instructions run natively on the hardware, providing the same To U performance for guests as native applications. Privileged instructions create extra overhead, however, causing the guest to run more slowly than it would natively.

• In addition, the CPU is being multi-programmed among many virtual machines, which can further slow down the virtual machines in unpredictable ways.

• Any privileged action by guest OS traps to VMM, emulated by VMM. Example: set IDT, set CR3, access hardware. Sensitive data structures like IDT must be managed by VMM, not guest OS.

• Problems with trap and emulate,

1) Guest OS may realize it is running at lower privilege level.

2) Some x86 instructions which change hardware state, run in both privileged and

• These problems occurs because OSes not developed to run at a lower privilege level and instruction set architecture of x86 is not easily virtualizable.

Binary Translation

• Binary translation could be static or dynamic. Static binary translation means using ewoll a processor to translate an image from an architecture to another before execution. In dynamic binary translation individual instructions or groups of instructions are on the fly translated and the translation is cached to allow for reuse in iterations without repeated translation.

• To be more precise, a segment of the original code is first executed in an interpreted mode and collected as a segment. It is determined if the code has been execute at least N times, if so, if not already translated it is translated and it is executed and from now the translated code will be executed.

• In binary translation the virtualization layer sits at CPU privilege level 0 (most privileged). The guest O/S system were supposed to run on level 0, but since virtual layer occupies that level, it moves guest O/S execution at privilege level 1 and leaves user applications at level 3 as it supposed to be.

• The non-virtualizable kernel code of the guest O/S is translated by virtual layer into new sequences of instructions that have the intended effect on virtual hardware, while user level code is directly executed on the CPU for high performance. The benefit of this approach is that the O/S is fully abstracted from the underlying hardware thus it doesn't require any modification.

Hardware Assisted

• In hardware assisted virtualization the virtual layer sits in a new root mode privilege level under level 0. Guest O/S privileged and sensitive calls are set to sibo auto trap to the hypervisor while user request are executed directly to the CPU for high performance.

• Hardware assisted virtualization requires a compatible CPU like Intel VT-x and AMD's AMD-V to work.

• This technique is not performing as expected because of the high overhead between guests O/S-to-hypervisor transition.