ipc: userspace: fix IPC serialization with multiple cores

[kv2019i]

Fix a race in IPC serialization with multi-core. The sequence observed:

• MOD_SET_DX IPC to power up core 1
• IPC reply to host
• CREATE_PIPELINE IPC (routed via core 0 to core 1)
• core 1 IPC thread starts, signals ipc_user->sem semaphore
• core 0 does NOT wait for thread as ipc_user->init_needed is set late
  • ipc_user->sem signal for thread start is handled as indication that IPC is handled (this is wrong)
• IPC reply to host (before CREATE_PIPELINE is handled)
• INIT_INSTANCE IPC (routed via core 0 to core 1)
  • core 0 sees init_needed, but it is already signaled so execution continues -> DSP panic as IPC mailbox is modified while still in use

The race is caused by a bug in setting "init_needed" and starting the IPC user thread on a secondary core (core 1 above). Due to the race, the CREATE_PIPELINE does not wait for core 1 to signal readiness and instead replies to host early, breaking IPC serialization.

Fix the problem by moving set of "init_needed" before the IPC thread is started on a new core. This will ensure CREATE_PIPELINE in above sequence will be not forwarded to core 1 until the IPC thread is ready on the new core.

[kv2019i]

FYI, this is easily hit on sof-ptl-nocodec.tplg with PR11164 (see comment #11164 (review) ).

[Copilot]

🟡 Changes recommended

The updated logic still relies on a cross-core init_needed[] flag that is accessed non-atomically, which can allow stale reads and reintroduce the serialization race on weakly ordered systems.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR fixes an IPC serialization race in multi-core scenarios by ensuring the per-core “userspace IPC thread not yet ready” flag is set before the secondary-core IPC userspace thread is started, so the primary core correctly blocks on the initial startup semaphore signal rather than misinterpreting it as command completion.

Changes:

• Move ipc_user->init_needed[core] = true; ahead of k_thread_start() in ipc_user_init_secondary() to close the startup ordering race on secondary cores.

File summaries

File	Description
src/ipc/ipc-common.c	Adjusts secondary-core IPC userspace thread startup ordering to prevent premature host replies and broken IPC serialization.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

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

[intel-sofci]

PR 11186: test results

Run date: 2026-09-10 19:40 UTC

Tested commit: 5db4397f18199d1188896fab381f61aeb23080c3

[kv2019i]

Back to draft, still fails, V2 coming

[kv2019i]

V2:

• more problems found, rework the synchronization to not rely on ipc_user->sem to signal thread readiness and leave the semaphore solely to track IPC completions
• the atomics are used purely to ensure compiler doesn't optimize or reorder

[kv2019i]

V3:

• fix cmocka and alsa plugin

[lyakh]

this looks strange... Would a very simple fix: set init_needed on core 0 before booting core 1 fix the problem too?

[kv2019i]

V4:

• discussed offline with @lyakh and implemented a different approach
• this passes same test as V3, but moves the synchronization of newly booted secondary cores, to MOD_SET_DX

[lyakh]

I don't understand this: "Note that after this, secondary cores may be powered
down and up many times, but the initialization (and related synchronization)
is no longer needed."

[lyakh]

hm, and if you power off a core and then power it back on?

[lyakh]

ok, clarified. The per-core userspace IPC thread isn't terminated when the respective core is powered down. All the threads stay there, they just aren't schedulable, because they are pinned to the powered off cores.