starkernel: item 3.2 -- Stadium boot-time allocation

Punch list §25 item 3.2 complete.

stadium_boot_init() (src/starkernel/vm/stadium.c) sizes the global
cell array at boot from a real memory-budget query rather than a
hardcoded count: pmm_get_stats().free_bytes at the point of
allocation, times the new STADIUM_MEMORY_PERCENT Kconfig symbol
(default 1%), rounded down to whole 64-byte cells. Matches §17.6's
position (b) literally. Also allocates the header/continuation
discriminator bitmap item 3.1 declared but did not allocate. Both are
kmalloc'd and explicitly zero-filled (kmalloc does not zero).

Called from kernel_main.c immediately before sk_vm_bootstrap_parity(),
i.e. before any VM exists (§6). Failure is soft -- logs and continues,
does not halt boot -- matching the existing precedent one line below
it (VM bootstrap parity failure does the same).

Added a "Stadium: N cells (M KB)" boot console line at the allocation
site so the acceptance logs are evidence the array was actually
allocated, not just that the kernel still boots -- the same blind spot
item 3.1's uncompiled-header gap exposed.

Verified: three-architecture boot (amd64, aarch64, riscv64), all
reaching ok> with identical dict_hash=0x3d4e1daf289da94f matching the
item-3.1 baseline, and the Stadium boot line confirmed present in all
three serial logs (amd64: 74234 cells/4639 KB, aarch64: 161329
cells/10083 KB, riscv64: 76122 cells/4757 KB).

Not built here, reported per §25.0 rule 3: per-VM free lists (§22.3)
-- granted when Hera assigns quota, not this item's scope.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-04 16:48:13 -04:00
co-authored by Claude Sonnet 5
parent 1b2f0677de
commit eb0fd4fffa
14 changed files with 31496 additions and 9 deletions
+33 -1
View File
@@ -2705,8 +2705,40 @@ document and committing that amendment as its own item.*
> with identical `dict_hash=0x3d4e1daf289da94f` -- amd64 (`logs/20260804-151032`), aarch64
> (`logs/20260804-151115`), riscv64 (`logs/20260804-151222`).
- [ ] **3.2 — Boot-time allocation.** One global cell array, sized from the memory budget,
- [x] **3.2 — Boot-time allocation.** One global cell array, sized from the memory budget,
before any VM exists. *Refs:* §6, §17.6, §22.3.
> **DONE 2026-08-04.** Sizing ruled by Captain Bob among three options (flat Kconfig
> constant / runtime PMM-derived / `STADIUM_MAX_VM_COUNT × STADIUM_CELLS_PER_VM`):
> **runtime PMM-derived**, matching §17.6 position (b) literally rather than position (a),
> the "arbitrary bound" that section argues against. New `STADIUM_MEMORY_PERCENT` Kconfig
> symbol (default 1%, ruled by Captain Bob) — `stadium_boot_init()` in `stadium.c` reads
> `pmm_get_stats().free_bytes` at the point of allocation, takes that percent, rounds down
> to whole `STADIUM_CELL_BYTES` cells. Both the cell array and the discriminator bitmap
> item 3.1 declared but did not allocate are `kmalloc`'d here and explicitly zero-filled
> (`kmalloc` does not zero — checked `kmalloc.c`, no `memset`). Called from
> `kernel_main.c`, immediately before `sk_vm_bootstrap_parity()` — before any VM exists,
> per §6. Failure is soft (logs, returns -1, does not halt boot): nothing downstream
> consumes the Stadium yet, matching the existing precedent one line below it
> (`sk_vm_bootstrap_parity()`'s own failure path also just logs and continues).
>
> **Made observable, by agreement before writing code** (same blind spot the item-3.1
> uncompiled-header gap exposed): a `Stadium: N cells (M KB)` console line at the
> allocation site, so the three-arch boot's serial logs are evidence the array was
> actually allocated at the size intended, not just that the kernel still boots.
>
> **Regression: clean, and the boot line confirmed present on all three.** All three
> architectures boot to `ok>` with identical `dict_hash=0x3d4e1daf289da94f`, matching the
> item-3.1 baseline. Observed sizes (1% of free memory at the allocation point, this
> session's QEMU configuration): amd64 74234 cells (4639 KB, `logs/20260804-164332`),
> aarch64 161329 cells (10083 KB, `logs/20260804-164432`), riscv64 76122 cells (4757 KB,
> `logs/20260804-164537`). Reported, not evaluated against §23.3's ~4096-cells-per-VM
> illustrative figure — that figure is itself labeled a proposal to validate, not a target
> this item is scored against.
>
> **Explicitly not built here, reported per §25.0 rule 3:** per-VM free lists (§22.3, "each
> VM holds its own free-list head index into the global array") — those get granted when
> Hera assigns a VM its quota, which is not this item's scope.
- [ ] **3.3 — Behaviour enumeration and dispatch.** Closed tag set fixed at build time.
Enumerate behaviours, never patron kinds. *Refs:* §13, §18.3.
- [ ] **3.4 — Density ranking.** Heat ÷ mass, read not computed. *Refs:* §19.2, §19.3.