Operating Systems and Interrupts/Exceptions

Transcription

1 Operating Systems and Interrupts/Exceptions Arvind Computer Science & Artificial Intelligence Lab. Massachusetts Institute of Technology Code for the lecture is available on the course website under the code tab April 10, L15-1

2 Operating Systems application application Operating system Hardware Application binary interface (ABI) Supervisor binary interface (SBI) Modern processors cannot function without some resident programs ( services ), which are shared by all users Services: programs for accessing I/O devices like, keyboard, mouse, display, disks, printers, network,... I/O devices have very long access latency as compared to registers and memories (milliseconds as opposed to microseconds) For efficiency, it is common to employ multiprogramming and switch to another task while waiting for an I/O operation to complete This creates a host of new problems April 10, L15-2

3 Multiprogrammed Systems Protection & Privacy Each program (user) has a private address space and a way of accessing OS which is shared by all programs The OS ensures that a program cannot access the address space of any other program Scheduling OS multiplexes the use of CPU among programs; only one program can be active at a given time Resource management OS also manages access to all other shared resources, e.g., I/O devices OS prog i In the jargon we use the word process instead of program April 10, L15-3

4 Process Life Cycle completed process created ready executing waiting scheduled interrupted woken-up OS maintains a list of all processes and their status {ready, executing, waiting} a process is scheduled to run for a specified amount of CPU time or until completion process is interrupted if it needs I/O service or runs out of allotted time slice, and is put in the sleep/waiting state another process can be scheduled a waiting process is woken up and put in the ready list when waiting-condition has been satisfied April 10, L15-4

5 Physical Memory Private Address Space per Process 0 n Process1 OS pages 0 m Process2 free Each process is allocated space in the memory by OS A process is not allowed to access memory of other processes or OS It is convenient if the program and data addresses don t depend upon where the process is allocated in the memory free free free free April 3, L14-5

6 Mirrage Main Memory Simple dynamic address Translation much more on dynamic address translation in L16 Bound Reg Bound Violation Base Reg Load X Effective + Address Program Address Space Physical Address Effective address is translated into a physical address at run time Base register has to be reloaded by the OS every time the active process changes Bound register can provide safety and isolation User Program & Data Load X Base and Bound registers should not be accessed by user programs user mode versus supervisor mode

7 Communicating with I/O devices We have a set of I/O registers (different from GPRs) which both the I/O devices and the CPU can read and write CPU can be read I/O registers in two different ways: Polling: It periodically reads the register associated with a specific device Interrupt: The I/O device can write the register and then interrupt the processor (i.e., ring the door bell!). Often these registers are mapped to specific memory addresses (Memory-Mapped I/O), some of which can be accessed only in the supervisor mode Some care has to be exercised in address translation while accessing MMIO locations We need a general framework and addressing mapping conventions to deal with a plethora of I/O devices more general way April 10, L15-7

8 ISA Extensions to support OS In RISC-V all special registers needed to implement an OS are collectively referred to as CSRs (Control and Status Registers) we will introduce them as needed The instructions to access CSRs are atomic, i.e., they perform a read followed by a write csrrw (read-write), csrrs (read-set specified bits to 1), csrrc (read-clear specified bits to 0) Almost all services we built require a mechanism to stop the program at a specific instruction under a variety of conditions and the transfer control to an OS routine to deal with that specific condition These ISA extensions work only if hardware and software (OS) agree on a common set of conventions April 10, L15-8

9 Interrupt (aka Trap) altering the normal flow of control I i-1 HI 1 program I i HI 2 interrupt handler I i+1 HI n An external or internal event that needs to be processed by another (system) program. The event is usually unexpected or rare from program s point of view. April 10, L15-9

10 Interrupts caused by an external event External asynchronous event input/output device service-request/response timer expiration power disruptions, hardware failure After the processor decides to process the interrupt It stops the current program at instruction I i, completing all the instructions up to I i-1 (Precise interrupt) It saves the PC of instruction I i in a special register It disables interrupts and transfers control to a designated interrupt handler running in more privileged mode Switch from user mode to supervisor mode prevents user programs from causing harm to other users or OS April 10, L15-10

11 Exceptions caused by the execution of an instruction The instruction cannot be completed undefined opcode, privileged instruction arithmetic overflow, FPU exception misaligned memory access virtual memory exceptions: page faults, TLB misses, protection violations System call: Deliberately used by the programmer to invoke an OS service next lecture Either the faulting condition is fixed; or the instruction is emulated by the exception handler; or the program is aborted The processor must undo any partial execution of the instruction and record the cause of the exception April 10, L15-11

12 Trap (Interrupt or Exception) handling When an trap is caused Hardware saves the information about the interrupt in CSRs: mepc exception PC mcause cause of the exception mstatus.mpp privilege mode of exception... Processor jumps to the address of the trap handler (stored in the mtvec CSR) and increases the privilege level A trap handler, a software program, takes over and performs the necessary action April 10, L15-12

13 Trap handling software There is a great variety of interrupts and exceptions and each has to be handled differently Hardware transfers all traps to a program known as the common interrupt handler (CH) It saves registers in a known place and transfers control to a specific Interrupt handler (IH) If the trap has been handled successfully, IH returns the control back to CH, which restores the registers and resumes the interrupted program Typically CH is written in Assembler but IH s are written in C April 10, L15-13

