What You Need to Know for Project One

1. What You Need to Knowfor Project One Joey Echeverria Friday, August 29, 2003 15-410 Fall 2003

2. Overview • Introduction • Project One Motivation and Demo • Mundane Details in x86PIC and hardware interrupts, software interrupts and exceptions, the IDT, privilege levels, segmentation • Writing a Device Driver • Installing and Using Simics Carnegie Mellon University

3. A Little Bit About Myself • My name is Joey • I’m a senior in ECE (sort-of) • I took OS with Greg Kesden last fall • I, like the rest of the staff, am Here to Help™ Carnegie Mellon University

4. Project 1 Motivation • What are our hopes for project 1? • introduction to kernel programming • a better understanding of the x86 arch • hands-on experience with hardware interrupts and device drivers • get acquainted with the simulator (Simics) and development tools Carnegie Mellon University

5. Project 1 Demo • Project 1 consists of using the console, keyboard and timer to create a simple game • Demo… Carnegie Mellon University

6. Mundane Details in x86 • Kernels work closely with hardware • This means you need to know about hardware • Some knowledge (registers, stack conventions) is assumed from 15-213 • You will learn more x86 details as the semester goes on • Use the Intel PDF files as reference (http://www.cs.cmu.edu/~410/projects.html) Carnegie Mellon University

7. Mundane Details in x86: Privilege Levels • Processor has 4 “privilege levels” (PLs) • Zero most privileged, three least privileged • Processor executes at one of the four PLs at any given time • PLs protect privileged data, cause general protection faults Carnegie Mellon University

8. Mundane Details in x86:Segmentation • When fetching an instruction, the processor asks for an address that looks like this: CS:EIP • So, if %EIP is 0xbeef then this is the 48879th byte of the CS segment. • The CPU looks at the segment selector in %CS • A segment selector looks like this: Carnegie Mellon University

9. Mundane Details in x86:Segmentation • The segment selector has a segment number, table selector, and requested privilege level (RPL) • The segment number is an index into a segment descriptor table • The table select flag selects a descriptor table • There are two tables: global descriptor table and a local descriptor table • The RPL’s meaning differs with the segment register the selector is in • For %CS, RPL sets the processor privilege level Carnegie Mellon University

10. Mundane Details in x86:Segmentation • Segments are defined areas of memory with particular access/usage constraints • Segments descriptors specify a base and a size • A segment descriptor looks like this: Carnegie Mellon University

11. Mundane Details in x86:Segmentation • For our example, if the segment descriptor indexed by the segment selector in %CS specified a base address of 0xdead0000 • Then assuming 0xbeef is smaller than the size of the segment, the address CS:EIP represents the linear virtual address 0xdeadbeef • This is fed into the page-directory/page-table system which will be important in project 3 Carnegie Mellon University

12. Mundane Details in x86:Segmentation • CS is the segment register for code • SS is the segment register for the stack segment • DS is the default segment register for data read/writes, but ES, FS, and GS can also be used Carnegie Mellon University

13. Mundane Details in x86:Segmentation • Segments need not be backed by physical memory and can overlap • Segments defined for these projects: 0xFFFFFFFF Kernel Code Kernel Data User Code User Data Not This Project 0x00000000 Carnegie Mellon University

14. Mundane Details in x86:Segmentation • Why so many? • You can’t specify a segment that is readable, writable and executable. • Therefore one for readable/executable code • Another for readable/writable data • Need user and kernel segments in project 3 for protection Carnegie Mellon University

15. Mundane Details in x86:Segmentation • Don’t need to be concerned with the mundane details of segments in this class • For more information you can read the intel docs or our documentation at: http://www.cs.cmu.edu/~410/doc/segments/segments.html Carnegie Mellon University

16. Mundane Details in x86: Getting into Kernel Mode • How do we get from user mode (PL3) to kernel mode (PL0)? • Exception (divide by zero, etc) • Software Interrupt (int n instruction) • Hardware Interrupt (keyboard, timer, etc) Carnegie Mellon University

17. Mundane Details in x86: Exceptions • Sometimes user processes do stupid things • int gorganzola = 128/0; • char* idiot_ptr = NULL; *idiot_ptr = 0; • These cause a handler routine to be executed at PL0 • Examples include divide by zero, general protection fault, page fault Carnegie Mellon University

18. Mundane Details in x86:Software Interrupts • A device gets the kernel’s attention by raising an interrupt • User processes get the kernel’s attention by raising a software interrupt • x86 instruction int n(more info on page 346 of intel-isr.pdf) • Executes handler routine at PL0 Carnegie Mellon University

19. Mundane Details in x86: Interrupts and the PIC • Devices raise interrupts through the Programmable Interrupt Controller (PIC) • The PIC serializes interrupts, delivers them • There are actually two daisy-chained PICs CPU PIC 1 PIC 2 Timer Keyboard IDE 1 IDE 2 Carnegie Mellon University

20. Mundane Details in x86:Interrupts and the PIC To Processor Carnegie Mellon University

21. Mundane Details in x86: Interrupt Descriptor Table (IDT) • Processor needs info on what handler to run when • Processor reads appropriate IDT entry depending on the interrupt, exception orint n instruction • An entry in the IDT looks like this: Carnegie Mellon University

22. Mundane Details in x86: Interrupt Descriptor Table (IDT) • The first 32 entries in the IDT correspond to processor exceptions. 32-255 correspond to hardware/software interrupts • Some interesting entries: More information in section 5.12 of intel-sys.pdf. Carnegie Mellon University

23. Mundane Details in x86:Communicating with Devices • I/O Ports • use instructions like inb, outb • use separate address space • Memory-Mapped I/O • magic areas of memory tied to devices • console is one of them Carnegie Mellon University

24. Writing a Device Driver • Traditionally consist of two separate halves • named “top” and “bottom” halves • BSD and Linux use these names differently • One half is interrupt driven, executes quickly, queues work • The other half processes queued work at a more convenient time Carnegie Mellon University

25. Writing a Device Driver • For this project, your keyboard driver will likely have a top and bottom half • Bottom half: • Responds to keyboard interrupts and enqueue scan codes • Top half: • In readchar(), read from the queue and processes scan codes into characters Carnegie Mellon University

26. Installing and Using Simics • Simics is an instruction set simulator • Makes testing kernels MUCH easier • Runs on both x86 and Solaris • If you want to run from Solaris, we can try and accommodate, but the tarball only has linux support Carnegie Mellon University

27. Installing and Using Simics:Running on AFS • We use mtools to copy to disk image files • Proj1 Makefile sets up config file for you • You must exec simics in your project dir • The proj1.tar.gz includes: • Only simics-linux.sh right now, can provide simics-solaris.sh if you are really interested Carnegie Mellon University

28. Installing and Using Simics:Running on AFS • We give you some volume space • It is located here: /afs/cs.cmu.edu/academic/class/15410-f03/usr/<user-id> • You should use this volume • This way, if you have a problem the staff will have permission to look at your code • This will help speed up answers to your questions Carnegie Mellon University

29. Installing and Using Simics:Running on Personal PC • Runs under Linux or Solaris (we will try to support this) • As of now you need a 128.2.*.* IP or a node locked license (takes a day or two to get this) • Download simics-linux.tar.gz (real soon™) • Install mtools RPM (pointer on course www) • Tweak Makefile Carnegie Mellon University

30. Installing and Using Simics: Debugging • Run simulation with r, stop with ctl-c • Magic instruction • xchg %bx,%bx (wrapper in interrupts.h) • Memory access breakpoints • break 0x2000 –x OR break (sym init_timer) • Symbolic debugging • psym foo OR print (sym foo) • Demo Carnegie Mellon University