![]() The OS could now run processes directly on hardware and still prevent them from misusing CPU time. The OS could configure the CPU to interrupt the active process at set intervals, allowing it to take control of scheduling and switch between processes. Next came virtualized "time", as it were. This means the OS can check if the process has permission before performing the action. This prevents processes from reading/writing directly to the harddrive, and instead forces them to ask the OS to read/write for them. ![]() An example is the ability to read/write data to hardware. These regions are occupied by the OS, allowing it to act as a gateway to to these privileged actions. If the OS wanted to have any sort of control over a process, it had to run the process in an emulator (nobody did, because it was too painfully slow).įirst was Privileged Memory: certain actions that can only be performed by special regions of memory. Processes all shared the same memory space, all had full access to hardware, and the ability to multi-task was entirely dependent upon one process stopping itself and giving control to the next process. (No guarantees that this is in correct order or is exhaustive, but should give a good starting overview) To add a bit of perspective, this is just one more step in a long history of virtualization and control. As long as the guest doesn't try to go outside of the virtualized boundaries, then the Host OS may not have any code running if it has nothing to do at a given point in time. The example above is extremely simplified, but memory, disk i/o, and even networking can be controlled on the latest of today's processors, allowing them to be interfaced safely without having to bother the host OS each time. With virtualization, the host OS configure limitations into the CPU, and then actually runs the guest code on the physical CPU. The key difference here is in an emulator, the guest OS is never actually running on the hardware. Host CPU saves all host registers and state, restores guest registers and state, and then starts executing Guest OS code Host OS: Oh, well give them this: File from virtual hard drive Host CPU: Hey Host OS, the Guest wanted this file! Host CPU saves all guest registers and state, and then restores all host registers and state Guest OS: I'm alive! Hey CPU, can you get me this file? Host CPU saves all host registers and state, and then starts executing Guest OS code ![]() Call me if it wants to do something that isn't just executing instructions. Host OS: Hey CPU, I need you to run this code virtualized. Here's a simplified example of the process: If the guest tries to do something with the real hardware that violates the rules (such as trying to access a disk device), the hardware will suspend the guest and send the host an interrupt, which allows the host to provide a response (such as returning data from an emulated disk device), and then resume the guest. This allows the host OS to set up rules about what the guest can and cannot do, and then actually run the guest on real hardware. Virtualization as you describe it is implemented in the hardware by allowing certain rules and restrictions to be applied at a hardware level, which can be managed by the host OS. If you tried to run it on the real CPU, you had no guarantee that it would hand control back to the host OS. Originally, you couldn't let the guest OS use real hardware because you had no way to control it.
0 Comments
Leave a Reply. |