1. 23 June 2015 Charles Reiss http://cs162.eecs.berkeley.edu/
CS162: Operating Systems and Systems Programming Lecture 2: Multiprogramming and Dual Mode Operation
23 June 2015
Charles Reiss

2. Recall: What is an OS Referee Resource sharing, protection, isolation
Illusionist
Clean, easy abstractions
Glue: Common services
Storage
Window systems
Authorization
Networking
Three things an OS does from our textbook

3. Recall: Virtual Machines
Definition: Software emulation of abstract machine
Programs believe they own the machine
Simulated "hardware" has the features we want
Two types:
Process VM: run a single program in the VM
Example: Typical OS
System VM: run entire OS + its applications in the VM
Example: Virtualbox, VMWare, Parallels, Xen, ...
Last time the way I presented process v system VM was confusing.
An OS can implement either or both kinds of VM.
Process VM: what runs inside the VM is an application program runs inside a VM. The VM it runs inside is implemented by the OS.
System VM: there are multiple layers of VMs – nesting as deep as one likes nesting doll style. An OS runs inside the VM. Another one runs outside.

4. Recall: Dual Mode Operation
Hardware provides at least two modes:
"Kernel" (or "supervisor" or "protected")
Unix "kernel" runs here (part of OS running all the time)
"User" mode
Normal programs run here
Even if "administrator" or "superuser" or "sudo"
Some operations prohibited in user mode
e.g. changing the page table pointer
Someone had a good question after class about how dual mode operation in hardware relates to "superuser" or "administrator" or "sudo" – where your program is "allowed" to do anything.
Application programs still always run in user mode. Things like sudo just make it so when they ask the OS to do something, it says yes. They still need to go through the kernel to do it.

5. Outline: Four OS concepts
Threads: Execution context
Program counter, registers, stack
Address spaces w/ translation
Program's view of memory distinct from the physical machine
Process: an instance of a running program
Address space + one (or more) threads
Dual mode operation
Only the "system" can access certain resources
Combined with translation, isolates user programs from each other
Today we're going to talk about implementing multiprogramming – that is, allowing multiple, independent programs to run at the same time.
We're going to talk about doing this with the programs protected from each other, so we're going to go into more detail about some of the protection mechanisms we alluded to at the end of yesterday's lecture.

8. Outline: Four OS concepts
Threads: Execution context
Program counter, registers, stack
Address spaces w/ translation
Program's view of memory distinct from the physical machine
Process: an instance of a running program
Address space + one (or more) threads
Dual mode operation
Only the "system" can access certain resources
Combined with translation, isolates user programs from each other
Now, we're going to talk about a thread, which will encapsulate that processor state – program counter and registers – we talked about.

9. Threads of Control Definition: Single unique execution context
Program Counter, Registers, Stack
A thread is executing on a processor when it is resident in that processor' registers
Registers hold the root state of the thread:
The rest is "in memory"
Including program counter – currently executing instruction
Registers point to thread state in memory:
Stack pointer to the top of the thread's (own) stack
A thread consists of the program counter, registers, and stack.
The PC + registers are the part the OS has to move around all the time. If you have them, you can find it where the thread's stack and the code its executing live. When an OS starts a thread on a CPU, it's all it needs to manipulate.
But to create a thread, it does not need its own stack.

14. Simple Multiprogramming Problems
All vCPUs share the non-CPU resources
Memory, I/O devices
Each thread can read/write the data of others
Threads can overwrite OS functions
Unusable? No.
Embedded applications (sometimes)
MacOS 1-9
Windows 3.1
Windows 95-ME (sort of)
What I've described is enough to implement multiprogramming.
It's what real OSs did.
But it's not the modern standard and has never been considered acceptable for multiuser systems.

15. Outline: Four OS concepts
Threads: Execution context
Program counter, registers, stack
Address spaces w/ translation
Program's view of memory distinct from the physical machine
Process: an instance of a running program
Address space + one (or more) threads
Dual mode operation
Only the "system" can access certain resources
With translation, isolates user programs from each other/the OS
Next, address spaces. We previewed this yesterday.

19. Relocation? jal printf 000011 XX XXXXXXX XXXXXXX XXXXXXX
opcode for jal
address of printf (shifted right by 2)
For example, in MIPS, jump-and-link instructions – used for function calls, encode the address of their target directly. Typically, we want to resolve these addresses at link time – before we produce the executable. If we don't, two options: (1) do this linking before loading the program or (2) compile the program to not use insturctions like these – only instructions which relative addresses.

