vregion: Disable virtual regions on ACE 2.0 and earlier

[jsarha]

The virtual memory heap does not work properly on MTL or LNL and effectively the system from functioning due to virtual memory heap allocations failing when the demand for module memory is high, like in this test:

TPLG="/lib/firmware/intel/development/sof-lnl-nocodec.tplg" MODEL=LNLP_RVP_NOCODEC SOF_TEST_INTERVAL=10 ~/sof-test/test-case/multiple-pipeline.sh -f a -c 20 -l

Disable virtual memory heap for ACE 2.0 and earlier as quick remedy to the problem. With proper tuning it may be possible to get VMH working on these platforms too.

Fixes: b3d0c47 (vregion: Add support for per pipeline/module virtual regions)

[Copilot]

Pull request overview

Disables the virtual regions feature by default on older Intel ACE platforms (ACE 2.0 and earlier) to mitigate memory allocation failures under high module/pipeline memory pressure.

Changes:

• Updates SOF_VREGIONS default selection to exclude ACE 1.5 (MTL) and ACE 2.0 (LNL).

Comments suppressed due to low confidence (1)

zephyr/Kconfig:266

• PR description mentions disabling the virtual memory heap (VMH) on ACE 2.0 and earlier, but this change only adjusts the default for SOF_VREGIONS. If the intent is specifically to address VM heap allocation failures, consider also updating VIRTUAL_HEAP’s default (or update the PR description to match what’s being disabled).

config SOF_VREGIONS
	bool "Enable virtual memory regions"
	default y if ACE && !ACE_VERSION_1_5 && !ACE_VERSION_2_0
	depends on ACE
	help
	  Enable the virtual regions memory allocator for pipeline resource management.
	  This provides a way to manage memory resources for audio pipelines,
	  including
	    1) multiple pipeline static lifetime allocations.
	    2) runtime pipeline allocations.

config VIRTUAL_HEAP
	bool "Use virtual memory heap to allocate buffers"
	default y if ACE

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The default condition references ACE_VERSION_1_5 and ACE_VERSION_2_0, but these symbols are not defined anywhere in this repository’s Kconfig files. If they’re not provided by the external Zephyr tree, Kconfig will treat them as undefined (effectively n), making the condition equivalent to default y if ACE and/or emitting undefined-symbol warnings. Please confirm the correct Kconfig symbols for MTL/LNL in the build (or define them here) so the default actually disables vregions on ACE 1.5/2.0.

Suggested change

	config ACE_VERSION_1_5
	bool
	default n
	help
	Hidden platform/version selector for ACE 1.5 based builds.
	config ACE_VERSION_2_0
	bool
	default n
	help
	Hidden platform/version selector for ACE 2.0 based builds.

[jsarha]

It seems this time AI is not hallucinating things that are not there, but it is not seeing things that are there in src/platform/Kconfig .

[lyakh]

I suppose we can do this for now. I think MTL and LNL would benefit from vregion style mod_alloc() which we're going to implement, but we can also re-enable it later once such an implementation has been merged

[lyakh]

In fact I'd like to understand how b3d0c47 breaks MTL and LNL. That commit is only supposed to take unused memory, not reducing the RAM used for heap or VMH. Apparently I'm misunderstanding something, would be good to know what exactly

[softwarecki]

The provided description does not appear to match the actual proposed changes. The change disables SOF_VREGIONS, which affects compilation of vregion.c and vpage.c. However, the description incorrectly states that VMH (Virtual Memory Heap) functionality is being disabled. VMH has been in active use for years and is not removed or turned off by this change.

[abonislawski]

Commit b3d0c47 also increases CONFIG_MM_DRV_INTEL_VIRTUAL_REGION_COUNT for MTL/LNL, is this intentionally not reverted?

But honestly not sure if there is a real need to differentiate platforms this way.

[jsarha]

Commit b3d0c47 also increases CONFIG_MM_DRV_INTEL_VIRTUAL_REGION_COUNT for MTL/LNL, is this intentionally not reverted?

But honestly not sure if there is a real need to differentiate platforms this way.

In fact the test case in question passes successfully if CONFIG_MM_DRV_INTEL_VIRTUAL_REGION_COUNT is 2, even if vregions is enabled. But for some reason the same is not enough LNL (@lyakh can you explain why?) . I just wanted make the minimum change to make our test suite to complete successfully again.

[abonislawski]

But what is your actual error/fail?
vregion is not used anyway and on MTL/LNL it even fails to init in vpage_init because of remaining_ram underflow.

[jsarha]

But what is your actual error/fail? vregion is not used anyway and on MTL/LNL it even fails to init in vpage_init because of remaining_ram underflow.

@abonislawski , All allocations starting to fail:

[ 4301.148571] <inf> [core 0] ipc: ipc_cmd: rx	: 0x450a0005|0x9000011
[ 4301.148640] <inf> [core 0] ipc: buffer_new: buffer new size 0x300 id 9.65537 flags 0x0
[ 4301.148656] <err> [core 0] buffer: buffer_alloc_struct: could not alloc structure
[ 4301.148660] <err> [core 0] buffer: buffer_alloc: could not alloc buffer structure
[ 4301.148678] <err> [core 0] ipc: ipc_comp_connect: failed to allocate buffer to bind 0xa0005 to 0x11
[ 4301.148688] <err> [core 0] ipc: ipc_cmd: ipc4: MODULE_MSG failed with err 3
[ 4301.149235] <inf> [core 0] ipc: ipc_cmd: rx	: 0x460b0005|0xc0005
--
[ 4301.165060] <wrn> [core 0] host_comp: host_get_copy_bytes_normal: comp:10 0xb0005 Skipped 2 no-bytes events in last 3 ms, bytes 768
[ 4301.165238] <inf> [core 0] ipc: ipc_cmd: rx	: 0x400c0005|0xb0015
[ 4301.165315] <err> [core 0] module_adapter: module_adapter_mem_alloc: failed to allocate memory for comp_dev
[ 4301.165326] <err> [core 0] ipc: ipc4_init_module_instance: error: failed to init module 5 : c
[ 4301.165338] <err> [core 0] ipc: ipc_cmd: ipc4: MODULE_MSG failed with err 104
[ 4301.165666] <inf> [core 0] ipc: ipc_cmd: rx	: 0x120b0000|0x0

There is more details in JIRA-1601