Hints for A3

This file may be updated, so check back periodically.

Quick Topic Links

• Getting Started
• Synchronization
• Handling TLB Faults
• as_copy
• Testing
• I didn't get the A2 system calls working

Getting Started

When you reconfigure your kernel for Assignment 3, major changes will be made that will prevent your kernel from compiling. These changes include:

• the file dumbvm.c will no longer be compiled and included in the kernel
• the file vm/addrspace.c will be compiled and included in the kernel - it was not included in the kernels that you compiled for A1 and A2.
• the preprocess option OPT_DUMBVM will no longer be defined. This means that most of the fields in the addrspace structure defined in include/addrspace.h will no longer be present in that structure.

The best way to get started on A3 is to first get back to where you can compile and run your kernel, and then start to implement the requirements for A3. If you don't do this, you will will not be able to test your A3 work incrementally as you get it done, and you'll be left with a huge mess to test at the end - almost a guarantee of testing and debugging nightmares.

One way to get started is to simply copy the implementations of the addrspace functions from dumbvm.c to addrspace.c. You will also need implementations of the other functions from dumbvm.c (like the fault handler, vm_fault and the various low level VM and physical memory functions, such as vm_bootstrap and getppages). You can either add a separate file to hold these functions, or you can simply copy them into addrspace.c as well. Finally, you will need to patch up the addrspace structure in addrspace.h so that the fields that went away when OPT_DUMBVM stopped being defined will be present again. Once you've made these changes, make sure that you can build your kernel and that things that ran after A2 continue to run.

Once you have done this, you can start working on the various parts of A3. Since you have a working kernel, you should be able to test each part of A3 as you build it.

Synchronization

• Remember that when a page fault occurs and the page needs to be copied from disk, the process that initiates the copy will block. While that process is blocked other process in the system may run.

Handling TLB Faults

• Make sure that your TLB fault handler (vm_fault) does not do anything that might cause another TLB fault. The result will be a potentially infinite nesting of TLB faults from which your kernel will probably not recover. In particular, your TLB fault handler should avoid anything that involves touching virtual addresses in the application's part of the virtual address space, since those attempts might generate faults, depending on what's in the TLB. Functions like copyin and copyout are examples of functions that touch application virtual addresses.

as_copy

• The as_copy function is needed only by the fork system call. Most A3 testing will not involve fork. Save as_copy for last - work on it only if you have time.

Testing

• Implementation marks for A3 are broken into three categories. Here is how we will be doing the testing for each of these categories
  • general single-process tests
    These single-process tests just test that your virtual memory system is working. Other than your virtual memory statistical output, they do not test any of the specific new features you are adding to the virtual memory system for A3. We will use the palin, matmult and sort applications to test. We will run palin using the default physical memory size. For matmult and sort, we will increase the physical memory size by a factor of 10 (to 5242880 bytes) before running the tests, to ensure that these applications can fit into memory. See below for instructions on how to change the physical memory size of the virtual machine.

    None of these programs make use of command line arguments, and none make use of system calls other than write to the console and exit.

  • on-demand loading, TLB replacement, read-only memory
    To test on-demand loading, we will use the sparse and huge applications. sparse will be run with the default physical memory size, and huge will be run with 10 times the default physical memory size. To test TLB replacement, we will use the tlbfaulter application run with 10 times the default memory size. To test protection of read-only memory, we will use romemwriter and the default physical memory size. In each case, we will be relying on the virtual memory statistics output by your kernel as an indication of whether your kernel is behaving as expected.

    Like the general single-process tests, these do not use argument passing and do not rely on system calls other than console writes and _exit.

  • general multi-process tests
    These tests are intended to test the robustness of your virtual memory implementation. We will run two tests: forktest and sty. Both will be run with 10 times the default physical memory size.
• To run many of the test programs you will need to increase the physical memory size of the machine. You can do this by editing root/sys161.conf. Look for this line:

  31      busctl  ramsize=524288
  

  which says that the machine has 524288 bytes of physical memory (128 4096-byte frames). Change 524288 to a larger number. The new number may need to be divisible by 4096 (I'm not sure).
• We expect to be able to run these programs using command lines like this:

  % sys161 kernel "p testbin/matmult;q"
  

  as we did for Assignment 2.

I didn't get the A2 system calls working. What can I do?

Most of the testing for A3 will involve only writes to the console and _exit. If you have at least that functionality working from A2, you can work with that, and you can ignore the rest of this section.

If you do not even have console writes and _exit working from A2, you can use the following instructions for a quick-and-dirty implementation of those two system calls. These implementations don't do much (in particular, this _exit simply reboots the machine) but it is enough to support most of the A3 testing.

First, modify the function mips_syscall(struct trapframe *tf) in kern/arch/mips/mips/syscall.c as shown below. Note that you may need to include some header files for this to compile.

mips_syscall(struct trapframe *tf)

  ...

  switch (callno) {
    case SYS_reboot:
      err = sys_reboot(tf->tf_a0);
      break;

    /* BEGIN NEW CODE ------------------------------------------- */
    /* NEW: Simple code to handle writes to console */
    /*   this *only* works for writing null-terminated */
    /*   strings, which should be sufficient to handle */
    /*   printf()s in the application code */
    case SYS_write:
      /* check that the write is to stdout */
      assert(tf->tf_a0 == STDOUT_FILENO);
      kprintf("%s", (char *) tf->tf_a1);
      retval = strlen((char *) tf->tf_a1);
      break;

    /* NEW: Simple code to handle _exit call */
    /* 
    case SYS__exit:
      thread_exit(); /* NOTE: need to modify thread_exit(); */
      break;         /* may require #include <thread.h> */
    /* END NEW CODE ------------------------------------------- */

    /* don't forget to comment out or otherwise disable */
    /* any existing implementation of SYS_write and */
    /* SYS__exit that you may have */

    default:
      kprintf("Unknown syscall %d\n", callno);
      err = ENOSYS;
      break;
  }

void
thread_exit(void)
{
  /* BEGIN NEW CODE ------------------------------------------- */
  /* NEW: just shut everything down */
  extern int sys_reboot(int code);
  sys_reboot(RB_POWEROFF); /* may require #include <kern/unistd.h> */
  /* END NEW CODE ------------------------------------------- */

  /* leave everything else here */

  ...

void
kill_curthread(u_int32_t epc, unsigned code, u_int32_t vaddr)
{
   /* BEGIN NEW CODE ------------------------------------------- */
   /* New: if the current thread gets killed */
   thread_exit();         /* may require #include <thread.h> */
   /* END NEW CODE ------------------------------------------- */

   ...