Mechanism: Limited Direct Execution

Time sharing/multi-programming.

Operating system starts on CPU, gives control to user process and then back the control.

What if user process does not gives control back to OS?

Hardware and OS support needed.

Basic technique:
>Just run directly on CPU

Library: Calls other program.

Problem:

Restricted operation:

1-I/O request to the DISK

2- Gaining resources such as CPU or memory

Process has full access to CPU, so we put some restrictions.

Let process do whatever it want:

Security issues.

Solution:
protected control transfer.
1- User mode: Application full/direct access

2- Kernel mode: Full resources of machine.

When user modes wants to access privilege like I/O:

it goes to kernal mode.
returns back to the user mode back again.

A "trap" instruction is used to transition from user mode to kernel mode

typical cases in which a trap instruction:

1. System Call: When a user-level program needs a service or

operation provided by the operating system (such as reading
from a file, allocating memory, or creating a new process), it
issues a system call. The trap instruction is used to transition from
user mode to kernel mode, allowing the OS to execute the
requested service on behalf of the user-level program. After the
service is executed, the control is returned to the user
program in user mode.
2. Exception Handling: Trap instructions can also be used to handle
exceptional conditions that occur during program execution, such
as division by zero, invalid memory access, or other
hardware-related errors. When such an exception occurs, the
trap instruction is executed to transfer control to the appropriate
exception handler in the kernel.
Hardware Interrupts: In some systems, hardware devices like timers, keyboards, or disk
controllers can generate hardware interrupts. When a hardware interrupt occurs, it can trigger the
execution of a trap instruction to transfer control to an interrupt handler routine in the kernel,
allowing the OS to respond to the interrupt.

In all of these cases, the trap instruction is executed to switch from user mode to kernel mode,
where the operating system has higher privileges and can perform tasks that are not allowed in
user mode.

System call:

Jump to Kernel mode.

Raise privilege to kernal mode.

Save old PC, register to kernal stack.

Switch to kernal stack( KERNAL does not trust the address of user stack)

Kernel does not trust user provided address, hence creates IDT: interrupt descriptor table at bot.

IDT has addresses of kernel functions to

run for system calls and other events

Return from trap instructions

Restore context of CPU registers from kernel stack

Change CPU privilege from kernel mode to user mode

Restore PC and jump to user code after trap

Incase of using trap:

Across all cases, the mechanism is: save context on kernel stack and switch to OS address in ID

IDT has many entries: which to use?

System calls/interrupts store a number in a CPU register before calling trap, to identify which IDT
entry to use
System calls/interrupts store a number in a
CPU register before calling trap, to identify
which IDT entry to use

When returning back:

User process unaware that it was suspended, resumes execution as always

Must you always return to the same user process from kernel mode? No

Before returning to user mode, OS checks if it must switch to another process

 The OS scheduler

The terms "preemptive" and "non-preemptive" refer to different scheduling strategies used by
operating systems to manage the allocation of the CPU's processing time to various tasks or
processes.

**Non-Preemptive (Cooperative) Schedulers:**

1. **Polite and Cooperative**: they rely on processes to voluntarily yield control of the CPU.
Processes are expected to cooperate and give up the CPU when they are in a state where they can do
so without causing problems.

2. **Switch Only on Blocking or Termination**: In non-preemptive scheduling, a process will

continue running until it either explicitly requests to be blocked (e.g., through a system call or I/O
operation) or it terminates (finishes its execution). The scheduler does not forcibly interrupt a
running process.

**Preemptive (Non-Cooperative) Schedulers:**

1. **Can Switch Even if Process Is Ready**: Preemptive schedulers have the authority to interrupt a
running process, even if that process is ready to continue executing. This means that a higher-priority
process can interrupt a lower-priority one, regardless of whether the lower-priority process is willing
to yield the CPU.

2. **Periodic Timer Interrupts**: To implement preemptive scheduling, the CPU generates periodic
timer interrupts. These interrupts occur at regular intervals and are handled by the operating
system's scheduler. When a timer interrupt occurs, it interrupts the currently executing process and
gives the scheduler an opportunity to decide whether to switch to a different process.

