Code to decode pipeline create messages payload by jsarha · Pull Request #10265 · thesofproject/sof

jsarha · 2025-09-26T11:52:33Z

Code to decode pipline create messages payload. E.g. this code is written to test this PR: thesofproject/linux#5537

lgirdwood

LGTM, we can followup with the allocations per pipeline or domain later.

jsarha · 2025-12-03T19:41:39Z

@lgirdwood this is now updated so that it should be almost exact match to #10281 , vpages code only needs to use the params passed to pipeline_new(). But to use this the topology should be built from this PR and you need my linux driver PR #10281 too to pass down the topology info.

jsarha · 2025-12-14T23:19:20Z

This version address the changes requested to thesofproject/linux#5537 . I still need to move the module init payload decoding to happen already before module_adapter_mem_alloc() -call, before this is ready.

jsarha · 2025-12-16T16:01:08Z

Finaly the module init payload decoding is happening where it should be. Ready for review.

jsarha · 2025-12-16T16:03:58Z

@lgirdwood should I rebase this or is it better to keep it on top of older base still?

lgirdwood · 2025-12-16T16:25:34Z

@lgirdwood should I rebase this or is it better to keep it on top of older base still?

Best to rebase and adding @ranj063

lgirdwood

Just minor opens from me.

lgirdwood · 2026-01-05T15:20:52Z

+#ifdef CONFIG_DCACHE_LINE_SIZE
+	if (!IS_ENABLED(CONFIG_LIBRARY))
+ sys_cache_data_invd_range((__sparse_force void __sparse_cache *)data,
+ ipc_config.ipc_config_size);


can you align up the size to cache line size.

and also check size < mailbox size

can you align up the size to cache line size.
@lgirdwood all cache operations do that internally, don't see a need to duplicate that.

can you align up the size to cache line size.
@lgirdwood all cache operations do that internally, don't see a need to duplicate that.
this always assumes the underlying HALs will round up/down rather than just wrapping the ISA instruction and passing a pointer and size. Best practice is to force the developer to understand exactly what is being invalidated.
@jsarha btw, this would also include the start data pointer is aligned.

this always assumes the underlying HALs will round up/down rather than just wrapping the ISA instruction and passing a pointer and size. Best practice is to force the developer to understand exactly what is being invalidated.
@lgirdwood sorry, I disagree. Let's look at the ISA, which says, e.g. for DCWB: "the line containing it is written back" - so, ISA itself takes cache lines, regardless what address you pass - because what else could it do? And we have an API, which is defined as "give us an address range, we'll invalidate respective cache lines for you" - the called isn't supposed to know anything about cache line sizes.

yes, the ISA will do that on xtensa (and probably most others) but how many times in the past have we been bitten by INV/WB the wrong address/size and been clobbered because we are not forced to think exactly what memory we are performing the cache operation on.
If we explicitly round up/down we are forced to consider whats before start address and whats after start_address + size.
I'm asking not about code correctness but about better process when we come to manual cache ops.

@lgirdwood we have been bitten by this when allocating memory with different cache policies, when then manipulating (invalidating or writing back) cache of one object and corrupting adjacent objects, sharing cache lines. But we don't do that when actually manipulating caches. Please just run git grep -A1 "writeback_region\|invalidate_region\|sys_cache_data_.*range" |less in the SOF tree and you'll see.

@lyakh sorry, we need to have better process here, this change will work today but if the IPC base address or IPC size change then we can have hard to debug problems. e.g. via introduction of dynamic mailbox and IPC updates.
I really want a
CACHE_ALIGN_UP()
and down() that can warn on non alignment and can be used for all cache ops users. This warn would be enabled by Kconfig and warn the developer.
@jsarha can you confirm if the size is being validated here as its being passed in by IPC.

@lgirdwood there is no CACHE_ALIGN_UP(), is there? Not alteast in out sof/main or matching zephyr. I'll go with ALIGN_UP(ipc_config.ipc_config_size, CONFIG_DCACHE_LINE_SIZE).

lgirdwood

@jsarha pls confirm if ipc size is validated before cache op, lets circle back to cache process later as we need to merge this PR since it's blocking other stuff.

lgirdwood · 2026-01-08T16:06:52Z

+#ifdef CONFIG_DCACHE_LINE_SIZE
+	if (!IS_ENABLED(CONFIG_LIBRARY))
+ sys_cache_data_invd_range((__sparse_force void __sparse_cache *)data,
+ ipc_config.ipc_config_size);


