Haskell

Recent site activity

Running userland processes

posted Dec 12, 2008 3:13 AM by Wei Hu   [ updated Dec 15, 2008 12:18 PM ]
As stated previously, House doesn't support file systems and the files must be loaded in memory by Grub. Then, you can do "run prog_name" in the shell.

The control flow of running a userland process is roughly:
execute3 (House.hs): interprets commands typed in the shell
buildUProc (UserProc.hs): sets up the context for the user process in a UProc data structure
    buildAOut (AOutModel.hs): sets up the entry point and the segments
execUProc (UserProc.hs): runs "UProc", in a CPS style
    execContext (UserMode.hs)
    execute (userspace.c): handles the magic context switching

More information can be found in the paper (Section 3,4,7).

I found two bugs in the code. Below is the bug report I sent to the maintainer:

To trigger the first bug, just run any program after you boot into the
shell. You'll get an error saying "Invalid page fault at 40000000."
This error happens when the process starts up and tries to access the
stack -- %esp points to 0x40000000 at startup. The valid stack range
and %esp are initialized by buildUProc defined in UserProc.hs. Because
inVRegion, the function that determines if an address is within a
given range is defined as [lower_bound, upper_bound), we should point
%esp to (endStack - 4), rather than endStack.

After fixing this bug, we can trigger the second bug by allocating <=
128M memory to the VM. Technically, this is not really a bug -- the
user processes run with no problem if the VM has >128M memory.
However, this is a bug in the sense that this behavior contradicts the
documentation and the paper. The paper suggests that user processes'
physical memory is allocated at 32M and above. However, the actual
code allocates the pages at 128M and above. This behavior is very
confusing to newcomers. I changed the USER_SPACE macro defined in
config.h back to 0x02000000 /* 32M */, and the user processes run just
fine. I'm wondering why we start user pages from 128M? Is it just for
safety so that the Haskell heap has enough space to grow? Do we have a
precise idea how much space the Haskell heap consumes?