fix(vmm): map full reservation in one segment on Windows

[harrytyp]

Problem

hipMemCreate/hipMemMap on Windows/ROCm 7.2 (gfx1100) maps a second, later segment onto the same physical pages as the first. The repo's own vmm_arena_smoke example panics at its boundary-growth assert (line 68) after the 2nd map_next — segment 1 aliases segment 2's pages — while single-segment maps pass.

The KV cache grows in ~1900 small map_next steps, so on Windows every growth corrupts all prior KV. This surfaces as token soup ("!!!!!!!!") from every model (qwen3.8:27b, qwen3.5:0.8b, lfm2.5:1.2b) in hipfire serve. Full repro and discussion: #655, #644.

Fix

Under #[cfg(windows)], alloc_vmm_tensor maps the full reservation in one map_next instead of growing in small segments. Linux behavior is byte-identical to before (the cfg block does not exist there).

Trade-off: costs full VRAM up front (no on-demand commit) on Windows only. This is a workaround for what looks like a ROCm-Windows VMM runtime bug — both mappings report distinct virtual addresses via hipMemGetAddressRange, yet share physical pages.

Validation (gfx1100, RX 7900 XTX, Windows 11, ROCm 7.2)

• Output correct after fix: 17*23 → 391, fluent prose, no token soup
• vmm_arena_smoke passes on the single-segment path; multi-segment growth assert is the repro for the underlying runtime issue
• AR decode ~40 t/s, DFlash draft ~48 t/s, 40k+ prefill completes without Windows: VMM KV backend fails at first decode (hipMemSetAccess invalid argument) - kv_backend=contiguous works #635 crash
• No perf claim vs baseline (baseline output was corrupt by construction)

HW-gate routes

• scripts/serve_harness.py: generation/state-lifecycle changed? No (dispatch/VMM allocation only)
• scripts/redline_daemon_harness.py: kernel/dispatch change? Yes — dispatch-layer VMM allocation path

[HUSRCF]

Thanks for putting this together and, especially, for validating it on the affected Windows/gfx1100 machine. The single-mapping workaround is consistent with the vmm_arena_smoke evidence and looks like the right safety policy for the affected runtime.

One small implementation detail may be worth adjusting before merge. The current Windows override uses:

#[cfg(windows)]
let initial_mapped_bytes = byte_size;

VmmArena::reserve rounds the requested byte size up to the HIP VMM allocation granularity, while VmmArena::map_next requires its size to be an exact multiple of that granularity. Therefore, a caller whose logical byte_size is not already aligned could still fail on Windows even though the reservation itself is valid.

Would it be safer to map the actual rounded reservation instead?

#[cfg(windows)]
let initial_mapped_bytes = arena.reserved_bytes();

This preserves the intended policy—one physical mapping covering the entire Windows reservation—while also keeping alloc_vmm_tensor correct for shapes whose logical byte size is not VMM-granularity aligned. The existing Qwen KV layout may happen to be aligned, but this API is shared by other VMM tensor callers as well.

[Kaden-Schutt]

Prepared integration/pr737-windows-fullmap at d827d03, based on your full PR history, with two fixups: use arena.reserved_bytes() directly, and migrate VMM smoke/tests to the Windows full-map contract (plus a 4097-byte roundtrip regression). Independent review caught the old smoke still expecting partial mapping/growth. Linux gfx1201 4097-byte GPU regression passes; this does NOT validate the Windows branch. Before beta landing, please run on Windows ROCm 7.2: cargo run -p rdna-compute --example vmm_tensor_smoke; cargo test -p rdna-compute --lib vmm_ -- --nocapture --test-threads=1; then your real serve/KV corruption reproduction and applicable capture/parity route. Please attach exact tested SHA and decoded output. Candidate: https://github.com/warpfront/hipfire/tree/integration/pr737-windows-fullmap . No Windows execution host is available in this session, so holding rather than claiming proof.

[Kaden-Schutt]

Landed corrected #737 into beta0db445ecb with original PR commits, reserved_bytes alignment fix, migrated full-map smoke/tests and generated crate-map refresh. Maintainer explicitly waived the remaining Windows-host validation requirement. Fresh merged-tree 4097-byte GPU roundtrip regression passed on Linux/gfx1201/HIP7.15; Windows execution is NOT claimed.