Multiboot memory detection fixes
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 15 Aug 2013 00:17:39 +0000 (17:17 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 15 Aug 2013 00:17:39 +0000 (17:17 -0700)
commitba5ee8edbcc1b1dcef6c0939a81363d68bf9e211
tree6695d349fc5c695b7b57b6545330b626da51bcd2
parente2646976a1c5d335c5ae27950b9417fb8e2eea51
Multiboot memory detection fixes

A few things:
- Multiboot's regions don't cover all of physical memory; it has holes.  We now
  init the pages[] array (for x86) to mark all pages as busy, and explicitly
  mark the free pages.
- The previous version of this worked a little, since the unmarked, non-free
  pages weren't on any free page lists.  However, the contiguous memory
  allocator (which is really lousy btw) looks directly at refcnts, bypassing
  the lists.
- One problem is that there is a big chunk of unusable memory around 0xfec00000
  (IOAPIC and friends).  This was working okay with multiboot's memory
  mappings, but not with qemu's "here's a lot of memory" approach.  In lieu of
  doing full-fledged memory detection/probing, I'm just ignoring physical
  memory from [0xc0000000, 0xffffffff].  This only applies to qemu, when
  launched with the -kernel flag.
- 32 bit had some other issues when giving out memory near the 4GB mark, as
  well as having other issues with 64 bit addresses (note some of the changes
  from %p to 0x%016llx).
- The bug with giving out pages that were mapped to IO/BIOS/x86 magic regions
  in high memory showed up as clobbered bookkeeping in small slab pages in
  kmem_cache_grow() (stored at the end of the pages improperly allocated).
  Good times!
kern/arch/x86/page_alloc.c
kern/arch/x86/ros/mmu32.h
kern/src/multiboot.c