@lyakh sorry, we need to have better process here, this change will work today but if the IPC base address or IPC size change then we can have hard to debug problems. e.g. via introduction of dynamic mailbox and IPC updates.
I really want a
CACHE_ALIGN_UP()
and down() that can warn on non alignment and can be used for all cache ops users. This warn would be enabled by Kconfig and warn the developer.
@jsarha can you confirm if the size is being validated here as its being passed in by IPC.

jsarha · 2026-01-09T21:58:15Z

Rebased and addressed @lgirdwood 's comment. Also moved "ipc4: helper: Do not invalidate cache of whole mailbox for module init" invalidation to its original place and used MAILBOX_HOSTBOX_BASE as the base address instead of data, to make it obvious that the address is cache line aligned.

jsarha · 2026-01-11T23:18:50Z

Message box size checks for cache invalidation added.

lgirdwood

LGTM

jsarha · 2026-01-12T22:12:39Z

@lgirdwood , before mergin this it would be good to at least get couple of approvals here too: thesofproject/linux#5537

kv2019i

Please check one squash command in a git commit. Otherwise, we need to get the CI through (now build failed, not related to this PR but it blocks testing), but otherwise looks good.

lgirdwood · 2026-01-26T13:56:49Z

@jsarha some red on CI, can you check, think we are good to go. Thanks !

jsarha · 2026-01-26T20:50:13Z

@jsarha some red on CI, can you check, think we are good to go. Thanks !

@lgirdwood I can not find any sane error logs about any of the failures, and suspend-resume appears to be the only failure concistently repeating. I'll trigger the CI again to hope to see some more concistetn resultes.

(Its unlikely my code would cause any specific failure, since its not used in our CI tests. There is no topologies setting the attributes or DP components using them, and the Linux kernel used is not even able to send pipeline create payloads.)

jsarha · 2026-01-26T20:50:22Z

SOFCI TEST

lgirdwood · 2026-01-27T10:55:02Z

@lrudyX good to merge, other CI looks good ?

…code() Use %zu in size_t prints in module_ext_init_decode(). Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Add lifetime_bytes_requirement and shared_bytes_requirement widget attributes. This token's value indicates the amount of heap memory needed at component initialization phase. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Adds structs and definitions for adding a payload to struct ipc4_pipeline_create message. The structure of the payload is very similar to struct ipc4_module_init_ext_init payload for struct ipc4_module_init_instance. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Add ipc4_create_pipeline_payload_decode() and call it if struct ipc4_pipeline_create's extension.r.payload bit is set. The function decodes the message payload, logs the contents, but does not store the information anywhere. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Invalidate cache for only the module init payload size not the whole mailbox. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Pass create pipeline payload parameters down to pipeline_new() by using struct pipeline_params. That is the place where the data will be used. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

…mory Add default values for stack, lifetime heap, interim heap, and shared memory sizes for all widgets, e.g. module instances. These values were tested with vpages branch and all cases that I tried worked with them. Eventually each module should be added with more accurate values, based on measurements. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

…data Update struct ipc4_module_init_ext_obj_dp_data to match what is required for latest user space features. This is a tricky change as it chenges already part of ABI. However, as the structure was not really used for anything before, changing it should be safe. That is with one exception. The case where an earlier SOF driver sends us the old smaller struct identifier with IPC4_MOD_INIT_DATA_ID_DP_DATA, then we should not fail on that, but only ignore the struct. This is why "return" is changed to "break" in case IPC4_MOD_INIT_DATA_ID_DP_DATA. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

Move module_ext_init_decode()-call earlier in call chain so that struct ipc4_module_init_ext_obj_dp_data is available when module_adapter_mem_alloc() is called. That is, if the struct ipc4_module_init_ext_object is present in the struct ipc4_module_init_ext_init payload. To accomplish this I needed to redesign how module_ext_init_decode() works and how its called a bit. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

jsarha mentioned this pull request Sep 26, 2025
New memory domain logic thesofproject/linux#5537
Merged

lyakh reviewed Sep 29, 2025
View reviewed changes

Comment threadsrc/include/ipc4/pipeline.h

lgirdwood reviewed Sep 30, 2025
View reviewed changes

Comment threadsrc/include/ipc4/pipeline.h

jsarha force-pushed the pipeline_memory_attributes branch from ac3bf18 to 5c3c095Compare September 30, 2025 20:59

lyakh reviewed Oct 1, 2025
View reviewed changes

Comment threadsrc/ipc/ipc4/helper.c Outdated

