Hardware Support for Operating Systems

1
Hardware Support for Operating Systems

• Sunny Gleason
• Vivek Uppal
• COM S 414
• gleason_at_cs.cornell.edu
• vu22_at_cornell.edu

2
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
• Whats the state of a process? Think!

3
Protection

• However, in a multitasking system, we cant let
  the processes do everything that the CPU can do
• Examples they shouldnt 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!

4
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? Well see
  interrupts and returning from interrupts

5
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

6
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

7
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 lt
  a lt s2
• To do this quickly, we will need additional
  hardware support

8
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

9
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 gt B, or p lt A, the hardware triggers an
  access out-of-bounds exception

10
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

11
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 PC4 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

12
Interrupts

• Since interrupt service routines may access
  critical data structures (I/O buffers, PCBs,
  etc.) we typically dont want to be interrupted
  during their execution
• When interrupt i is being serviced, interrupts of
  priority j gt 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 lower-priority interrupts that they may
  have interrupted

13
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,
  lets call it sys_call
• The process executes a software interrupt
  instruction (in Linux, INT 0x80)
• The ISR for interrupt 0x80 jumps to address
  sys_callid
• System call code places return value into return
  register
• Returns from the interrupt using an IRET
  instruction

14
Returning from Exceptions

• For faults, execution returns to the original
  instruction (well 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?)

15
Peripherals

• Printer
• Key Board
• Mouse
• Speaker
• Storage Devices
• CPU communicates with the peripheral devices
  through a peripheral interface.

16
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)

17
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.

18
Device Organization
Application Program
Abstract I/O machine
Device Controller
Device
External hardware Disks, Tapes, C D Roms
19
Controller Interface
busy done 0 0 idle 0 1
finished 1 0 working 1 1
undefined
. . . busy done Error code . . .
Command
Status
Data 0
Data 1
Logic
Data n-1
20
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.
21
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
22
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
23
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)

24
Priorities

• Scenario
• Few resources
• Many contenders
• So we need arbitration
• Leads to priorities

25
Interrupt Priorities
Power event 30 Inter
processor signal 29 Clock tick
28 Performance
monitoring 27 General device
interrupts 3-26 Scheduler operations
2
26
Daisy chained I/O buses
Device n Lowest Priority
Device 1 Highest priority
Device 2
Grant
Grant
Grant
Bus Arbiter
Release
Request
27
Daisy Chain Bus
28
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
29
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.