Limited Direct Execution

• Virtualization through CPU time sharing methods. Need to overcome/consider:
  • Performance: Virtualization without giving too much of overhead.
  • Control: Efficient execution of process with control over CPU.

Basic Concept: Limited Direct Execution

• Direct Execution:
  • Just execute the program on CPU.
  • OS creates process object in the process list when execute.
  • Alloscate the memory, load it on a disk, branch to magin point to run the code.

Above figure shows no limited direct execution.
It creates several problems:

1. How can ensure it does not execute the program that OS does not want?
2. How can we stop the execution and switch to the other process during the execution?
   --> How can we implement Time Sharing Method?

This is why we need “Limited” Direct Execution.

Problem 1 : Limited Execution

What if the program requires to executr privileged instructions such as IO/additional memory allocation? –> Introduce two different modes

• User Mode: Limited access such as no request for IO.
• Kernel Mode: Non limited access

To allow privileged instructions, modern OS provides systemcall to user process.

• Filesystem access, process creationa and deletion, communication and allocation…

To call systemcall, a program needs to execute trap command.

• It elevates the the privilege level from user to Kernel when the instruction branches to the kernel.
• Once elevated to the kernel mode, OS can execute every instructions, and can handle all the requested instructions by the process.
• Once completed, OS calls “return-from-trap” which de-elevates the privilege down to user mode.

When calls the trap command, hardware needs to store necessary register of the process.
It is to return properly to the user process when “return-from-trap” is executed.

* x86 has PC, flags, and other registers are stored in kernel stack of each process.
* "return-from-trap" pops these info to re-run the user mode process (from sleep).

A process cannot state the “branch address” where “trap” gets executed as it means the process has access to the kernel.

• Kernel creates trap table during the boot, and controls the system with it.
• Booting is instructed within kernel mode, hence hardware can be managed as wanted.

OS uses privileged instructions to deliver the trap handler location to the hardwares.
Trap Handler: When some interruptors, or systemcalls happen, which code hardware should execute?

In the booting:

1. Kernel creates/resets trap table
2. OS lets hardware knows the location of trap handler. 

After the boot:

1. User calls trap to OS
2. Hardware saves the stack and branch to trap handler.
3. Kernel handles the trap, branch back to hardware.
4. Restore the registers from kernel stack, branch to user program.
5. User program moves on.

Problem 2: Process Switch

How OS gets CPU back to switch the process?

A Cooperative Approach: Wait For System Calls

• OS assumes that process will behave reasonably; process gives up CPU periodically so that other processes get the chance.
• Process often calls systemcall to handover the control of CPU to OS such as while reading files… –> yield systemcall.
• If the application behaves abnormal –> it triggers trap –> OS gets CPU control.

A Non-Cooperative Approach: The OS Takes Control

Timer Interrupt - trigs the interrupt periodically and executes the interrupt handler.
OS needs to decide whether to proceed the current process or do the switch; decision is made by sheduler policy.

• Context Save and Store
  • OS saves the current state of the process in the kernel stack, and restore the stack of the next process.
  • By doing so, return-from-trap returns to the next process (not the current process).
  • Once the next process (current) calls return-from-trap, it calls the previous process to proceed where it stopped.

ASIDE: KEY CPU VIRTUALIZATION TERMS (MECHANISMS)

• The CPU should support at least two modes of execution: a restricted user mode and a privileged (non-restricted) kernel mode.
• Typical user applications run in user mode, and use a system call to trap into the kernel to request operating system services.
• The trap instruction saves register state carefully, changes the hardware status to kernel mode, and jumps into the OS to a pre-specified destination: the trap table.
• When the OS finishes servicing a system call, it returns to the user program via another specialreturn-from-trap instruction, which reduces privilege and returns control to the instruction after the trap that jumped into the OS.
• The trap tables must be set up by the OS at boot time, and make sure that they cannot be readily modified by user programs. All of this is part of the limited direct execution protocol which runs programs efficiently but without loss of OS control.
• Once a program is running, the OS must use hardware mechanisms to ensure the user program does not run forever, namely the timer interrupt. This approach is a non-cooperative approach to CPU scheduling.
• Sometimes the OS, during a timer interrupt or system call, might wish to switch from running the current process to a different one, a low-level technique known as a context switch