reclaiming uefi memory

docs/frame-allocator.md

@@ -100,12 +100,25 @@ The `free frames` MiB agreeing with the memory map's `usable RAM`, the three
 distinct consecutive addresses, and the count returning to its start after freeing
 are the three signals that init, alloc and free are all correct.
 
+## Boot-services memory comes pre-reclaimed
+
+The UEFI boot-services memory (~44 MiB) is defunct and free once
+`ExitBootServices` runs, taking usable RAM from ~76 MiB up to ~121 MiB. The frame
+allocator does **nothing special** to get it: the loader already classified it as
+`usable` (see [memory-map.md](memory-map.md)), so it's just part of the `usable`
+regions `init` frees. Keeping that boot-protocol knowledge on the loader side is
+deliberate — the kernel has no notion of "reclaimable" or of UEFI at all.
+
+The one live piece in that memory is the boot stack the kernel starts on; the loader
+leaves the single region containing it `reserved`, so `init` won't hand it out. A
+later step will move task 0 onto a kernel-owned stack, freeing that last ~1 MiB
+region too (and giving user mode the clean stack it wants).
+
 ## What's next (not done here)
 
 - **Contiguous allocation** — scan for N consecutive free bits — for callers that
   need physically adjacent frames.
-- **Consumers**: the virtual memory manager / page tables and then the kernel heap
-  will be the first real users, each asking `alloc()` for frames.
-- **Reclaiming `reclaimable`** (UEFI boot-services) memory, and eventually the
-  `reserved` `loader_data` (kernel image, boot buffers) once nothing needs it —
-  see the deferred list in [memory-map.md](memory-map.md).
+- **A kernel stack for task 0**, so the boot stack's region can be freed too (and
+  for the clean stack user mode wants).
+- **Freeing the `reserved` `loader_data`** (the boot-time map buffers) once the
+  kernel is done reading the memory map.