This is an undergraduate operating systems class that requires x86 assembly language and C language basics such as data structures, stacks, queues, and pointers. I will attach pdf of the lab with...

This is an undergraduate operating systems class that requires x86 assembly language and C language basics such as data structures, stacks, queues, and pointers. I will attach pdf of the lab with instructions and the .c files which code must be written in. There is two parts Part A and Part B. Part is due on the 27/11/2022 and part B is due on 23/10/2022. All Exercises 1-15 must be done. All the files which code has to be done are in zip folder and also I'm attaching lab manual.





Docs » Lab Assignments » Lab 4: Preemptive Multitasking Lab 4: Preemptive Multitasking Handed out: 10/28/2022 (Fri) Due: 12/04/2022 (Sun) 11:59pm Introduction In this lab you will implement preemptive multitasking among multiple simultaneously active user-mode environments. In Part A, you will add multiprocessor support to JOS, implement round-robin scheduling, and add basic environment management system calls (calls that create and destroy environments, and allocate/map memory). In Part B, you will implement a Unix-like fork() , which allows a user-mode environment to create copies of itself. Finally, in Part C you will add support for inter-process communication (IPC), allowing different user-mode environments to communicate and synchronize with each other explicitly. You will also add support for hardware clock interrupts and preemption. Getting started Use Git to commit your Lab 3 source, fetch the latest version of the course repository, and then create a local branch called lab4 based on our lab4 branch, origin/lab4 in the lab repository: https://crs.s3lab.io/cs4348/2022/fall/index.html https://crs.s3lab.io/cs4348/2022/fall/lab.html http://s3lab.utdallas.edu/cs4348/jos/-/tree/lab4 Chandrahas Nanduri Chandrahas Nanduri $ cd ~/jos $ git pull Already up-to-date. $ git add -A $ git commit -am 'changes to lab3 after handin' Created commit 734fab7: changes to lab3 after handin 4 files changed, 42 insertions(+), 9 deletions(-) $ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 4 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 remote: remote: To create a merge request for lab3, visit: remote: http://s3lab.utdallas.edu/cxk200010/jos/-/merge_requests/new? merge_request%5Bsource_branch%5D=lab3 remote: To ssh://s3lab.utdallas.edu:2224/cxk200010/jos.git 88682b1..494dc56 lab3 -> lab3 $ git remote add cs4348 ssh://[email protected]:2224/cs4348/jos.git $ git fetch cs4348 remote: Enumerating objects: 95, done. remote: Counting objects: 100% (95/95), done. remote: Compressing objects: 100% (63/63), done. remote: Total 64 (delta 23), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (64/64), 37.76 KiB | 234.00 KiB/s, done. From ssh://s3lab.utdallas.edu:2224/cs4348/jos * [new branch] lab1 -> cs4348/lab1 * [new branch] lab2 -> cs4348/lab2 * [new branch] lab3 -> cs4348/lab3 * [new branch] lab4 -> cs4348/lab4 $ git checkout -b lab4 cs4348/lab4 Branch 'lab4' set up to track remote branch 'lab4' from 'cs4348'. Switched to a new branch 'lab4' $ git push -u origin lab4:lab4 Enumerating objects: 95, done. Counting objects: 100% (95/95), done. Delta compression using up to 4 threads Compressing objects: 100% (63/63), done. Writing objects: 100% (64/64), 38.04 KiB | 2.54 MiB/s, done. Total 64 (delta 22), reused 0 (delta 0), pack-reused 0 remote: remote: To create a merge request for lab4, visit: remote: http://s3lab.utdallas.edu/cxk200010/jos/-/merge_requests/new? merge_request%5Bsource_branch%5D=lab4 remote: To ssh://s3lab.utdallas.edu:2224/cxk200010/jos.git * [new branch] lab4 -> lab4 Branch 'lab4' set up to track remote branch 'lab4' from 'origin'. $ git remote rm cs4348 $ You will now need to merge the changes you made in your lab3 branch into the lab4 branch, as follows: $ git merge lab3 Auto-merging lib/printfmt.c Auto-merging kern/trapentry.S Auto-merging kern/trap.c Auto-merging kern/syscall.c Auto-merging kern/pmap.c Auto-merging kern/env.c Merge made by the 'recursive' strategy. .lab1-extra | 1 + answers-lab2.txt | 7 ++++ answers-lab3.txt | 9 ++++ lib/printfmt.c | 12 ++++++- ... $ Lab 4 contains a number of new source �les, some of which you should browse before you start: kern/cpu.h Kernel-private de�nitions for multiprocessor support kern/mpconfig.c Code to read the multiprocessor con�guration kern/lapic.c Kernel code driving the local APIC unit in each processor kern/mpentry.S Assembly-language entry code for non-boot CPUs kern/spinlock.h Kernel-private de�nitions for spin locks, including the big kernel lock kern/spinlock.c Kernel code implementing spin locks kern/sched.c Code skeleton of the scheduler that you are about to implement Lab requirements This lab is divided into three parts, A, B, and C. Part A and Part B are due at the end of the third week and forth week from the time this lab was assigned, respectively; you should commit your changes and push your lab before the Part A deadline (11/20/2022 11:59pm) and Part B deadline (11/27/2022 11:59pm), even though your code may not yet pass all of the grade script tests. (If it does, great!) You only need to have all the grade script tests passing by the Part C deadline at the end of the �fth week (12/04/2022 11:59pm). As before, you will need to do all of the regular exercises described in the lab and provide a writeup that brie�y answers to the questions posed in the lab. Place the write-up in a �le called answers-lab4.txt in the top level of your repository directory before handing in your work. Chandrahas Nanduri Chandrahas Nanduri Chandrahas Nanduri Chandrahas Nanduri Part A: Multiprocessor Support and Cooperative Multitasking Due: 11/20/2022 (Sun) 11:59pm In the �rst part of this lab, you will �rst extend JOS to run on a multiprocessor system, and then implement some new JOS kernel system calls to allow user-level environments to create additional new environments. You will also implement cooperative round-robin scheduling, allowing the kernel to switch from one environment to another when the current environment voluntarily relinquishes the CPU (or exits). Later in Part C you will implement preemptive scheduling, which allows the kernel to re-take control of the CPU from an environment after a certain time has passed even if the environment does not cooperate. Multiprocessor support We are going to make JOS support "symmetric multiprocessing" (SMP), a multiprocessor model in which all CPUs have equivalent access to system resources such as memory and I/O buses. While all CPUs are functionally identical in SMP, during the boot process they can be classi�ed into two types: the bootstrap processor (BSP) is responsible for initializing the system and for booting the operating system; and the application processors (APs) are activated by the BSP only after the operating system is up and running. Which processor is the BSP is determined by the hardware and the BIOS. Up to this point, all your existing JOS code has been running on the BSP. In an SMP system, each CPU has an accompanying local APIC (LAPIC) unit. The LAPIC units are responsible for delivering interrupts throughout the system. The LAPIC also provides its connected CPU with a unique identi�er. In this lab, we make use of the following basic functionality of the LAPIC unit (in kern/lapic.c ): Reading the LAPIC identi�er (APIC ID) to tell which CPU our code is currently running on (see cpunum() ). Sending the STARTUP interprocessor interrupt (IPI) from the BSP to the APs to bring up other CPUs (see lapic_startap() ). In Part C, we program LAPIC's built-in timer to trigger clock interrupts to support preemptive multitasking (see apic_init() ). A processor accesses its LAPIC using memory-mapped I/O (MMIO). In MMIO, a portion of physical memory is hardwired to the registers of some I/O devices, so the same load/store instructions typically used to access memory can be used to access device registers. You've already seen one IO hole at physical address 0xA0000 (we use this to write to the VGA display buffer). The LAPIC lives in a hole starting at physical address 0xFE000000 (32MB short of 4GB), so it's too high for us to access using our usual direct map at KERNBASE . The JOS virtual memory map Chandrahas Nanduri leaves a 4MB gap at MMIOBASE so we have a place to map devices like this. Since later labs introduce more MMIO regions, you'll write a simple function to allocate space from this region and map device memory to it.  Note Exercise 1. Implement mmio_map_region() in kern/pmap.c . To see how this is used, look at the beginning of lapic_init() in kern/lapic.c . You'll have to do the next exercise, too, before the tests for mmio_map_region() will run. Application Processor Bootstrap Before booting up APs, the BSP should �rst collect information about the multiprocessor system, such as the total number of CPUs, their APIC IDs and the MMIO address of the LAPIC unit. The mp_init() function in kern/mpconfig.c retrieves this information by reading the MP con�guration table that resides in the BIOS's region of memory. The boot_aps() function (in kern/init.c ) drives the AP bootstrap process. APs start in real mode, much like how the bootloader started in boot/boot.S , so boot_aps() copies the AP entry code ( kern/mpentry.S ) to a memory location that is addressable in the real mode. Unlike with the bootloader, we have some control over where the AP will start executing code; we copy the entry code to 0x7000 ( MPENTRY_PADDR ), but any unused, page-aligned physical address below 640KB would work. After that, boot_aps() activates APs one after another, by sending STARTUP IPIs to the LAPIC unit of the corresponding AP, along with an initial CS:IP address at which the AP should start running its entry code ( MPENTRY_PADDR in our case). The entry code in kern/mpentry.S is quite similar to that of boot/boot.S . After some brief setup, it puts the AP into protected mode with paging enabled, and then calls the C setup routine mp_main() (also in kern/init.c ). boot_aps() waits for the AP to signal a CPU_STARTED �ag in cpu_status �eld of its struct CpuInfo before going on to wake up the next one.  Note Exercise 2. Read boot_aps() and mp_main() in kern/init.c , and the assembly code in kern/mpentry.S . Make sure you understand the control �ow transfer during the bootstrap of APs. Then modify your implementation of page_init() in kern/pmap.c to avoid adding the page at MPENTRY_PADDR to the free list, so that we can safely copy and run AP bootstrap code at that physical address. Your code should pass the updated check_page_free_list() test (but might fail the updated check_kern_pgdir() test, which we will �x soon).  Note Question 1. Compare kern/mpentry.S side by side with boot/boot.S . Bearing in mind that kern/mpentry.S is compiled and linked to run above KERNBASE just like everything else in the kernel, what is the purpose of macro MPBOOTPHYS ? Why is it necessary in kern/mpentry.S but not in boot/boot.S ? In other words, what could go wrong if it were omitted in kern/mpentry.S ? Hint: recall the differences between the link address and the load address that we have discussed in Lab 1. Per-CPU State and Initialization When writing a multiprocessor OS, it is important to distinguish between per-CPU state that is private to each processor, and global state that the whole system shares. kern/cpu.h de�nes most of the per-CPU state, including struct CpuInfo , which stores per-CPU variables. cpunum() always returns the ID of the CPU that calls it, which can be used as an index into arrays like cpus . Alternatively, the macro thiscpu is shorthand for the current CPU's struct CpuInfo . Here is the per-CPU state you should be aware of: Per-CPU kernel stack. Because multiple CPUs can trap into the kernel simultaneously, we need a separate kernel stack for each processor to prevent them from interfering with each other's execution. The array percpu_kstacks[NCPU][KSTKSIZE] reserves space for NCPU's worth of kernel stacks. In Lab 2, you mapped the physical memory that bootstack refers to as the BSP's kernel stack just below KSTACKTOP . Similarly, in this lab, you will map each CPU's kernel stack into this region with guard pages acting as a buffer between them. CPU 0's stack will still grow down from KSTACKTOP ; CPU 1's stack will start KSTKGAP bytes below the bottom of CPU 0's stack, and so on. inc/memlayout.h shows the mapping layout. Per-CPU TSS and TSS descriptor. A per-CPU task state segment (TSS) is also needed in order to specify where each CPU's kernel stack lives. The TSS for CPU i is stored in cpus[i].cpu_ts , and the corresponding TSS descriptor is de�ned in the GDT entry gdt[(GD_TSS0 >> 3) + i] . The global ts variable de�ned in kern/trap.c will no longer be useful. Per-CPU current environment pointer. Since each CPU can run different user process simultaneously, we rede�ned the symbol curenv to refer to cpus[cpunum()].cpu_env (or thiscpu->cpu_env ), which points to the environment currently executing on the current CPU (the CPU on which the code is running). Per-CPU system registers. All registers, including system registers, are private to a CPU. Therefore, instructions that initialize these registers, such as lcr3() , ltr() , lgdt() , lidt() , etc., must be executed once on each CPU. Functions env_init_percpu() and trap_init_percpu() are de�ned for this purpose. 