1. 10. Epilogue ENGI 3655 Lab Sessions

2.  We took control of the computer as early as possible, right after the end of the BIOS  Our multi-stage bootloader enabled the more advanced functions of the computer ◦ Extended memory, segmentation, FAT linked- allocation file searching and loading ◦ Activated the CPU 32-bit protected mode and jumped to the Kernel  And our C kernel had the two most fundamental features ◦ Displaying stuff on-screen and handling interrupts ◦ We enabled our first interrupt-driven hardware devices, a PIT-based clock and the keyboard What We’ve Done Richard Khoury2

3.  Writing the other 46 Interrupt Handling Routines  Handling Physical Memory  Handling Virtual Memory  Paging  Multitasking  User Mode What’s Left? Richard Khoury3

4.  The system has a fixed amount of physical memory  The OS needs to know how much there is, and which parts are used or free ◦ That’s the memory map  The BIOS builds it automatically during the POST! ◦ Our bootloader will push the BIOS’s map information on the stack ◦ Our kernel will retrieve it as a KernelMain argument Handling Physical Memory Richard Khoury4

5.  The OS needs to keep track of which parts of memory are allocated/free  Divide memory into 4KB frames  Build a memory bitmap ◦ One bit per frame, 0/1 = free/allocated ◦ Stored sequentially, each bit is a frame in memory order  Frame number is a linear function of memory address ◦ Initialize with the memory map values Handling Physical Memory Richard Khoury5

6.  The OS needs some handling function ◦ Mark a frame as allocated/free in the bitmap ◦ Find a free frame in the bitmap ◦ Allocate a block of memory to a process  Converts the size of the block into frames  Checks that there is enough free memory  Finds the needed number of free frames and marks them as allocated  Returns the memory address of the frames Handling Physical Memory Richard Khoury6

7.  Each process has its own virtual memory space, divided in pages  Each page is represented by a 32-bit page table entry ◦ Bit 0: Present flag (0/1 if page is not/is present in physical memory) ◦ Bit 1: Read/Write flag (0/1 if page is read only/writable) ◦ Bit 2: Mode flag (0/1 if page is in kernel/user mode) ◦ Bits 3-4: Reserved by Intel ◦ Bit 5: Access flag; set by processor (0/1 if page has not/has been accessed) ◦ Bit 6: Dirty flag; set by processor (0/1 if page has not/has been written to) ◦ Bits 7-8: Reserved by Intel ◦ Bits 9-11: Available for use ◦ Bits 12-31: Frame address Handling Virtual Memory Richard Khoury7

8.  The page table is an array of page table entries PageEntry PageTable[1024]; ◦ This page table would represent 1024x4KB = 4MB of virtual memory using 1024x32bits = 4KB of memory Handling Virtual Memory Richard Khoury8 Page Entry 1023 Page Entry 0 Page Entry 1 Page Table …

9.  There are 1024 pages table per process ◦ 1024x4Mb = 4GB of virtual memory per process  So we need a way to manage page tables!  The page directory ◦ Naturally composed of page directory entries Handling Virtual Memory Richard Khoury9

10.  32-bit page directory entries ◦ Bit 0: Present flag (0/1 if table is not/is present in physical memory) ◦ Bit 1: Read/Write flag (0/1 if table is read only/writable) ◦ Bit 2: Mode flag (0/1 if table is in kernel/user mode) ◦ Bit 3: Write-through flag (0/1 if write-back/write- through is enabled) ◦ Bit 4: Cache flag (0/1 if table will not/will be cached) ◦ Bit 5: Access flag; set by processor (0/1 if table has not/has been accessed) ◦ Bit 6: Reserved by Intel ◦ Bit 7: Page size (0/1 for 4KB/4MB pages) ◦ Bit 8: Ignored ◦ Bits 9-11: Available for use ◦ Bits 12-31: Page table base address Handling Virtual Memory Richard Khoury10

11. Handling Virtual Memory Richard Khoury11 Page Entry 1023 Page Entry 0 Page Entry 1 Page Table 0 … Page Entry 1023 Page Entry 0 Page Entry 1 Page Table 1 … Page Entry 1023 Page Entry 0 Page Entry 1 Page Table 1023 … Page Directory Directory Entry 1023 Directory Entry 0 Directory Entry 1 …

12.  Now we have a page directory, page tables, and pages... So what’s left?  We have to tell the CPU to use paging!  Remember the Intel x86 Control Registers? ◦ CR0 controls a number of general behaviours ◦ CR1 is reserved by Intel ◦ CR2 controls the Page Fault Linear Address ◦ CR3 controls memory paging, and includes the Page Directory Base Register ◦ CR4 controls behaviour while in protected mode Paging Richard Khoury12

