For this lab it will be important to understand a bit of RISC-V assembly.
Add a file user/call.c with the following content, modify the Makefile to add the program to the user programs, and compile (make fs.img). The Makefile also produces a binary and a readable assembly a version of the program in the file user/call.asm.
#include "kernel/param.h"
#include "kernel/types.h"
#include "kernel/stat.h"
#include "user/user.h"
int g(int x) {
return x+3;
}
int f(int x) {
return g(x);
}
void main(void) {
printf(1, "%d %d\n", f(8)+1, 13);
exit();
}
Read through user/call.asm and understand it. The instruction manual for RISC-V is in the doc directory (doc/riscv-spec-v2.2.pdf). Here are some questions that you should answer for yourself:
In this exercise you will modify the xv6 kernel to print out a line for each system call invocation. It is enough to print the name of the system call and the return value; you don't need to print the system call arguments.
When you're done, you should see output like this when booting xv6:
... fork -> 2 exec -> 0 open -> 3 close -> 0 $write -> 1 write -> 1
That's init forking and execing sh, sh making sure only two file descriptors are open, and sh writing the $ prompt. (Note: the output of the shell and the system call trace are intermixed, because the shell uses the write syscall to print its output.)
Hint: modify the syscall() function in kernel/syscall.c.
Run the xv6 programs you wrote in earlier labs and inspect the system call trace. Are there many system calls? Which system calls correspond to code in the applications you wrote?
Optional: print the system call arguments.
In this exercise you'll add a feature to xv6 that periodically alerts a process as it uses CPU time. This might be useful for compute-bound processes that want to limit how much CPU time they chew up, or for processes that want to compute but also want to take some periodic action. More generally, you'll be implementing a primitive form of user-level interrupt/fault handlers; you could use something similar to handle page faults in the application, for example.
You should add a new sigalarm(interval, handler) system call. If an application calls sigalarm(n, fn), then after every n "ticks" of CPU time that the program consumes, the kernel should cause application function fn to be called. When fn returns, the application should resume where it left off. A tick is a fairly arbitrary unit of time in xv6, determined by how often a hardware timer generates interrupts.
You should put the following test program in user/alarmtest.c: XXX Insert the final program here; maybe just give the code in the repo
#include "kernel/param.h"
#include "kernel/types.h"
#include "kernel/stat.h"
#include "kernel/riscv.h"
#include "user/user.h"
void test0();
void test1();
void periodic();
int
main(int argc, char *argv[])
{
test0();
test1();
exit();
}
void test0()
{
int i;
printf(1, "test0 start\n");
alarm(2, periodic);
for(i = 0; i < 1000*500000; i++){
if((i % 250000) == 0)
write(2, ".", 1);
}
alarm(0, 0);
printf(1, "test0 done\n");
}
void
periodic()
{
printf(1, "alarm!\n");
}
void __attribute__ ((noinline)) foo(int i, int *j) {
if((i % 2500000) == 0) {
write(2, ".", 1);
}
*j += 1;
}
void test1() {
int i;
int j;
printf(1, "test1 start\n");
j = 0;
alarm(2, periodic);
for(i = 0; i < 1000*500000; i++){
foo(i, &j);
}
if(i != j) {
printf(2, "i %d should = j %d\n", i, j);
exit();
}
printf(1, "test1 done\n");
}
The program calls sigalarm(2, periodic1) in test0 to
ask the kernel to force a call to periodic() every 2 ticks,
and then spins for a while. After you have implemented
the sigalarm() system call in the kernel,
alarmtest should produce output like this for test0:
Update output for final usertests.c
$ alarmtest alarmtest starting .....alarm! ....alarm! .....alarm! ......alarm! .....alarm! ....alarm! ....alarm! ......alarm! .....alarm! ...alarm! ...$
(If you only see one "alarm!", try increasing the number of iterations in alarmtest.c by 10x.)
The main challenge will be to arrange that the handler is invoked when the process's alarm interval expires. You'll need to modify usertrap() in kernel/trap.c so that when a process's alarm interval expires, the process executes the handler. How can you do that? You will need to understand in detail how system calls work (i.e., the code in kernel/trampoline.S and kernel/trap.c). Which register contains the address where system calls return to?
Your solution will be few lines of code, but it will be tricky to write the right lines of code. The most common failure scenario is that the user program crashes or doesn't terminate. You can see the assembly code for the alarmtest program in alarmtest.asm, which will be handy for debugging.
To get started, the best strategy is to first pass test0, which will force you to handle the main challenge above. Here are some hints how to pass test0:
XXX alarm() needs to be defined somewhere.
int sigalarm(int ticks, void (*handler)());
if(which_dev == 2) ...
make CPUS=1 qemu
XXX it is surprising that test0() appears to work perfectly, even though something is seriously wrong with the way periodic() returns. we should recognize that something odd is happening, maybe ask them to think about it, and hint or say why they are not done even though test0() works.
Test0 doesn't test whether the handler returns correctly to the user instruction that was interrupted by the timer. The previous section didn't require you to get this right. If you didn't, test0 will probably succeed anyway, but test1 will likely fail (the program crashes or the program goes into an infinite loop). Another challenge is that the register contents need to be correct when control returns to the interrupted user instruction.
Your solution is likely to require you to save and restore registers---what registers do you need to save and restore to resume the interrupted code correctly? (Hint: it will be many). There are several ways to restore the registers; one convenient plan is to add another system call sigreturn that the handler calls when it is done, and which restores registers and returns to the original interrupted user instruction. Some hints:
Once you pass test0 and test1, run usertests to make sure you didn't break any other parts of the kernel.
Download uthread.c and uthread_switch.S into your xv6 directory. Make sure uthread_switch.S ends with .S, not .s. Add the following rule to the xv6 Makefile after the _forktest rule:
$U/_uthread: $U/uthread.o $U/uthread_switch.o $(LD) $(LDFLAGS) -N -e main -Ttext 0 -o $U/_uthread $U/uthread.o $U/uthread_switch.o $(ULIB) $(OBJDUMP) -S $U/_uthread > $U/uthread.asmMake sure that the blank space at the start of each line is a tab, not spaces.
Add _uthread in the Makefile to the list of user programs defined by UPROGS.
Run xv6, then run uthread from the xv6 shell. The xv6 kernel will print an error message about uthread encountering a page fault.
Your job is to complete uthread_switch.S, so that you see output similar to this (make sure to run with CPUS=1):
~/classes/6828/xv6$ make CPUS=1 qemu ... $ uthread my thread running my thread 0x0000000000002A30 my thread running my thread 0x0000000000004A40 my thread 0x0000000000002A30 my thread 0x0000000000004A40 my thread 0x0000000000002A30 my thread 0x0000000000004A40 my thread 0x0000000000002A30 my thread 0x0000000000004A40 my thread 0x0000000000002A30 ... my thread 0x0000000000002A88 my thread 0x0000000000004A98 my thread: exit my thread: exit thread_schedule: no runnable threads $
uthread creates two threads and switches back and forth between them. Each thread prints "my thread ..." and then yields to give the other thread a chance to run.
To observe the above output, you need to complete uthread_switch.S, but before jumping into uthread_switch.S, first understand how uthread.c uses uthread_switch. uthread.c has two global variables current_thread and next_thread. Each is a pointer to a thread structure. The thread structure has a stack for a thread and a saved stack pointer (sp, which points into the thread's stack). The job of uthread_switch is to save the current thread state into the structure pointed to by current_thread, restore next_thread's state, and make current_thread point to where next_thread was pointing to, so that when uthread_switch returns next_thread is running and is the current_thread.
You should study thread_create, which sets up the initial stack for a new thread. It provides hints about what uthread_switch should do. Note that thread_create simulates saving all callee-save registers on a new thread's stack.
To write the assembly in thread_switch, you need to know how the C compiler lays out struct thread in memory, which is as follows:
--------------------
| 4 bytes for state|
--------------------
| stack size bytes |
| for stack |
--------------------
| 8 bytes for sp |
-------------------- <--- current_thread
......
......
--------------------
| 4 bytes for state|
--------------------
| stack size bytes |
| for stack |
--------------------
| 8 bytes for sp |
-------------------- <--- next_thread
The variables &next_thread and ¤t_thread each
contain the address of a pointer to struct thread, and are
passed to thread_switch. The following fragment of assembly
will be useful:
ld t0, 0(a0) sd sp, 0(t0)This saves sp in current_thread->sp. This works because sp is at offset 0 in the struct. You can study the assembly the compiler generates for uthread.c by looking at uthread.asm.
To test your code it might be helpful to single step through your uthread_switch using riscv64-linux-gnu-gdb. You can get started in this way:
(gdb) file user/_uthread Reading symbols from user/_uthread... (gdb) b *0x2300x230 is the address of uthread_switch (see uthread.asm). When you compile it may be at a different address, so check uthread_asm. You may also be able to type "b uthread_switch". XXX This doesn't work for me; why?
The breakpoint may (or may not) be triggered before you even run uthread. How could that happen?
Once your xv6 shell runs, type "uthread", and gdb will break at thread_switch. Now you can type commands like the following to inspect the state of uthread:
(gdb) p/x *next_thread
$1 = {sp = 0x4a28, stack = {0x0 (repeats 8088 times),
0x68, 0x1, 0x0 }, state = 0x1}
What address is 0x168, which sits on the bottom of the stack
of next_thread?
With "x", you can examine the content of a memory location