Telecon 04-12-07

From OSR

(Meeting notes at bottom)

Topic: Helen OS Thoughts

1) Architecture support is impressive.

2) Fairly straight-forward to understand what's going on.

3) Micro-kernel design kernel thread servers for console, scheduling, etc. We desire a self-contained monolithic kernel image, so the match isn't very good.

4) Kernel level contexts managed as tasks, each containing one or more threads. Our current model is to support one thread per CPU and let user level code do threading.

5) Their ADTs (list, hash table, btree, fifo) should be usable.

6) Their page table abstractions should be usable.

      page_mapping_insert(addr_space_obj, virt, phys, flags)
  Implementations for up to 4-level tree-based page tables (x86_64) and hash-table page tables (PowerPC).

7) Their synchronization primitives should be usable.

       Spinlocks
       Sleeping Semaphores
       Condition Variables
       Wait Queues
       Linux-like Futexes (fast user-level locks)

Strategy: I'm currently attempting a reorg of nway to use a directory structure and build system similar to theirs. This is an experiment to see how feasible it is. It has been fairly enlightening so far, if nothing else.

The build system is modified to use a single configuration file and to use the less-verbose build make macro from the nway tree.

Current status is I'm still working through the bootstrap code for both x86 and x86_64. I think I have a pretty good handle on what the x86_64 memory map should look like (see below).

Topic: Memory Map

I'd like to move to a more traditional memory map. Here's what I'm proposing:

For x86:

       Virtual Range          Physical Range
    -------------------    -------------------
    ffffffff - 80000000    7fffffff - 00000000    Kernel
    7fffffff - 00000000       User Specified      User

    Note: Kernel region is an identity map of all of physical memory.

For x86_64:

                Virtual Range               Physical Range
    -----------------------------------   ------------------
    ffffffffffffffff - ffffffff80000000   7fffffff - 0000000   Kernel
       top of mem    - ffff800000000000   mem_top  - 0000000   Kernel MemMap
    00007fffffffffff - 0000000000000000    User Specified      User

   Notes:
   1) Kernel text and data is mapped into top 2GB of the virtual address
      space.  The kernel is compiled using mcmodel=kernel
   2) Kernel MemMap is an identity mapping of all of physical memory.
      This separate mapping is needed because the 2 GB kernel region is
      not big enough on systems with more than 2 GB.
   3) Due to the split, converting a kernel virtual address to a physical
      address becomes:

          if (x > 0xffffffff80000000)
              return x - 0xffffffff80000000;
          else
              return x - 0xffff800000000000;
   4) Linux uses a similar scheme (see Documentation/x86_64/mm.txt)

In addition to the memory map changes, we need some way to track which regions of memory are reserved by the kernel and not available for user mappings. I propose we create a "frame map" that contains one entry for each base page (4KB) in the system. An alternative might be to store reserved pages in a tree and do a search on every mapping.

Meeting Notes

1) Discussed HelenOS. Current plan is to get x86_64 long mode working using their code as an example.

2) Discussed x86_64 memory map. All agreed it seemed OK (need to get Trammell's take). Plan is to hoist kernel up to the top of the virtual memory space.

3) Discussed overall project goals a bit. Focus is on developing a minimal kernel that:

      - Supports many cpus
      - Supports threads
      - Supports NUMA memory (e.g., a fast memory)

Key questions are how much functionality can be moved to user space and what the API exported by the kernel should be. Practical target is our expected next machine but design should also work for different environments.

4) Discussed Charm++. Charm++ requires lots of threads and depends on the OS kernel to some extent to do load balancing. Kurt is going to think about how Charm++ would work on the current nway prototype.