-
Notifications
You must be signed in to change notification settings - Fork 369
[Draft] Fix DP userspace crashes and memory-allocation failures for compressed playback on PTL #11181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
[Draft] Fix DP userspace crashes and memory-allocation failures for compressed playback on PTL #11181
Changes from all commits
a6a314b
8fe4417
8021f1d
c2db699
feba771
f22e91b
73c24d7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -54,6 +54,14 @@ struct ipc4_flat { | |
| struct sof_source *source[CONFIG_MODULE_MAX_CONNECTIONS]; | ||
| struct sof_sink *sink[CONFIG_MODULE_MAX_CONNECTIONS]; | ||
| } pipeline_state; | ||
| /* | ||
| * SOF_IPC4_MOD_INIT_INSTANCE: a by-value copy of the caller's | ||
| * ext_data. The original lives on the calling thread's stack, | ||
| * which the DP thread's memory domain doesn't have access to. | ||
| * The pointers it contains reference the IPC mailbox, which stays | ||
| * valid and is covered by the DP thread's SOF_DP_PART_CFG partition. | ||
| */ | ||
| struct module_ext_init_data init_instance; | ||
| }; | ||
| }; | ||
|
|
||
|
|
@@ -73,6 +81,12 @@ static int ipc_thread_flatten(unsigned int cmd, const union scheduler_dp_thread_ | |
| flat->bind.bu = *param->bind_data->ipc4_data; | ||
| flat->bind.type = param->bind_data->bind_type; | ||
| break; | ||
| case SOF_IPC4_MOD_INIT_INSTANCE: | ||
| if (param->ext_data) | ||
| flat->init_instance = *param->ext_data; | ||
| else | ||
| flat->init_instance = (struct module_ext_init_data){ 0 }; | ||
| break; | ||
| case SOF_IPC4_GLB_SET_PIPELINE_STATE: | ||
| flat->pipeline_state.trigger_cmd = param->pipeline_state.trigger_cmd; | ||
| switch (param->pipeline_state.trigger_cmd) { | ||
|
|
@@ -133,7 +147,13 @@ static void ipc_thread_unflatten_run(struct processing_module *pmod, struct ipc4 | |
| flat->ret = ops->free(pmod); | ||
| break; | ||
| case SOF_IPC4_MOD_INIT_INSTANCE: | ||
| /* | ||
| * Repoint ext_data at the copy ipc_thread_flatten() made in DP-thread- | ||
| * accessible memory; the original caller-stack copy is out of reach here. | ||
| */ | ||
| pmod->priv.cfg.ext_data = &flat->init_instance; | ||
| flat->ret = ops->init(pmod); | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ah, that's because the only tested until now module in DP mode was SRC and it doesn't access |
||
| pmod->priv.cfg.ext_data = NULL; | ||
| break; | ||
| case SOF_IPC4_GLB_SET_PIPELINE_STATE: | ||
| switch (flat->pipeline_state.trigger_cmd) { | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -57,6 +57,16 @@ Class.Widget."decoder" { | |
|
|
||
| # cadence codec UUID | ||
| uuid "43:84:21:d8:f3:5f:4c:4a:b3:88:6c:fe:07:b9:56:aa" | ||
|
|
||
| # Cadence codec memory tables (persist/scratch/input/output) can exceed the | ||
| # generic widget-common.conf default; give decoders more headroom. This same | ||
| # vregion also backs every buffer bound to a DP module (ipc4_comp_connect() | ||
| # allocates from dp->mod->priv.resources.alloc), so it must cover the | ||
| # codec's own memory tables plus every connected buffer, not just the codec. | ||
| heap_bytes_requirement 196608 | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should be squashed with an earlier one |
||
| # Cadence codec init (e.g. xa_aac_dec) can need more stack than the | ||
| # generic widget-common.conf default when run in the DP userspace thread. | ||
| stack_bytes_requirement 16384 | ||
| no_pm "true" | ||
| num_output_pins 1 | ||
| num_input_pins 1 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -130,8 +130,15 @@ struct vregion *vregion_create(size_t memsize) | |
| */ | ||
| total_size = ALIGN_UP(memsize, CONFIG_MM_DRV_PAGE_SIZE); | ||
|
|
||
| /* allocate vregion metadata separately to keep it inaccessible to the user */ | ||
| vr = rmalloc(0, sizeof(*vr)); | ||
| /* | ||
| * allocate vregion metadata separately to keep it inaccessible to the | ||
| * user. The vregion is created on the DP module's own core but is | ||
| * later read/written from other cores too (e.g. buffer_new() on the | ||
| * IPC core routes through it for buffers connecting to this module), | ||
| * so it must be coherent - plain cached memory left writes from the | ||
| * creating core invisible to other cores without an explicit flush. | ||
| */ | ||
| vr = rmalloc(SOF_MEM_FLAG_KERNEL | SOF_MEM_FLAG_COHERENT, sizeof(*vr)); | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. until now all accesses to vregion metadata were taking place on the same core. Do you have a DP module on a core different, than the rest of the pipeline?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it looks like we do — the decoder/encoder consistently ends up on core 1 while the rest of the pipeline (and the IPC thread connecting buffers to it) runs on core 0.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hm, @jsarha was saying that it didn't work for him IIRC? |
||
| if (!vr) | ||
| return NULL; | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all three of these changes are needed? With the below 2 changes, this one might not be needed any more?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
only the
ctx->n_modcheck is needed