vpage: fix region size underflow, free tracking, and enable vpages on NVL-S

[lgirdwood]

Fixes the NVL-S vpage_alloc failed -22 ... total 1048294 free 1048294 seen in the daily-nvl-s CI run.

Root cause

vpage_init() computed the region size as an unsigned subtraction L2_end - (unused_start + virtual_heap + library). On NVL-S (2MB L2, default 0x140000 heap + 0x100000 library) that underflows by 0x11a000 into a 0xFFEE6000 byte (1048294 page) region whose end wraps the 32-bit address space. sys_mm_drv_map_region_safe() then fails virt + size <= region_end for every address, so every vpage_alloc() returns -EINVAL and vregion falls back to the heap. It is not a leak: the first page (0xa023a000) is always chosen because nothing is ever allocated.

Changes

1. Bounds-check the layout instead of underflowing; if nothing fits, leave vpages disabled and fail cleanly with -ENODEV.
2. Enable vpages on small-L2 platforms: the virtual heap and library regions are only virtual address space, so when they do not fit in L2 place the vpage region after the virtual heap, end it at CONFIG_LIBRARY_BASE_ADDRESS (or end of virtual memory), capped by the physical L2 left after the image. Layouts that fit in L2 are unchanged.
3. Fix vpages_free_and_unmap() moving velems[num_elems_in_use] (one past the last element) over the released slot. Freeing a non-last allocation orphaned the last element; the next alloc overwrote its tracking entry and it could never be freed (leaked virtual + physical pages).
4. Release pages already mapped when a multi-page map fails; the mm driver leaves them mapped, leaking physical L2.
5. Add vpage_free_out_of_order boot test.

Testing

• Builds for intel_adsp/ace40/nvls (xt-clang, full link) and the vpage object for nvl and ptl.
• For the NVL-S layout this gives a non-empty region (232 pages with the xt-clang image, ~294 with the CI image); previously it underflowed.
• NOT yet run on hardware: needs a boot on ba-nvls-rvp to confirm the vpage: region ... log line, the boot test, and check-playback-all-formats.
• Note: the vpage errors may not be the cause of the 25-test CI failure cascade (vregion has a heap fallback); that needs the mtrace checked for heap exhaustion.

Draft until tested on NVL-S.

🤖 Generated with Claude Code

[lgirdwood]

@harajend fyi - pls let me know if this helps.

[Copilot]

🟡 Changes recommended

Region boundary handling still has edge-case bugs, and the new regression test does not detect the original leak.

3 open findings

• Honor library base when computing virtual page range · New
• Revalidate RAM size after physical-memory cap · New
• Fix test to detect leaked middle page · New

What changed in this PR

Fixes vpage sizing and allocation tracking, including NVL-S support.

Changes:

• Prevents virtual-region size underflow.
• Cleans up partially mapped pages and fixes out-of-order frees.
• Adds an out-of-order free boot test.

File	Description
zephyr/​lib/​vpage.c	Updates region sizing, cleanup, and allocation tracking.
zephyr/​test/​vpage.c	Adds an out-of-order free regression test.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[intel-sofci]

PR 11303: test results

Run date: 2026-10-14 07:36 UTC

Tested commit: b6f127a467cf69bff8316170c8910770bd21d50c

[harajend]

@harajend fyi - pls let me know if this helps.

@lgirdwood

Tested commit b6f127a46 via intel-innersource CI run
38693960124
on both NVL-S DUTs (ba-nvls-rvp-01, ba-nvls-rvp-02).

This issue is not fixed. All playback/capture tests still fail on both
boards with a DSP firmware crash (EXCCAUSE 29 store prohibited) triggered
on the first pipeline-create IPC, halting DSP core 0 with no recovery.

Detailed analysis:

CI failure: DSP firmware crash on NVL-S (regression vs. previously-reported bug)

Tested commit b6f127a46 via intel-innersource CI run
38693960124
on both NVL-S DUTs (ba-nvls-rvp-01 SoundWire, ba-nvls-rvp-02 HDA).

Result: All playback/capture-dependent test cases fail on both boards with an
identical, reproducible DSP crash triggered by the very first pipeline-create IPC:

<inf> [core 0] vregion.vregion_create: new at base 0xa023a000 size 0x12000 pages 18 metadata at 0x400fdd80
<inf> [core 0] ipc.ipc_cmd: rx: 0x40000004|0x15
<err> [core 0] os.print_fatal_exception:  ** FATAL EXCEPTION
<err> [core 0] os.print_fatal_exception:  ** CPU 0 EXCCAUSE 29 (store prohibited)
<err> [core 0] os.print_fatal_exception:  **  PC 0xa007ef38 VADDR 0xa0031050
...
<err> [core 0] os.z_fatal_error: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
<err> [core 0] zephyr.k_sys_fatal_error_handler: Halting system

Identical PC/backtrace/address on both boards → deterministic firmware bug, not
hardware/board-specific noise. DSP core 0 halts and never recovers (unlike a
suspend/resume cycle, which does not bring it back here).

This looks like a regression against a previously-filed bug, not a fix

We have an existing internal bug report (BUG_REPORT_NVL-S_vpage_alloc.md,
CI run 38194969857, firmware beeac4752) describing a failure at the
exact same virtual region 0xa023a000:

<err> [core 0] vpage.vpages_alloc_and_map: error: failed to map virtual region 0xa023a000 ..., error -22
<err> [core 0] vpage.vpage_alloc: vpage_alloc failed -22 for N pages, total 1048294 free 1048294
<err> [core 0] pipe.pipeline_new: Failed to create pipeline vregion of X bytes, using heap

In that prior report, the failure was graceful: vpage_alloc() returned
-22 (EINVAL), the firmware fell back to heap allocation, and the DSP stayed
alive (recoverable via a suspend/resume D0→D3→D0 cycle).

With this PR, the same 0xa023a000 region now produces a hard CPU
exception (store prohibited) and a full core halt, with no recovery path
short of a host reboot.

Hypothesis: this PR enables actually mapping/using the vpage region
instead of returning EINVAL, but something writes into 0xa023a000 /
VADDR 0xa0031050 without the mapping having succeeded (or before it's
committed), so the previously-tolerated error case is now a hard store fault
instead of a handled error return.

Suggested next step

Please check the map-then-use ordering / error handling around
vregion_create() / vpages_alloc_and_map() for the small-L2 (NVL-S) path —
specifically whether the metadata write (metadata at 0x400fdd80) or first
use of the new vregion happens before/without confirming the map succeeded.