23. Virtual Address Translation/Paging
Maybe you remember this from 61C?
Regardless, more on this later in the course
Gives every process the whole address space
Break into pages (~4K chunks)
Allows unallocated "holes"
and other tricks
There's a better version of address translation called paging. You theoretically cover this in 61C – but people seem to forget it anyway. We'll go over this in more depth later.
The ways it's better is that it gives every process all the addresses they can name. The OS can make any part of that – in 4K chunks -- do whatever it needs.
This allows all sorts of tricks we'll talk about later.

24. Outline: Four OS concepts
Threads: Execution context
Program counter, registers, stack
Address spaces w/ translation
Program's view of memory distinct from the physical machine
Process: an instance of a running program
Address space + one or more threads
Dual mode operation
Only the "system" can access certain resources
With translation, isolates user programs from each other/the OS
Now we'll talk about the process.
For now, we'll just consider single-threaded processes. This means you take the thread we talked about earlier – the registers and program counter – and combine it with the address space.
[next slide]

25. The Process Process: execution environment with Restricted Rights
Address Space with One (or More) Threads
Today: Just one thread
Owns memory (address space)
Owns file descriptors, file system context, …
Why processes?
Protected from each other!
OS protected from them
Tradeoff: protection and efficiency
Threads more efficient than processes (later)
Application: one or more processes
That's essentially what a process is. There are a few other things we want to associate with a process related to other services the OS provides, like open files, which we'll talk about.
Two processes are protected from each other in space and time. They can't accidentally interfere with each other and don't need to be built with each other in mind (for example, no relocation).
Having separate address spaces has a cost, however. Threads are not free.
Don't confuse a process with an application. It is common for applications to be built from multiple processes. When you're writing an application you might find protection between different parts of your application are useful:

26. Protection Why? Reliability: buggy programs only hurt themselves
Security and privacy: trust programs less
Fairness: share of disk, CPU
Mechanisms:
Address translation: address space only contains its own data
Privileged instructions, registers
Syscall processing (e.g. enforce file access rights)

27. Outline: Four OS concepts
Threads: Execution context
Program counter, registers, stack
Address spaces w/ translation
Program's view of memory distinct from the physical machine
Process: an instance of a running program
Address space + one (or more) threads
Dual mode operation
Only the "system" can access certain resources
With translation, isolates user programs from each other/the OS

28. Dual Mode Operation Hardware provides to modes
"Kernel" (or "supervisor" or "protected")
"User" mode
Hardware support

29. Dual Mode Operation: HW Support
1 bit of state (user/kernel mode bit)
Certain actions only permitted in kernel mode
User->kernel transition sets kernel mode, saves user PC
Only transition to OS-designated addresses
OS can save the rest of the user state (if it needs to)
Kernel->user transition sets user mode, restores user PC
The most important piece of hardware support is the user/kernel mode bit and that the processor honors it. For example, a thread better not be able to update its base or bound register in user mode. The hardware needs to enforce this.
But how do we set this bit to kernel mode? We can't just let the user program do it on demand.
Hardware needs to support controlled entry to kernel mode. As we'll talk about in a bit, we also want the hardware to save the address where that happened from, because some of these transitions need to be invisible to the user.
The key part of the controlled entry is that the OS decides what code runs first. That code is responsible for keeping thing safe.

32. Types of (U->K) Mode Switches
System call (syscall)
"Function call" to the kernel
Example: exit, read
Kernel reads syscall id + args from user registers
Interrupt
External asynchronous events: timer, I/O
Trap or Exception
Special event in process
Protection violation (segfault), divide by zero, …

33. A brief terminology note
Architectures have a lack of agreement about the names
Interrupt
Trap
Exception
Sorry.
We will try to be consistent in this course.

35. Mode Transfer Hygeine Very careful kernel code packs up user state
Must handle weird buggy/malicious user state:
Syscall with null pointers
Return instruction out of bounds
User stack pointer out of bounds
Cannot let user corrupt kernel
User program should not know interrupt occurred

36. The Kernel Stack Interrupt handlers want a stack
System call handlers want a stack
Can't use the user stack [Why?]
User stack might not even be valid
Some handlers – for IO – for switching processes – need to be invisible to user, they would notice if the kernel manipulated their stack
Kernel might put information on stack user is not supposed to know about.