13.  CR0 Bit 31 is the Paging bit ◦ Switch to 1 to enable paging  When enabled, CR2 & CR3 are used ◦ CR3 contains the page directory base address ◦ In other words, we store the start address of the process’ page directory table in this register so the CPU can use it Paging Richard Khoury13

14.  With paging comes page faults ◦ Interrupt 14 in our IDT  Recall the Low Part of our Interrupt Handler pushed an error code ◦ For Interrupt 14, the error code is pushed by the CPU and the first five bits are significant ◦ Bit 0: 0/1 if page fault occurred because page was missing/other reason ◦ Bit 1: 0/1 operation that caused the page fault was a read/write ◦ Bit 2: 0/1 if CPU was running in ring 0/3 ◦ Bit 3: 0/1 page fault did not/did occur because reserved bits were written over ◦ Bit 4: 0/1 if page fault did not/did occur during an instruction fetch  CR2 contains the address that caused the page fault Paging Richard Khoury14

15.  A task can be represented as a C structure typedef struct task { uint32_t id; // Process ID uint32_t esp; // Stack pointer uint32_t ebp; // Base pointer uint32_t eip;// Instruction pointer page_directory_t *page_directory; // Page directory struct task *next; // Next task in list } task_t; Multitasking Richard Khoury15

16.  On switch from task0 to task1 ◦ Save the current values of esp, ebp and eip from the CPU registers to task0’s struct ◦ Load the values of esp, ebp and eip from task1’s struct to the CPU registers ◦ Load task1’s page directory into CR3 ◦ Jump to eip  We can move through the list of tasks by following the *next pointers ◦ task0->next = task1 ◦ On switch, move task0 to task0->next Multitasking Richard Khoury16

17.  You might remember the task state segment ◦ Part of the 80x86 architecture ◦ Contains information about the current process’ state ◦ Paired with Interrupt 10 in the IDT  So why build a task struct instead? ◦ Only marginally more efficient than our software solution ◦ Hardware-dependent, whereas our software isn’t Multitasking Richard Khoury17

18.  We need to switch tasks every N milliseconds ◦ This time cannot be counted by the kernel, as the CPU is busy running the task ◦ And we cannot trust the task to tell us when its time is up ◦ We need some kind of hardware timer, that we can program to generate an interrupt after a given interval… Multitasking Richard Khoury18

19.  So far, we are in Kernel Mode ◦ Code segment 0x08 and data segment 0x10  But now that we can run tasks, we want to run them in User Mode ◦ Code segment 0x18 and data segment 0x20  The only time we can switch segments is in assembly, when we return from a procedure ◦ Recall in the GDT code: mov ax, 0x10 mov ds, ax mov es, ax mov fs, ax mov gs, ax mov ss, ax jmp 0x08:endgdt User Mode Richard Khoury19

20.  It’s not enough to jump to user segments ◦ We have to request to have user privilege in them ◦ The last three bits of the descriptor are the requested privilege level ◦ 0x18 = 011000 → 011011 = 0x1B ◦ 0x20 = 100000 → 100011 = 0x23  Create a routine to return from in user mode mov ax, 0x23 mov ds, ax mov es, ax mov fs, ax mov gs, ax mov ss, ax push 0x23 push 0x1B iret User Mode Richard Khoury20

21.  What about returning to kernel mode? ◦ Needed for system calls, for example  We will set up a System Call interrupt ◦ Not one of the standard interrupts so we can assign it any number > 47 ◦ Linux uses Interrupt 80, for example  User program specifies the kernel function it wants, then generates an interrupt 80 ◦ CPU automatically switches to kernel segments ◦ Top Part of System Call Interrupt Handler will execute the function requested User Mode Richard Khoury21

22.  Modern computers are interrupt-driven ◦ Our KernelMain function runs an endless loop for (;;); ◦ Interrupts break it out of it, and jump to useful code  Timer notifications  Keyboard input  I/O device notifications  System calls  … Summary Richard Khoury22

23.  Our OS is well on its way  Already handles interrupts, both hardware and software ◦ That’s the most important part ◦ With this working, it’s easy to expand and add functionalities Summary Richard Khoury23

24.  Next week in lab  Will be a purely programming exam (no questions on theory)  You can use your own computer & programming tools  You will have access to the course website  You cannot ask each other (or me, or google) for help Lab Exam Richard Khoury24

25.  Will include some questions on the theory presented in labs  Will not include: ◦ Coding ◦ Trivia (i.e. dates) ◦ Minute technical details (i.e. “which port number is the keyboard controller data port?”) Final Exam Richard Khoury25

26. Richard Khoury26 Lab Assignment  Review labs 1 to 9 and the code you wrote  Make sure you understand it all  Make sure your code is complete, compiles, and works!!! ◦ The exam is only 90 minutes, you don’t want to spend it debugging your OS ◦ Don’t forget to bring it, and your USB key  Don’t panic