Download Slide set from 314 review session

Hardware Support for Operating
Systems
Sunny Gleason
Vivek Uppal
COM S 414
[email protected]
[email protected]
Multitasking
• In a multitasking uniprocessor OS, the OS tries to
give each process the illusion that it is running on
its own CPU.
• In reality, the OS:
– runs process A for a while
– gets interrupted by a timer, [the timer may need to be
reset by the CPU]
– saves the state of process A to memory
– restores the state of another process, B
(loading the PC, resumes execution of B)
– runs process B for a while … [repeat]
• What’s the state of a process? Think!
Protection
• However, in a multitasking system, we can’t let
the processes do everything that the CPU can do
• Examples: they shouldn’t be able to:
– Halt the CPU
– Read/Write to arbitrary devices, or locations in main
memory
(For example, the system timer, or the saved state of
another process)
• We need methods of protection!
User Mode and Kernel Mode
• Modern CPUs support multiple modes of
operation
• At the very least, we need user mode and kernel
mode
• User mode is the mode under which normal
applications run
• Kernel mode (also called Supervisor mode) is
the mode under which the OS code runs
• How do you go between them? We’ll see –
“interrupts and returning from interrupts”
User Mode and Kernel Mode
• Modes are implemented as integer privilege
levels: user == 3, kernel == 0
• In the x86 architecture, the current mode is stored
using 2 bits of the MSW (machine status word)
• The mode is typically implemented by tagging a
block of instructions in memory with the mode
• Jumping to new locations in memory causes the
mode to change to the tagged mode
User Mode and Kernel Mode
• In the Intel Pentium architecture, examples of
privileged instructions are:
– LMSW, SMSW (load/store MSW)
– MOV DBn, MOV CRn (move to debug/control
registers)
– LSL (load stack limit, adjusting one type of memory
available to a process)
– HLT (halt the CPU)
• A general protection exception is caused if
these instructions are reached by the CPU while
in user mode
User Mode and Kernel Mode
• How is memory protected?
• Typically, we check to make sure that an
address is within a given range [s1, s2],
that is, s1 <= a <= s2
• To do this quickly, we will need additional
hardware support …
Memory Protection
• In a shared environment, processes should
not be able to write to arbitrary locations in
the physical memory
• Processes need to have their own memory
to work with, or logical address space
• The CPU must check each memory access
to make sure that it is within the address
space of the process
Memory Protection
• A simple scheme:
– The program, as compiled, uses memory addresses
from a start address A to end address B
– When a program is loaded, the O/S allocates physical
memory to the process from base address A’ to limit
address B’
– While the process is running, A’ and B’ are loaded into
special hardware registers
– Special hardware translates a program address a to a
physical address p using p = a – A + A’
– If p > B’, or p < A’, the hardware triggers an access
out-of-bounds exception
Exceptions, faults, traps,
interrupts…
• CPU ordinarily executes instructions in order
• After every intruction (clock cycle), checks the
IRQ (interrupt request signal)
• Interrupts occur when:
– a device sends a signal on the IRQ line going into the
CPU (external interrupt)
– an INT n instruction is executed (software interrupt)
• Exceptions occur due to the CPU instruction that
was just executed: often these are categorized
into faults and traps
Interrupts
• Each interrupt has a numerical priority
• The interrupt vector – array of function pointers
to ISRs (interrupt service routines)
• When an interrupt occurs:
–
–
–
–
–
Push ret_addr = PC+4 onto the stack
Jump to [ivector_base + priority * 4]
[the CPU mode may switch]
Run the interrupt service routine code
Inform the interrupt controller that the interrupt has
been handled
– Pop ret_addr from the stack, jump to ret_add
– [the CPU mode returns to the previous mode]
Interrupts
• Since interrupt service routines may access
critical data structures (I/O buffers, PCB’s, etc.)
we typically don’t want to be interrupted during
their execution
• When interrupt i is being serviced, interrupts of
priority j >= i are masked, or disabled
• Priority is not enough to save you! The kernel
must be written so that higher-priority interrupts
do not clobber the data structures used by lowerpriority interrupts that they may have interrupted
System Calls
• System calls are just a special interrupt!
– The process pushes system call arguments into registers, or onto the
stack
– Under the covers, the first argument to a system call is an integer system
call identifier, call it id
– [implementation note: Linux keeps an array of pointers to the actual
system call routines, let’s call it sys_call[] ]
– The process executes a software interrupt instruction (in Linux, INT
0x80)
– The ISR for interrupt 0x80 jumps to address [sys_call[id]]
– System call code places return value into return register
– Returns from the interrupt using an IRET instruction
Returning from Exceptions
• For faults, execution returns to the original
instruction (we’ll learn about this later – a
page fault may trigger an ISR that loads
the page from disk into memory)
• For traps, execution returns to the
instruction following the original (have
you ever wondered how debugging
assembly code works?)
Peripherals
•
Printer
•
Key Board
•
Mouse
•
Speaker
•
Storage Devices
CPU communicates with the peripheral
devices through a peripheral interface.
Peripheral Interface
Abstract model of the interface.
• Top most layer of the interface
High level commands
(Like postscript commands)
• Device Model
Detailed device behavior
(printer/monitor)
Peripheral Interface Cont...
• Protocol layer
Recognition of Data and command bytes
Registers for giving commands to the device
Register to transfer the data to the device.
• Lowest level
Voltages, currents, Cables.
Device Organization
Application Program
Abstract I/O machine
Device Controller
Device
External hardware
Disks, Tapes, C D Roms
Controller Interface
busy done
. . . busy done Error code . . .
Command
Status
0
0
idle
0
1
finished
1
0
working
1
1
undefined
Data 0
Data 1
Logic
Data n-1
Controller Interface
A controller is at the protocol layer
of the device.
The controller could have registers
dedicated for the commands and
status or it could have some memory
location reserved for it.
In many cases the same controller
may be driving many devices.
Direct Memory Access (DMA)
What is the easiest I/O interface ?
One I/P instruction.
One O/P instruction.
Each instruction selects a device, and
transfers a byte of data.
Disadvantages:
DMA cont…
Better solution:
CPU selects the device, memory address, and
bytes of data to be transferred
After this initial set up the data transfer is taken
control of by the device controller and I/O and
computation at the CPU take place in parallel.
This is Direct memory Access(DMA).
Cycle Stealing:
Interrupts
A scenario when the I/O has finished. What should
the device do to let the process know that I/O has
finished ?
2 options
• Set flag in status. Wait for CPU to check it (Polling)
• Send a signal to CPU saying the I/O finished
(Interrupts)
Priorities
Scenario
• Few resources
• Many contenders
So we need arbitration
Leads to priorities
Interrupt Priorities
Power event
30
Inter processor signal
29
Clock tick
28
Performance monitoring
27
General device interrupts
3-26
Scheduler operations
2
Daisy chained I/O buses
Device 1
Highest
priority
Grant
Bus
Arbiter
Device 2
Grant
Release
Request
Grant
Device n
Lowest
Priority
Daisy Chain Bus
Daisy Chain Disadvantages
Unfair
One device goes down the whole down stream is
down
The bus may have to be turned off when adding a
new device to it
Review
Several devices are on the same I/O bus
Use some mechanism like daisy chain to determine
who gets to use the bus
I/O devices do DMA for bulk transfers
Devices make interrupts when they are done with the
I/O.
Device controllers are visible in memory at some
predefined address.