Heptabase Notes

Question: How to efficiently virtualize the CPU with control?

In the previous chapter, we learned about the many APIs available to processes. In this chapter, we will discuss how we execute processes on the CPU.

Direct execution protocol #

Directly running processes on the CPU is the most efficient method. This approach is commonly seen in embedded systems.

However, this can lead to two potential issues:

1. What if I want to protect certain operations? For example, preventing a process from directly performing I/O writes to files, as malicious programs could read and write at will.
2. What if a process continuously occupies the CPU?

Limited direct execution protocol #

To address the first issue mentioned above, the operating system has developed two mechanisms:

Processor modes #

1. user mode
   • Regular programs run in user mode, which has limited permissions and cannot perform all operations.
2. kernel mode
   • Used by the operating system

Because of Processor mode, when a process needs to perform a system call, it must go through the operating system (return to kernel mode) to execute.

This way, we can ensure that processes operate resources under controlled conditions.

trap instruction, trap table, trap handler #

We can simply understand these three things as:

• trap handler: a program (e.g., for rebooting)
• trap table: records the relationship between trap instruction and trap handler; for example, sd -> reboot
• trap instruction: a specific instruction, for example, sd.

The trap table and trap handler are initialized when the computer boots up and inform the CPU where these instructions are located.

How to perform restricted operations? #

When a process needs to perform system-level operations (e.g., I/O):

1. Save the process state
2. Switch processor mode (user mode -> kernel mode)
3. Execute the system call
4. Restore the process state
5. Return to the process and continue execution
6. Release resources

How does the operating system regain control? #

Cooperative mode #

In early operating systems, we trusted that each process would timely return control to the operating system.

However, this is clearly not a reliable method.

Timer interrupt #

We can think of it as having a small clock in our computer that notifies the CPU to pause every so often (e.g., 1 ms).

When the CPU is interrupted, it returns control to the operating system, which can then decide whether to switch to another process.

The decision whether or not to execute another process is called Scheduler, and this transition process is called context-switch.

We will start discussing Scheduler and context-switch in detail in the next chapter.