audio: module-adapter: make generic code compatible with user-space#10950
audio: module-adapter: make generic code compatible with user-space#10950kv2019i wants to merge 2 commits into
Conversation
kv2019i
requested review from
dbaluta,
lbetlej,
lgirdwood,
mmaka1 and
plbossart
as code owners
|
For context, part of #10558 |
There was a problem hiding this comment.
Pull request overview
This PR aims to make generic module-adapter and data blob handling code safe/usable from user-space contexts by switching allocations to user-safe heap APIs and threading a heap choice through the data blob handler creation path.
Changes:
- Extend
comp_data_blob_handler_new_ext()with an optionalstruct k_heap *heapparameter and update the default wrapper. - Update generic module configuration/runtime allocations to use
sof_heap_alloc()/sof_heap_free()(withsof_sys_user_heap_get()). - Pass the module allocator heap into
comp_data_blob_handler_new_ext()frommod_data_blob_handler_new().
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/include/sof/audio/data_blob.h | Extends blob handler constructor API with an optional heap parameter and updates the inline wrapper. |
| src/audio/module_adapter/module/generic.c | Replaces config/runtime rballoc/rfree usage with sof_heap_alloc/sof_heap_free and passes allocator heap into blob handler creation. |
| src/audio/data_blob.c | Stores heap in the handler, allocates/frees handler via heap when provided, and adds “default heap” alloc/free helpers. |
Use user-space friendy sof_heap_alloc() for dynamic allocations in data_blob handler. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Replace direct rballoc() and rfree() calls with sof_heap_alloc() and sof_heap_free(), and use sof_sys_user_heap_get() as the heap. This makes the code ready to be used in user-space, including module prepare and free stages. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
kv2019i
force-pushed
the
202606-module-adapt-userspace
branch
from
82045ae to
dfc1660
Compare
|
V2 pushed:
|
| handler = rzalloc(SOF_MEM_FLAG_USER, | ||
| sizeof(struct comp_data_blob_handler)); | ||
| handler = sof_heap_alloc(heap, SOF_MEM_FLAG_USER | SOF_MEM_FLAG_COHERENT, | ||
| sizeof(struct comp_data_blob_handler), 0); |
There was a problem hiding this comment.
could just use sof_sys_user_heap_get() directly as in other cases. But this one also adds COHERENT - that's on purpose, right? Maybe mention in the commit message
There was a problem hiding this comment.
Ok, fixing both. Earlier version of the patch stored a heap instance, but no need for that. And COHERENT is a mistake, we should align flags. Will fix.
| /* No space for config available yet, allocate now */ | ||
| dst->data = rballoc(SOF_MEM_FLAG_USER, size); | ||
| dst->data = sof_heap_alloc(sof_sys_user_heap_get(), | ||
| SOF_MEM_FLAG_USER, size, 0); |
There was a problem hiding this comment.
so, we're releasing some of VMH memory and using the standard heap here. Have you checked how big these allocations are typically and how many we switch? Do we need to reallocate some memory from VMH to the userspace heap?
There was a problem hiding this comment.
Hmm, right. I don't think we should touch the virtual/direct heap mix in the same PRs as we add support for user-space LL use. And yeah, that's what I'm doing here and some of earlier rballoc(). I could use SOF_MEM_FLAG_LARGE_BUFFER to mark places where rballoc() was used, but that is hardcoded to kernel in current zephyr/alloc.c, so won't work either. But alas, some cleaner solution is needed. Sizing the VMH split is a much more complicated problem and I don't want to tackle that in these PRs...
kv2019i
left a comment
kv2019i
left a comment
There was a problem hiding this comment.
Inline responses... this will need more work.
| handler = rzalloc(SOF_MEM_FLAG_USER, | ||
| sizeof(struct comp_data_blob_handler)); | ||
| handler = sof_heap_alloc(heap, SOF_MEM_FLAG_USER | SOF_MEM_FLAG_COHERENT, | ||
| sizeof(struct comp_data_blob_handler), 0); |
There was a problem hiding this comment.
Ok, fixing both. Earlier version of the patch stored a heap instance, but no need for that. And COHERENT is a mistake, we should align flags. Will fix.
| /* No space for config available yet, allocate now */ | ||
| dst->data = rballoc(SOF_MEM_FLAG_USER, size); | ||
| dst->data = sof_heap_alloc(sof_sys_user_heap_get(), | ||
| SOF_MEM_FLAG_USER, size, 0); |
There was a problem hiding this comment.
Hmm, right. I don't think we should touch the virtual/direct heap mix in the same PRs as we add support for user-space LL use. And yeah, that's what I'm doing here and some of earlier rballoc(). I could use SOF_MEM_FLAG_LARGE_BUFFER to mark places where rballoc() was used, but that is hardcoded to kernel in current zephyr/alloc.c, so won't work either. But alas, some cleaner solution is needed. Sizing the VMH split is a much more complicated problem and I don't want to tackle that in these PRs...
Series of patches to make generic module code safe to use from user-space.