Windows: VMM KV backend fails at first decode (hipMemSetAccess invalid argument) - kv_backend=contiguous works

[SergioSV96]

Windows: VMM KV backend crashes at first decode — hipMemSetAccess: invalid argument; kv_backend=contiguous works

Splitting this from #634 (GGUF naming) since it's an independent Windows runtime issue found during the same bring-up.

Repro

master 80a572c824dc, Windows 11, RX 7900 XTX (gfx1100), ROCm 7.2 HIP SDK. Native registry model, default config (memory.kv_backend unset → resolves to vmm):

PS> hipfire run qwen3.5-0.8b.mq4 "..."
GPU dev 1: gfx1100 (25.8 GB VRAM, HIP 7.2)
KV cache: Q8 vmm (6/24 layers carry KV; ... physical_cap=262144 ...)
  <model loads fully>
hipfire: daemon error: [internal retryable=false ...] forward_scratch decode:
HipError(1): hipMemSetAccess: invalid argument; VMM access prefix
base=0x4408000000 size=4194304 (new segment address=0x4408200000 offset=2097152
size=2097152) granularity=65536

Model load and kernel JIT complete; the failure fires on the first decode's VMM segment commit.

Workaround (verified)

PS> hipfire config set kv_backend contiguous
PS> hipfire run qwen3.5-0.8b.mq4 "..."
KV cache: q8 (6/24 layers carry KV, others placeholder)
<full generation, coherent output>

Suggestion

Either default kv_backend away from vmm when running on Windows HIP (runtime probe at init would be cleaner), or document the knob in GETTING_STARTED's Windows section — nothing today hints that the default allocator is broken on this platform.

[HUSRCF]

@SergioSV96 — thank you for the precise report. I have a diagnostic fix ready in draft PR #643 at exact head 008db8a5.

The reported range is correctly aligned to the Windows-reported 64 KiB granularity. The failure instead occurs on the first growth where hipfire asks hipMemSetAccess to cover a contiguous 4 MiB virtual prefix backed by two independent 2 MiB physical mappings. Linux ROCm 7.2 needs that prefix form because it can reject otherwise-valid non-zero subranges; Windows HIP 7.2 appears to have the opposite limitation and rejects a range spanning mappings.

#643 preserves the prefix call as the primary path. Only when it returns hipErrorInvalidValue does it retry access separately for every physical mapping. Other errors are not masked, and the existing cleanup path remains in force.

Could you please test the exact head on the same Windows RX 7900 XTX machine?

git fetch https://github.com/HUSRCF/hipscope.git fix/windows-vmm-access
git switch --detach 008db8a5
cargo build --release --locked

target\release\hipfire.exe config set kv_backend vmm
target\release\hipfire.exe run qwen3.5-0.8b.mq4 "What is the capital of France? Answer in one short sentence."

Please post the KV cache: line and either the generated text or the complete VMM error. The decisive pass is reaching coherent first-token decode with KV cache: Q8 vmm; the CPU-only fallback tests and our Linux gfx1100 two-segment VMM smoke already pass, but they cannot substitute for the affected Windows HIP runtime.

[harrytyp]

PR #643 fix verified working on RX 7900 XTX / Windows 11 / ROCm 7.2 HIP SDK: cherry-picked onto master (3dec61a2), a 40k-token prefill in VMM mode now completes at 397 tok/s where it previously crashed with hipMemSetAccess: invalid argument at the first segment commit. Fix looks good on this box.