memory: the e820 work, and why the extended suite flaps

Records the measured effect of the region-based allocator (2.2x on a cold
ls, 6 s off the boot), the two pre-existing UEFI blockers found while
verifying it, and the three confounds that each produced a confident
wrong answer about guest speed in one session.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.claude/memory/schos-uefi-loader.md

@@ -1,8 +1,10 @@
 ---
 name: schos-uefi-loader
-description: boot/uefi works under OVMF; the SCH64 entry, the GDT trap, and the one open bug (e820 fragmentation)
-metadata:
-  node_type: project
+description: "boot/uefi works under OVMF; the SCH64 entry, the GDT trap, and the one open bug (e820 fragmentation)"
+metadata: 
+  node_type: memory
+  originSessionId: d4821aa9-2e49-40da-91e7-90ef9ed9997e
+  modified: 2026-08-09T19:05:15.325Z
 ---
 
 **`boot/uefi/` boots.** `make uefi`, `make esp`, `make qemu-uefi`. Verified
@@ -42,17 +44,46 @@ arriving in long mode is still on the firmware's descriptors; the first thing
 needing the kernel's own selectors faulted with `unexpected trap 13 ... cs=38`,
 a long way from the cause.
 
-## Open bug: the memory map
+## The memory map — fixed 2026-08-09
 
-`e820_init` takes the usable run **containing the kernel**. Under OVMF that run
-ends at 8 MB — the firmware places an ACPI NVS region at 0x800000, so it is
-genuinely fragmented. The loader's map is truthful and untruncated (21 entries);
-the one-contiguous-run assumption is BIOS-shaped.
+`e820_init` used to take the usable run **containing the kernel**, which under
+OVMF ends at 8 MB because the firmware puts an ACPI NVS region at 0x800000.
+That failed the `PHYSTOP_MIN` check, so the kernel fell back to asserting
+224 MB it had not measured and then freed straight through the reserved hole.
 
-**Fix: have the kernel free each usable region rather than one range.** That
-touches `kalloc`/`freerange` and `kinit1`, which is the most safety-critical
-code in the tree — it deserves its own change with both boot paths verified,
-not the tail of a session.
+The kernel now keeps the usable regions as a **list** (`mem_usable[]` /
+`nmem_usable` in memlayout.h) as well as a top address, and `kinit1` frees each
+one clipped to the window `main()` passes in. `PHYSTOP` still means exactly what
+it did, so no call site changed. `phystop` comes from the **largest** region,
+not the highest, because the DMA arena is carved off the top of it and must be
+contiguous; a smaller region above it is deliberately left unfreed rather than
+raising the bound past a hole.
+
+Result: 1018 MB in 7 regions under OVMF, 1023 MB in 2 under BIOS.
+
+**It is also a large speedup, which was not the goal and is worth knowing.**
+Measured from inside the guest (`/proc/uptime`, fresh image each boot,
+alternating rounds): boot to prompt **14.8 s vs 21.2 s**, and a cold
+`ls /bin | wc -l` **23.6 s vs 51.2 s** — 2.2x. Both rounds agreed within
+0.3 s. So if the allocator ever looks slow again, this is the baseline to
+compare against.
+
+## What still stops a full UEFI boot
+
+Two separate, pre-existing problems — neither is the memory map, and both
+predate the e820 work (the unfixed kernel triple faults in the same place):
+
+1. **virtio-gpu's BAR lands above 4 GB.** OVMF assigns the 64-bit BAR high;
+   the first MMIO write faults with `CR2` around `0xffff80c000000014`, which is
+   `P2V` of physical **768 GB**, far outside the 4 GB direct map `kvmalloc`
+   builds from four 1 GB pages. Then a double fault, then a triple fault and a
+   reboot loop. SeaBIOS assigns it low, so the BIOS path never sees it.
+   **Drop `-device virtio-gpu-pci` to boot UEFI past this.**
+2. **Boot stalls after `cpu0: starting`**, before `schfs: mounted`. Under UEFI
+   the ESP is hd0 and schfs.img is hd1; the root never mounts. Not diagnosed.
+
+`cpu0: starting` remains the UEFI high-water mark, now reached with a truthful
+memory map rather than a fabricated one.
 
 ## Testing