Information Technology Reference
In-Depth Information
The guest operating system loads a process from the virtual disk into
memory.
To start a process, the guest operating system issues instructions to resume
execution at user-level, e.g., using
reti
on the x86. As changing the
privilege level is a privileged operation, this instruction will trap into the
host operating system kernel.
The host operating system simulates the requested mode switch as if the
processor had directly executed it, restoring the program counter, stack
pointer, and processor status word exactly as the guest operating system
had intended. Note that the host operating system needs to protect itself
from bugs in the guest operating system, and so it also needs to check
the validity of the mode switch | e.g., that the guest operating system
is not surreptitiously attempting to get the host kernel to \switch" to an
arbitrary point in the kernel code.
Next, consider what happens when the guest user process does a system
call, illustrated in Figure 2.18. To the hardware, there is only one kernel, the
host operating system. Thus, the trap instruction will trap into the host kernel's
system call handler. Of course, the system call was not for the host! Rather, the
host kernel simulates what would have happened had the system call instruction
occurred on real hardware running the guest operating system:
The host kernel saves the instruction counter, processor status register,
and user stack pointer in the exception stack of the guest operating system.
The host kernel transfers control to the guest kernel at the beginning of
the interrupt handler, but with the guest kernel running with user-mode
privilege.
The guest kernel performs the system call.
When the guest kernel attempts to return from the system call back to
user-level, this will cause a privilege exception, dropping back into the
host operating system kernel.
The host kernel can then restore the state of the user process, running at
user level, as if the guest operating system had been able to return there
directly.
Exceptions are handled similarly, with one caveat. Some exceptions gener-
ated by the virtual machine are due to the user process; these are forwarded
to the guest kernel for handling. Other exceptions are generated by the guest
kernel itself (e.g., when it tries to execute privileged instructions); these must
be handled by the host kernel.
Thus, the host kernel needs to keep track of