14 Outline of Common Interrupt Handler (CH) 1. Saves all GPRs (x0-x31) into known memory locations 2. Passes mcause, mepc, stack pointer to the IH (a C function) to handle the specific interrupt mcause, mepc, etc are loaded by hardware 3. On the return from the IH, writes the return value to mepc 4. Loads all GPRs from the memory 5. Execute mret, which does: set pc to mepc a new pop mstatus (mode, enable) stack instruction CH GPR IH IH IH April 10, L15-14

15 Common Interrupt Handler- SW (RISC-V Assembly code) common_handler: # entry point for exception handler # save x1 to mscratch to free up a register csrw mscratch, x1 # write x1 to mscratch # get the pointer for storing GPRs li x1, GPR_BASE # save x2 - x31 sw x2, 8(x1) sw x3, 12(x1)... sw x31, 124(x1) # now registers x2 x31 are free # save original x1 (now in mscratch) csrr x2, mscratch # x2 used as temporary register sw x2, 4(x1) # x1 still points to GPR storage April 10, L15-15

16 Common handler- SW cont. Setting up and calling IH_Dispacher common_handler:... # we have saved all GPRs to stack # call C function to handle interrupt csrr a0, mcause # arg 0: cause csrr a1, mepc # arg 1: epc li a2, GPR_BASE # arg 2: pointer to all saved GPRs... # set up stack pointer for C-code jal ih_dispatcher # calls ih_dispatcher which may # have been written in C # return value is the PC to resume csrw mepc, a0 # restore mscratch and all GPRs li x1, GPR_BASE; lw x2, 8(x1); lw x3, 12(x1);...; lw x31, 124(x1) lw x1, 4(x1) # restore x1 last mret # finish handling interrupt April 10, L15-16

17 IH Dispatcher (in C) Dispatches to a specific handler based on cause Remember, before we call ih_dispatcher, we know the cause, epc, and have a pointer to where the registers (x1-x31) have been saved. (C can be used because of calling conventions) long ih_dispatcher(long cause, long epc, long *regs) { // regs[i] refers to GPR xi stored in stack if(cause == 0x02) // illegal instruction return illegal_ih(cause, epc, regs); else if(cause == 0x08) // system call, e.g, OS service write to file return syscall_ih(cause, epc, regs); else if (cause == 0x0D) // load address translation fault else if (cause < 0) // external interrupt... } Key board handler in Recitation on Friday As an example we show an interrupt handler to implement multiply instruction in Software April 10, L15-17

18 Multiply mul x1, x2, x3 is an instruction in the M extension (x1 := x2 * x3) If M is not implemented, this is an illegal instruction What happens if we run code from an RV32IM machine on an RV32I machine? mul causes an illegal instruction exception An exception handler can take over and abort the program or emulate the instruction April 10, L15-18

19 SW emulation of MULT instruction mul rd, rs1, rs2 MUL can be decoded as an unsupported instruction in the decoder It will throw an Illegal Instruction exception when executed Illegal Instruction handler illegal_inst_ih checks if the interrupted instruction is a MUL and if it is then it simply calls the code that emulates the multiply function Control is resumed to epc + 4 after emulation is done (MRET) April 10, L15-19

20 Illegal Instruction IH (in C) long illegal_inst_ih(long cause, long epc, long *regs) { uint32_t inst = *((uint32_t*)epc); // fetch inst // check opcode & function codes if((inst & MASK_MUL) == MATCH_MUL) { // is MUL, extract rd, rs1, rs2 from inst int rd = (inst >> 7) & 0x01F; int rs1 =...; int rs2 =...; // emulate regs[rd] = regs[rs1] * regs[rs2] multiply(rd, rs1, rs2, regs); return epc + 4; // done, resume at epc+4 } else abort(); } Multicycle-cycle implementation of Interrupts : the next few slides Optional April 10, L15-20

21 Decode function DecodedInst decode(data inst, Mode mode); DecodedInst dinst =?;... opsystem: begin case (funct3)... fnpriv: begin // privilege inst dinst.itype = case(inst[31:20]) fn12ecall: SYSCALL; // sys call // MRET can only be executed under a privileged mode fn12mret: ispriv(mode)? MRET : NoPermit;... default: Unsupported; endcase; dinst.dst = Invalid; dinst.rs1 =?; dinst.rs2 =?; dinst.imm =?; dinst.alufunc =?; dinst.brfunc =?; end... endcase... return dinst; endfunction end typedef enum {OP,..., SYSCALL, MRET, NoPermit} IType April 10, L15-21

22 Add Execute code for setting CSRs... if (einst.itype==syscall) begin csrf.setstatus(statuspush(csrf.getstatus)); csrf.setcause(32 h08); // cause for System call csrf.setepc(pc); end else if (einst.itype==mret) begin csrf.setstatus(statuspop(csrf.getstatus)); end April 10, L15-22

23 Redirecting PC if (einst.itype==syscall) pc <= csrf.gettvec; else if (einst.itype==mret) pc <= csrf.getepc; else pc <= einst.brtaken? einst.addr : pc + 4; Interrupt redirection is done from the last stage; speed is not a paramount concern in hardware handling of interrupts April 10, L15-23

24 Saving GPRs a small complication optional another CSR Operating system manages the space where GPRs are saved and provides a pointer to the space for the current program For simplicity we ll assume this location is fixed at GPR_BASE RISC-V s memory instructions require the base address to be stored in a GPR Therefore before GPRs can be saved, we need to free up a GPR (say x1) by storing its value in a special scratch register (mscratch) After saving the other GPRs, they (??) are freed up Finally, x1 is restored from mscratch and saved April 10, L15-24