3. **Checking for Long Running Processes**: After servicing a timer interrupt, the operating system
checks whether the currently running process has been running for too long. If it has exceeded its
allocated time quantum (a predetermined time slice for execution), the scheduler may decide to
preempt it and switch to another process. This helps prevent any single process from monopolizing
the CPU's time.
In summary, non-preemptive (cooperative) schedulers rely on processes to cooperate and switch
control explicitly, typically only doing so when a process blocks or terminates. Preemptive (non-
cooperative) schedulers, on the other hand, can forcibly switch between processes, even when a
process is ready to continue, and they use timer interrupts to periodically check and potentially
preempt long-running processes to ensure fairness and responsiveness in multitasking
environments.

**Context Switch from Process A to Process B:**

- Process A moved from has user mode to kernel mode.

- The operating system (OS) decides that it must switch from executing process A to process B.

- The OS saves the context of process A, which includes the program counter (PC), registers, and the,
onto the kernel kernel stack pointer stack designated for process A.

- The stack pointer (SP) is switched to the kernel stack designated for process B.

- The OS restores the saved context from process B's kernel stack, including its PC and registers,
effectively loading the state of process B.

- At this point, the CPU is running process B in kernel mode.

- To eventually return to user mode for process B, the CPU executes a "return-from-trap" instruction
or a similar mechanism, which is handled by the OS.

, the switching of processes typically occurs within the kernel

mode of the operating system

Within the kernel mode, the operating system performs the necessary
tasks for context switching between processes, which includes saving
the state of the currently executing process, loading the state of
the next process to run, and updating the processor's state (e.g.,
stack pointer and program counter) accordingly.

So, the actual process switching, where the context of one process is
saved, and the context of another process is loaded, takes place while the
CPU is executing in kernel mode. This ensures that the operating system
has the necessary privileges to manage and control the process switching,
as well as to maintain the integrity of each process's data and execution
state.
Two times when data is saved in kernal stack:

Trap handling in xv6

The following events cause a user process to “trap” into the kernel (xv6 refers to all these events as
traps)

System calls (requests by user for OS services)

Interrupts (external device wants attention)
Program fault (illegal action by program)
When above events happen, CPU executes the special “int” instruction

For hardware interrupts, device sends a signal to CPU, and CPU

executes int instruction
Trap instruction has a parameter (int n), indicating type of interrupt

E.g., syscall has a different value of n from keyboard interrupt.

  Before trap: eip(INSTRCUTION POINTER)
pointing to user program instruction, esp to
user stack. Suppose interrupt occurs now
 The following steps are performed by CPU as
part of “int n” instruction
o Fetch n-th entry interrupt descriptor table (CPU knows
memory address of IDT)
o Save stack pointer (esp) to internal register
o Switch esp to kernel stack of process (CPU knows
location of kernel stack of current process)
o On kernel stack, save old esp, eip (where execution
stopped before interrupt occurred, so that it can be
resumed later)
o Load new eip from IDT, points to kernel trap handler
 Result: ready to run kernel trap handler code,
on kernel stack of process

BEFORE INT:

ESP SWITCHES FROM THE USER STACK TO KERNEL STACK.

\\
Before the int n instruction starts, the kernal stack has some already pushed data

\
No matter what the value of int n is, the esp will point to alltraps code.

What does alltraps do:

push all reigsters to kernal stack and push more cpu context(all general purpose registers)
Context switching in XV6:

Scheduler takes back control gives to any process in ptable(array in xv6).

That process gives back control to schedules and schedeules again give sit back to process.

Multiple reasons of switching:

Do note:
Context swticig happens in kernel mode not in user mode.
A- Loops through the process.

B- Finds the process runnable

C- Start running it.

D- Switch to the processo

E- sched, simply switch back to scheduler again(gives back the control)

s

Struct pushes the data onto the registers for future.

Swtiching from the scheduler to context.^^^
Process to the scheduler: