1. 19 Dec, 2016 2 commits
  2. 26 Oct, 2016 7 commits
    • Charles Jacobsen's avatar
      test-v2: RAM map tests pass. · c543053a
      Charles Jacobsen authored
      Couple duplicate memory interval tree inserts/deletes were leading
      to some use-after-frees/page faults. Cleaned that up. Added some
      resource tree debug code along the way.
      
      Also, caught something subtle (noted in code). I didn't consider
      the following scenario: Heap tries to allocate pages; the allocator
      notices it needs to bring in more fresh pages, and notifies the
      heap (via a callback); the heap allocs the fresh pages (from the
      microkernel), maps them, and inserts those pages into the memory interval
      tree; the memory interval tree kmallocs a tree node; kmalloc
      calls back into the heap to grow a slab cache.
      
      That last bit could be a potential problem (recursive call back
      into the heap before we finish the original call). Lucky for me,
      I designed the heap/allocator so that (1) the pages from the first
      call are already marked as in use (not on a free list); (2) the
      fresh pages are mapped first *before* inserting the corresponding
      cptr into the memory interval tree.
      
      The Linux kernel deals with these same recursive issues (they
      resolve them using special GFP_ flags so that you don't get
      recursion). In my case, the recursion is risky, but works.
      c543053a
    • Charles Jacobsen's avatar
      test-v2: kmalloc tests pass, big page alloc test passes. · 42ad48cc
      Charles Jacobsen authored
      Caught a bug in heap allocator - wasn't setting an out
      parameter (that design pattern I use - out params - will be the
      death of me).
      
      Updated max page allocation order to match the host. The microkernel
      uses the host page allocator, so that is the only limiting
      factor now (so e.g., on x86_64, you can now allocate up to
      2^10 = 1024 pages = 4 MBs inside the LCD, and this is the maximum
      you could allocate in non-isolated code too). Before, the allocation
      size was limited to about 2^6 = 64 pages = 256 KBs.
      42ad48cc
    • Charles Jacobsen's avatar
      4ca91d0c
    • Charlie Jacobsen's avatar
      0d822f1c
    • Charlie Jacobsen's avatar
      a94f0e92
    • Charlie Jacobsen's avatar
      liblcd-v2: Fix generalized page alloc metadata alloc/free. · 2979d763
      Charlie Jacobsen authored
      It seemed dumb to have the generalized page allocator code
      repeatedly call out to the user to get memory for metadata.
      For one thing, it was buggy. For another, in many use cases
      we can alloc the metadata in one shot.
      
      RAM map allocator partially started.
      2979d763
    • Charlie Jacobsen's avatar
      liblcd-v2: Make room for RAM map region (separate from heap). · b9ce0034
      Charlie Jacobsen authored
      This is kind of like an mmap region, but only for RAM. (The guest
      virtual page tables will be configured for write back).
      
      Use case: You get a RAM capability from some other guy, and you
      want to map it into your physical/virtual address space. This is
      reasonable to figure out manually for big RAM chunks that are
      mapped one/two times. But for little tedious ones (string sharing),
      it's helpful to have an allocator to assist and track free parts
      of guest physical.
      
      The RAM map region uses very course-grained physical address space
      allocation (minimum 64 MBs). This leads to a lot of internal
      fragmentation, but it should be tolerable since the region is big.
      It also means we have a smaller bit of metadata for tracking the
      region.
      b9ce0034