37. The Kernel Stack Solution: Two stacks
Each OS thread has kernel stack and user stack
Place to save user registers during interrupt
Typical design is to have a kernel stack for every user thread.
This also gives the kernel a place to save the user registers during an interrupt.
One question is how knows where to change the stack pointer to and save the old one. Often the hardware supports this. Otherwise, the kernel can hardcode a memory location to use.

38. Before Interrupt

39. During Interrupt

40. Handling interrupts safely
Interrupts disabling
On entry to handler (by hardware)
Reenabled on completion
Explicitly by OS: (cli/sti on x86)
A key piece of hardware support for interrupts is disabling. Consider the case of switching stacks before. What happens if we get a second interrupt while we're saving the first interrupt's state. Chaos? Maybe we could write that code so nothing bad happens?
We don't need to. Hardware automatically prevents this from happening. It lets us disable interrupts. When interrupts are disabled, hardware events aren't forgotten, but won't cause an interrupt until interrupts are enabled again.

41. Why disable interrupts?
Interrupt while saving state during interrupt handler
Interrupt while restoring state to return from interrupt/syscall
Interrupt while reconfiguring interrupt handlers
Interrupt while selecting a new process to run

42. Handling interrupts safely
Interrupts disabling
On entry to handler (by hardware)
Reenabled on completion
Explicitly by OS: (cli/sti on x86)
When selecting process to run [Why?]
Just before returning from interrupt/syscall [Why?]
Handler must be quick
Can't hold up whatever it's interrupting
Usually just queue work for later (wake up a thread)
A key piece of hardware support for interrupts is disabling. Consider the case of switching stacks before. What happens if we get a second interrupt while we're saving the first interrupt's state. Chaos? Maybe we could write that code so nothing bad happens?
We don't need to. Hardware automatically prevents this from happening. It lets us disable interrupts. When interrupts are disabled, hardware events aren't forgotten, but won't cause an interrupt until interrupts are enabled again.

43. Handling interrupts safely
Atomically change all of these:
User/kernel mode
Program counter
Memory protection
→ "Return from interrupt" (RFI) instruction
Also needed for syscalls, etc.
When we enter an interrupt, the hardware changes all of these things at once.
We also need a way to do the reverse. Typically, the hardware provides a special "return-from-interrupt" instruction.
Note that we need some extra space to hold the program counter to return to in addition to all the user registers. Typically the hardware provides a special register for this purpose.

44. Handling system calls safely
Same work as interrupts to enter/leave
Copy arguments from user registers/memory (!)
Carefully check memory locations!
Validate arguments
Kernel can't crash if user code is broken/malicious
Do operation
Copy result back into user registers/memory

45. Addt'l HW support for interrupts
Multiple layers of interrupts
Priority levels
Some non-maskable (can't be disabled)
segmentation fault in segmentation fault handler
"watchdog" timer

46. Outline: Four OS concepts
Threads: Execution context
Program counter, registers, stack
Address spaces w/ translation
Program's view of memory distinct from the physical machine
Process: an instance of a running program
Address space + one or more threads
Dual mode operation
Only the "system" can access certain resources
With translation, isolates user programs from each other/the OS

47. Putting it together Mode transfer and translation
Switching between processes
A brief note on hardware threads

48. Putting it together Mode transfer and translation
Switching between processes
A brief note on hardware threads

49. Mode Transfer and Translation
Mode transfer should change translation map
Examples:
Ignore base + bound in kernel mode
Page tables with "kernel mode only" bits

54. Putting it together Mode transfer and translation
Switching between processes
A brief note on hardware threads

55. Switching between processes
Just two mode transfers!

59. Process Control Block (PCB)
Kernel representation of each process
Status (running, ready, blocked)
Register state (if not ready)
The thread control block – for now, one thread per process
Process ID
Execution time
Memory translations, …
Scheduler maintains a data structure of PCBs
Scheduling algorithm decides what to run

62. Putting it together Mode transfer and translation
Switching between processes
A brief note on hardware threads

64. Conclusion: Four OS concepts
Thread
Single unique execution context
Program Counter, Registers, Stack
Address Space w/ Translation
Programs execute in an address space that is distinct from the memory space of the physical machine
Process
An instance of an executing program is a process consisting of an address space and one or more threads of control
Dual Mode operation/Protection
Only the “system” has the ability to access certain resources
The OS and the hardware are protected from user programs and user programs are isolated from one another by controlling the translation from program virtual addresses to machine physical addresses

65. Missing topics:
Multicore
Idle loop/power
Performance (OS overhead)

66. Break