lyakh changed the title ~~Code to decode pipline create messages payload~~Code to decode pipeline create messages payloadOct 2, 2025

lyakh reviewed Oct 6, 2025
View reviewed changes

Comment threadsrc/ipc/ipc4/helper.c Outdated
Comment threadsrc/ipc/ipc4/helper.c Outdated

jsarha force-pushed the pipeline_memory_attributes branch from e43cb7b to 9f5d981Compare October 7, 2025 21:37

jsarha force-pushed the pipeline_memory_attributes branch 2 times, most recently from 2dc8ac4 to 7e4bb9aCompare November 11, 2025 18:06

lyakh reviewed Nov 14, 2025
View reviewed changes

Comment threadsrc/ipc/ipc4/helper.c
Comment threadsrc/ipc/ipc4/helper.c Outdated
Comment threadsrc/ipc/ipc4/helper.c Outdated

jsarha force-pushed the pipeline_memory_attributes branch from 7e4bb9a to d9de565Compare December 3, 2025 19:17

jsarha force-pushed the pipeline_memory_attributes branch from d9de565 to 4d8a457Compare December 14, 2025 23:14

jsarha marked this pull request as ready for review December 16, 2025 16:02

CopilotAI review requested due to automatic review settings December 16, 2025 16:02

jsarha requested review from RanderWang, dbaluta, jxstelter, kv2019i, lbetlej, marcinszkudlinski, mmaka1, pblaszko, plbossart and ranj063 as code owners December 16, 2025 16:02

jsarha force-pushed the pipeline_memory_attributes branch from ae1aa2f to ea35f8eCompare January 5, 2026 09:48

lgirdwood reviewed Jan 5, 2026
View reviewed changes

lgirdwood reviewed Jan 8, 2026
View reviewed changes

jsarha force-pushed the pipeline_memory_attributes branch from ea35f8e to def7436Compare January 9, 2026 21:55

jsarha force-pushed the pipeline_memory_attributes branch from def7436 to 7f4abebCompare January 11, 2026 23:16

lgirdwood reviewed Jan 12, 2026
View reviewed changes

jsarha force-pushed the pipeline_memory_attributes branch from 7f4abeb to 130263dCompare January 12, 2026 13:39

lgirdwood approved these changes Jan 12, 2026
View reviewed changes

kv2019i reviewed Jan 22, 2026
View reviewed changes

Comment threadsrc/ipc/ipc4/helper.c

jsarha force-pushed the pipeline_memory_attributes branch from 130263d to 9817ed2Compare January 23, 2026 15:22

kv2019i approved these changes Jan 26, 2026
View reviewed changes

Jyri Sarha added 9 commits January 27, 2026 18:22

audio: module_adapter: Use %zu in size_t prints in module_ext_init_de…
e855f3a
…code() Use %zu in size_t prints in module_ext_init_decode(). Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

ipc4: helper: Do not invalidate cache of whole mailbox for module init
0e9d17c
Invalidate cache for only the module init payload size not the whole mailbox. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

pipeline: Pass create pipeline payload parameters down to pipeline_new()
fe86763
Pass create pipeline payload parameters down to pipeline_new() by using struct pipeline_params. That is the place where the data will be used. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>

jsarha force-pushed the pipeline_memory_attributes branch from 9817ed2 to 312c6e3Compare January 27, 2026 16:53

lgirdwood approved these changes Jan 27, 2026
View reviewed changes

lgirdwood merged commit 77790ce into thesofproject:mainJan 27, 2026
45 of 52 checks passed

Uh oh!

Conversation

jsarha commented Sep 26, 2025

Uh oh!

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jsarha commented Dec 3, 2025

Uh oh!

jsarha commented Dec 14, 2025

Uh oh!

jsarha commented Dec 16, 2025

Uh oh!

jsarha commented Dec 16, 2025

Uh oh!

lgirdwood commented Dec 16, 2025

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lgirdwoodJan 6, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsarhaJan 9, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsarha commented Jan 9, 2026

Uh oh!

jsarha commented Jan 11, 2026

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

jsarha commented Jan 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lgirdwood commented Jan 26, 2026

Uh oh!

jsarha commented Jan 26, 2026

Uh oh!

jsarha commented Jan 26, 2026

Uh oh!

lgirdwood commented Jan 27, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

lgirdwoodJan 6, 2026•
edited
Loading

jsarhaJan 9, 2026•
edited
Loading

jsarha commented Jan 12, 2026•
edited
Loading