[userspace LL] scheduling: LLEXT, DP & multicore - #10945
Conversation
a462fcf to
9f6770d
Compare
|
After multiple PRs got merged we're down from 108 commits to 32 |
|
let me mark it "ready" to have some on-device testing |
PR 10945: test resultsRun date: 2026-09-04 09:03 UTC Tested commit: 6a70cdd8d32dfaab35b7dd602be7d6add461a79b |
There was a problem hiding this comment.
🟡 Changes recommended
Confirmed issues include unsafe userspace LL domain mapping for DP modules and uninitialized/per-core IPC state leading to potential deadlocks or invalid memory access.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
Suppressed comments (1)
src/ipc/ipc-common.c:619
- ipc_user is allocated with sof_heap_alloc() but never zero-initialized; init_needed[] and the per-core thread/event pointers start as uninitialized heap garbage. This can cause ipc_user_forward_cmd() to deadlock (spurious init_needed[core]) or dereference invalid per-core pointers.
struct ipc *ipc = ipc_get();
struct ipc_user *ipc_user = sof_heap_alloc(sof_sys_user_heap_get(),
SOF_MEM_FLAG_USER | SOF_MEM_FLAG_COHERENT,
sizeof(*ipc_user), 0);
int ret;
- Files reviewed: 14/14 changed files
- Comments generated: 2
- Review effort level: Lite
kv2019i
left a comment
There was a problem hiding this comment.
Looks good, some minor comments and usual nagging about z_vrfy code ...
| #define IPC_TASK_POWERDOWN BIT(3) | ||
|
|
||
| #ifdef CONFIG_CORE_COUNT | ||
| #define CORE_COUNT CONFIG_CORE_COUNT |
There was a problem hiding this comment.
Isn't CORE_COUNT a bit generic (and short) definition in a public header file?
Most places in SOF just use CONFIG_CORE_COUNT (defined in sof/src/platform/Kconfig), so this should be available for all builds. Maybe "ifndef CONFIG_CORE_COUNT" and set it 1 for the failing builds (library, cmocka, ztests?)
There was a problem hiding this comment.
uhm, rather not. Really don't think #define CONFIG_foo ... is a good thing. How about IPC_DSP_CORE_COUNT?
There was a problem hiding this comment.
@lyakh I'm good with IPC_DSP_ prefix. Or alternatively pull in some header that will ensure CONFIG_CORE_COUNT is defined.
| userspace/ksem.c | ||
| ) | ||
| if(CONFIG_USERSPACE AND CONFIG_SOF_USERSPACE_INTERFACE_ALLOC) | ||
| if(CONFIG_USERSPACE AND CONFIG_SOF_USERSPACE_INTERFACE_ALLOC AND NOT CONFIG_SOF_USERSPACE_LL) |
|
@kv2019i comments addressed |
|
@lrudyX MTL test hung? |
Extract a privileged LLEXT-related part from lib_manager_module_create() into a separate function to be called from kernel context. At the same time lib_manager_mod_free_priv() already executes privileged operations; to make it callable in userspace, convert lib_manager_free_module() to a system call. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
If LL runs in userspace, it needs access to loaded LLEXT modules, running in DP more too. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Make scheduling LL thread and synchronisation objects per-core and forward IPCs and scheduling events accordingly. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Checking pointer for non-NULL after dereferencing it makes no sense. Swap the order. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Simplify code by using cached core ID values instead of querying the hardware or re-evaluating expressions. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
In case of userspace LL scheduling the (also userspace) IPC thread needs access rights to DP assets like the thread itself and its stack and synchronisation primitives. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
When running in syscall context on behalf of a userspace thread dynamically mapped memory doesn't automatically become accessible. To make it accessible it has to be added to the thread memory domain. This is a problem for loadable modules with executable cold sections. To be able to execute them they have to be mapped to threads with the executable bit set. While for linking that memory has to be mapped writable. To solve the problem we perform linking from the kernel IPC context before forwarding to the userspace IPC thread. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Re-enable LLEXT, DRAM execution and data, the DP scheduler and boot time testing with userspace LL with a small restriction for the latter - userspace allocation failure tests aren't currently working. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
This includes #10558 and my patches on top to enable LLEXT and multicore. Current status: passes simple tests with nocodec with both core 0 and core 1 streaming. 2 streams simultaneously run into a problem when the first of them terminates. WiP.
Update: now that #10558 has mostly been merged, this PR still carries remaining fixes for multicore, LLEXT, cold sections. At its peak this PR contained more than a 100 commits, as of today Aug 28th only 12 patches remain
Update: as of today Sep 2nd only 7 patches remain and this is now considered to be the final step (short of making userspace LL on by default on ACE3+)