lib: dma: add support for user-space usage #10341

kv2019i · 2025-10-29T19:56:19Z

Initial work to allow user-space threads to operate DMA streams. No impact to SOF targets that do not use user-space.

~~The first four commits are from #10119 , one market commit and two actual new commits.~~

kv2019i · 2025-10-29T20:00:54Z

lgirdwood

I think this looks good, the dma config part probably needs some refinement to minimise data passed to configure the channel and we need a ID instead of a pointer to pass to the kernel dma structure

lgirdwood · 2025-10-30T14:39:40Z

src/include/sof/sof_syscall.h

 __syscall uint32_t sof_local_lock(void);
 __syscall void sof_local_unlock(uint32_t flags);

+__syscall struct sof_dma *sof_dma_get(uint32_t dir, uint32_t caps, uint32_t dev, uint32_t flags);


I assume these are already exported for clients in dma.h with doxygen API. Btw, might be worth spelling out that the sys calls are for SOF infra usage and not intended for direct module usage as a comment.

lgirdwood · 2025-10-30T14:57:49Z

zephyr/syscall/sof_dma.c

+}
+#include <zephyr/syscalls/sof_dma_release_channel_mrsh.c>
+
+static inline int z_vrfy_sof_dma_config(struct sof_dma *dma, uint32_t channel,


So this is the tricky one @kv2019i @teburd.

We really have to be minimal data here for our end goal for both channel configuration and buffer descriptor configuration. e.g. (buffer config example - inspiration from DW HW LLI)

struct dma_desc { void *src; void *dest; size_t bytes; // copy size for this descritptor uint32_t flags; // should be generic - things like direction struct dma_desc *next; // next desc, NULL if last - can also be cyclic };

This should allows us to specify our buffers, where we can then do

for_each_desc { if (!k_thread_can access(desc->src) || !k_thread_can_access(desc->src + desc->size)) return -EINVAL; //... check dest and next desc ptr }

where we need a k_thread_can_access() type API call that can lookup thread domain page tables.

@lgirdwood I can take a stab at this. There's basicly two approaches that both seem possible:

take the Zephyr DMA API and filter out forbidden fields in the syscall handler (if user-kernel split is enabled), or

define new types that offer more limited interface and use that interface in the user-kernel interface (as per your comment above)

I agree (2) seems better in terms of longterm maintainance of the syscall handler code. The downside is that we then limit the DMA interface for all SOF users in dai/host-zephyr.c, whether they use user-space or not. But maybe this is still better in the end. We can cover all existing usage with the "safe wrappers" and if there are more needs in the future, the interface can be extended. In worst case, there's always the possibility to use a different implementation of host/dai modules. Less code reuse but less restrictions.

Ok hit some roadblocks with this approach. Looking at dai-zephyr.c usage of this interface, I see the Zephyr DMA interface features are more widely used with the DAI DMAs (e.g. support for NXP DMAs uses more of Zephyr DMA features). So after I extended my "safe" variants to cover everything needed for host-zephyr.c and dai-zephyr. c, I'm basicly left with replicas of the Zephry dma.h structs, sans a few fields (for kernel callbacks). I don't think works out well.

Also dai-zephyr.c really uses scatter-gather (unlike host-zephyr.c and other simpler DMA users in SOF), so there are actually multiple descriptors. We can't trust the descriptor objects in user context (Tom commented about this earlier and matches guidance). So need to think how to copy over the descriptors to kernel space, and then pass to the driver.

Back to thinking hat with this one.

In latest 14th Nov series of this PR, I now solved this by:

still using the full Zephyr DMA interface

do a full copy (including a deepcopy of the scatter-gather list) in kernel space, and only copy fields supported when using user-space DMA

i.e. kernel doesn't try to verify all fields, but instead only uses fields it trusts and knows about. if new fields are added (to upstrema Zephyr DMA), they need to be explicitly added here in order to pass the new field/information to DMA drivers

lgirdwood · 2025-10-30T15:01:08Z

zephyr/test/userspace/dma.c

+static struct k_thread user_thread;
+static K_THREAD_STACK_DEFINE(user_stack, USER_STACKSIZE);
+
+static void user_function(void *p1, void *p2, void *p3)


Would be good to say what this test does e.g. userspace thread that copies memory from userspace buffers.

kv2019i · 2025-11-06T19:25:59Z

V2:

dropped ztest cases and dependency to Test user-space and enable CONFIG_USERSPACE on select platforms #10119 (only needed to add the userspace test case for DMA, not for actual code)
converted host-zephyr.c to use new wrapper
started working on support to handle dai-zephyr.c as well, but not ready yet
new approach to validate the DMA config and sg/transfer list -- now supports "block_count > 1" usage (dai-zephyr.c)
should pass CI, no functional change to current non-userspace SOF targets

kv2019i · 2025-11-14T12:32:10Z

V3:

added a new test case to exercise the DMA fully in the test case
decoupled from Test user-space and enable CONFIG_USERSPACE on select platforms #10119 .. added a new standalone boot test Kconfig and added instructions how to build and run the test
no dependencies outside the PR, so marking this as ready for review now

kv2019i · 2025-11-14T12:32:30Z

Example test output on PTL with this PR:

START - userspace_intel_hda_dma
[    0.000031] <inf> sof_boot_test: intel_hda_dma_kernel: run intel_hda_dma_kernel with buffer at address 0x40132000, size 2 56
INFO:cavs-fw:Mapping registers for hda stream 0 at base 7fe614c3c080
INFO:cavs-fw:Resetting stream 0
INFO:cavs-fw:Disable SPIB and set position 0 of stream 0
INFO:cavs-fw:Enabling dsp capture (PROCEN) of stream 0
INFO:cavs-fw:Reset stream 0
INFO:cavs-fw:Configuring stream 0
INFO:cavs-fw:Allocating huge page and setting up buffers
INFO:cavs-fw:type of mem is <class 'mmap.mmap'>
INFO:cavs-fw:Mapped 2M huge page at 0x16e600000 for buf size (256)
INFO:cavs-fw:Filled the buffer descriptor list (BDL) for DMA.
INFO:cavs-fw:Setting buffer list, length, and stream id and traffic priority bit
INFO:cavs-fw:Configured stream 0
[    0.000098] <inf> sof_boot_test: intel_hda_dma_kernel: user started, waiting for it to be ready
[    0.000098] <inf> sof_boot_test: intel_hda_dma_user: SOF thread UserSpace! (intel_adsp/ace30/ptl)
[    0.000098] <inf> dma: z_impl_sof_dma_get: dma_get() ID 0 sref = 1 busy channels 0
[    0.000098] <inf> sof_boot_test: intel_hda_dma_user: configure DMA channel
[    0.000098] <inf> sof_boot_test: intel_hda_dma_user: sof_dma_request_channel: ret 0
[    0.000098] <inf> sof_boot_test: intel_hda_dma_user: DMA addr alignment 128
[    0.000098] <inf> sof_boot_test: intel_hda_dma_user: sof_dma_config: success
[    0.000098] <inf> sof_boot_test: intel_hda_dma_user: sof_dma_start: ret 0
[    0.000098] <inf> sof_boot_test: intel_hda_dma_user: setup ready, waking for kernel to configure host-side of the test
[    0.000098] <inf> sof_boot_test: intel_hda_dma_kernel: user ready, starting HDA test
INFO:cavs-fw:Starting stream 0, CTL 40000
INFO:cavs-fw:Started stream 0, CTL 40002
[    0.000110] <inf> sof_boot_test: intel_hda_dma_user: start DMA test and transfer data
[    0.000110] <inf> sof_boot_test: intel_hda_dma_user: sof_dma_get_status start: ret 0 pend 0 free 256
[    0.000110] <inf> sof_boot_test: intel_hda_dma_user: sof_dma_reload: ret 0
[    0.000110] <inf> sof_boot_test: intel_hda_dma_user: sof_dma_get_status 0: ret 0 pend 256 free 0
[    0.000110] <inf> sof_boot_test: intel_hda_dma_user: sof_dma_get_status end: ret 0 pend 0 free 256
[    0.000110] <inf> sof_boot_test: intel_hda_dma_user: transfer done, asking host to validate output
[    0.000110] <inf> sof_boot_test: intel_hda_dma_kernel: transfer done, validating results
INFO:cavs-fw:Is ramp data? True
INFO:cavs-fw:Ext data to send back on ramp status 1
[    0.000121] <dbg> sof_boot_test: ipc_message: HDA message received, data 1, ext_data 1
[    0.000121] <inf> sof_boot_test: intel_hda_dma_user: test done, cleaning up resources
[    0.000121] <inf> sof_boot_test: intel_hda_dma_user: sof_dma_stop: ret 0
[    0.000121] <inf> sof_boot_test: intel_hda_dma_user: sof_dma_release_channel: success
[    0.000121] <inf> dma: z_impl_sof_dma_put: dma_put(), dma = 0x400c1a70, sref = 0
[    0.000121] <inf> sof_boot_test: intel_hda_dma_user: sof_dma_put: success
[    0.000121] <inf> sof_boot_test: intel_hda_dma_kernel: test done, terminate user
 PASS - userspace_intel_hda_dma in 0.290 seconds

Copilot

Pull Request Overview

This PR adds support for user-space threads to operate DMA streams through a syscall layer, enabling safer isolation of DMA operations while maintaining compatibility with existing SOF targets that don't use user-space.

Key changes:

Introduced new syscall interface for DMA operations with kernel-side validation
Added standalone boot test infrastructure that can run complex tests using IPC
Converted existing DMA function calls to use the new syscall-based API

Reviewed Changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
zephyr/test/userspace/test_intel_hda_dma.c	New user-space test case for Intel HDA DMA functionality with kernel/user thread coordination
zephyr/test/userspace/README.md	Documentation for building and running the Intel HDA DMA user-space test
zephyr/test/CMakeLists.txt	Build configuration to include user-space DMA test when appropriate configs are enabled
zephyr/syscall/sof_dma.c	Implementation of syscall verification handlers with access validation and memory permission checks
zephyr/include/sof/lib/dma.h	Updated function declarations to use z_impl_ prefix for syscall implementation pattern
zephyr/Kconfig	New configuration option for standalone boot tests that interfere with normal SOF operation
zephyr/CMakeLists.txt	Build integration for syscall sources and header registration
src/lib/dma.c	Renamed DMA functions to z_impl_ pattern and added new wrapper functions for syscall interface
src/ipc/ipc-common.c	Added early return in IPC initialization when running standalone tests
src/include/sof/sof_syscall.h	New header defining syscall signatures for DMA operations
src/audio/host-zephyr.c	Updated all DMA API calls to use new sof_dma_* function names
app/userspace_overlay.conf	Configuration overlay enabling user-space and custom syscalls

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-11-14T12:34:06Z

zephyr/syscall/sof_dma.c

+static inline struct dma_block_config *deep_copy_dma_blk_cfg_list(struct dma_config *cfg)
+{
+	struct dma_block_config *kern_cfg =
+		rmalloc(0, sizeof(*kern_cfg) * cfg->block_count);


Memory allocation for kern_cfg is not checked for NULL before use. If rmalloc fails, subsequent operations at lines 106-138 will cause undefined behavior. Add a null check immediately after allocation and return NULL if allocation fails.

Suggested change

rmalloc(0, sizeof(*kern_cfg) * cfg->block_count);

rmalloc(0, sizeof(*kern_cfg) * cfg->block_count);

if (!kern_cfg)

return NULL;

It's true kern_cfg is used to initialize other pointers, but it is not dereferences before a NULL check is done, so this is safe.

Copilot · 2025-11-14T12:34:07Z

zephyr/syscall/sof_dma.c

+			kern_prev = kern_next;
+		}


On the first iteration when kern_prev is NULL, it is never initialized, causing all blocks except the first to be disconnected from the chain. Initialize kern_prev = kern_cfg before the loop or set it to kern_next unconditionally after processing each block.

Suggested change

kern_prev = kern_next;

}

}

kern_prev = kern_next;

Copilot · 2025-11-14T12:34:07Z

zephyr/test/userspace/test_intel_hda_dma.c

+		LOG_INF("sof_dma_get_status %d: ret %d pend %u free %u", err,
+			i, stat.pending_length, stat.free);


The format string placeholders are misaligned with arguments. The first %d should print i, the second should print err, but they appear in the wrong order. The correct format should be: LOG_INF(\"sof_dma_get_status %d: ret %d pend %u free %u\", i, err, stat.pending_length, stat.free);

Suggested change

LOG_INF("sof_dma_get_status %d: ret %d pend %u free %u", err,

i, stat.pending_length, stat.free);

LOG_INF("sof_dma_get_status %d: ret %d pend %u free %u", i,

err, stat.pending_length, stat.free);

Copilot · 2025-11-14T12:34:08Z

src/audio/host-zephyr.c

 	cb(dev, bytes);

-	ret = dma_reload(hd->chan->dma->z_dev, hd->chan->index, 0, 0, bytes);
+	ret = sof_dma_reload(hd->chan->dma, hd->chan->index, 0, 0, bytes);


The call to sof_dma_reload passes 5 arguments, but the syscall signature at line 33 in src/include/sof/sof_syscall.h and implementation at line 189-192 in src/lib/dma.c only accept 3 parameters: dma, channel, and size. Remove the two extra 0, 0 arguments.

Suggested change

ret = sof_dma_reload(hd->chan->dma, hd->chan->index, 0, 0, bytes);

ret = sof_dma_reload(hd->chan->dma, hd->chan->index, bytes);

src/audio/host-zephyr.c

Copilot · 2025-11-14T12:34:08Z

zephyr/test/userspace/test_intel_hda_dma.c

+	hda_ipc_msg(INTEL_ADSP_IPC_HOST_DEV, IPCCMD_HDA_VALIDATE, TEST_CHANNEL,
+		    IPC_TIMEOUT);
+
+	hda_dump_regs(HOST_OUT, HDA_REGBLOCK_SIZE, channel, "host reset");


The variable channel is used here but is a local variable in the intel_hda_dma_user function and not in scope within intel_hda_dma_kernel. This should likely be TEST_CHANNEL instead.

Suggested change

hda_dump_regs(HOST_OUT, HDA_REGBLOCK_SIZE, channel, "host reset");

hda_dump_regs(HOST_OUT, HDA_REGBLOCK_SIZE, TEST_CHANNEL, "host reset");

Copilot · 2025-11-14T12:34:09Z

zephyr/Kconfig

+	help
+	  Run extended set of tests at boot that can use IPC and interfere
+	  with system state. Normal IPC handling of the SOF application
+	  is disable to allow more complex tests to run.


Corrected spelling of 'disable' to 'disabled'.

Suggested change

is disable to allow more complex tests to run.

is disabled to allow more complex tests to run.

kv2019i · 2025-11-14T12:56:30Z

V4 pushed:

address copilot review comments

Copilot

Pull Request Overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 3 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

zephyr/test/userspace/test_intel_hda_dma.c

Copilot · 2025-11-14T13:02:23Z

src/lib/dma.c

+EXPORT_SYMBOL(z_impl_sof_dma_get);
+EXPORT_SYMBOL(z_impl_sof_dma_put);


The remaining DMA API functions (sof_dma_config, sof_dma_start, sof_dma_stop, etc.) should also have EXPORT_SYMBOL declarations if they are intended to be used outside this module, to maintain consistency with the existing exports.

zephyr/include/sof/lib/dma.h

lrudyX · 2025-11-19T15:45:05Z

Intel Internal CI fails with not related test

kv2019i · 2025-11-21T17:22:32Z

V5 pushed:

rebased to merge with recent changes to BOOTTEST handling
moved the syscall declarations to sof/lib/dma.h. this more aligned to the coding style used in upstream Zephyr. the new sof-dma.h is a bit of a beauty error to avoid a naming clash when generating syscall headers (not to class with Zephyr dma.h)
reworked how the BOOTTEST_STANDALONE are run
fixed non-zephyr SOF builds that use dma.h

kv2019i · 2025-11-21T17:23:05Z

@jsarha if you can also take a look.

lyakh · 2025-11-24T08:53:01Z

src/include/sof/sof_syscall.h

+
+#include <stdint.h>
+
+#error "should not get here"


mmh, not sure I understand?

I think this is to catch inclusion on non userspace platforms, but does need more context added.

Oops, this is a transitional file I was supposed to remove once all contents is moved elsewhere. Will address.

lyakh · 2025-11-24T08:58:43Z

zephyr/syscall/sof_dma.c

+	for (d = info->dma_array; d < info->dma_array + info->num_dmas; d++) {
+		if (d == dma) {
+			dma_ko = d;
+			break;


nitpick: could just do here if (d == dma && sof_dma_has_access(dma)) return true;

thanks @lyakh , more compact and still readable, will change

lyakh · 2025-11-24T09:05:48Z

zephyr/syscall/sof_dma.c

+	struct sof_dma *dma = z_impl_sof_dma_get(dir, cap, dev, flags);
+
+	if (sof_dma_has_access(dma))
+		return dma;


hm, firstly it's a bit unusual I think to check after executing the kernel function? Normally you'd want to prevent the "assuming benevolence" kernel function to execute on unsafe user parameters, but maybe in this case it's justified - the user can only pass integers. But if the user doesn't have access to that, shouldn't we put() before returning NULL?

Good points. The order is on purpose, so let me add an longer inline comment to explain. And yes, the put() was missing, will also added that.

lyakh · 2025-11-24T09:14:35Z

zephyr/syscall/sof_dma.c

+	if (!kern_cfg)
+		return NULL;
+
+	while (user_next) {


RFC:

for (user_next = cfg->head_block, kern_next = kern_cfg; user_next; user_next = user_next->next_block, user_next++)

s/user_next++/kern_next++/ to the last statement, but yeah, easier to read this way, will add.

lyakh · 2025-11-24T09:16:44Z

zephyr/syscall/sof_dma.c

+		case MEMORY_TO_MEMORY:
+			K_OOPS(K_SYSCALL_MEMORY_WRITE((void *)kern_next->dest_address,
+						      kern_next->block_size));
+			/* fallthrough */


COMPILER_FALLTHROUGH

Aa, thanks, changed.

lyakh · 2025-11-24T09:31:37Z

app/userspace_overlay.conf

@@ -0,0 +1,3 @@
+CONFIG_USERSPACE=y
+CONFIG_APPLICATION_DEFINED_SYSCALL=y
+CONFIG_MAX_THREAD_BYTES=3


we also have app/overlays/ptl/userspace_overlay.conf

Hmm, I was thinking there's nothing board or Intel specific in this overlay, so it could be added as a top-level overlay. The ptl overlay does seem to use more stuff (that is more board specific), so maybe I'll drop this for now and update the docs to use the baord specific overlay instead.

lyakh · 2025-11-24T09:33:28Z

zephyr/test/userspace/test_intel_hda_dma.c

+	 */
+	dma = sof_dma_get(SOF_DMA_DIR_LMEM_TO_HMEM, 0, SOF_DMA_DEV_HOST, SOF_DMA_ACCESS_SHARED);
+
+#if NEEDS_FAULT_HANDLING


if NEEDS_FAULT_HANDLING can be undefined, as it seems to be in this version, then better #ifdef

Let me drop this for now, doesn't need to be in this initial PR.

lgirdwood

LGTM so far. One comment is that does every permission failure have to be fatal ? i.e. should we return -EPERM instead of oops().

lgirdwood · 2025-11-24T11:08:07Z

src/include/sof/sof_syscall.h

+
+#include <stdint.h>
+
+#error "should not get here"


I think this is to catch inclusion on non userspace platforms, but does need more context added.

lgirdwood · 2025-11-24T11:10:18Z

src/lib/dma.c

 	k_spin_unlock(&dma->lock, key);
 }

+int z_impl_sof_dma_get_attribute(struct sof_dma *dma, uint32_t type, uint32_t *value)


optimization for later - these could be static inline in the syscall header ?

True, good point @lgirdwood . I think I was thinking there would be more in the implementation of these functions, but it's not really needed. Let me inline these right away.

lgirdwood · 2025-11-24T11:12:05Z

zephyr/CMakeLists.txt

 endif()
 zephyr_include_directories(${SOF_PLATFORM_PATH}/${PLATFORM}/include)

+zephyr_library_sources_ifdef(CONFIG_USERSPACE


I think we now have several config options around userspace, i.e. one for DP only and one for DP + infra.

@lgirdwood This is the canonical one defined in Zephyr and used all over Zephyr code when defining syscalls (in a way that still builds if user-space is not enabled in the build). I try to follow style and convetions of Zephyr even if these particular syscalls are on SOF side.

got you - so we cant drill down further for the syscalls today

lgirdwood · 2025-11-24T11:14:03Z

zephyr/syscall/sof_dma.c

+	if (!info->num_dmas)
+		return false;
+
+	for (d = info->dma_array; d < info->dma_array + info->num_dmas; d++) {


nitpick, if if info->num_dais is constant for the duration I would sum it before the loop.

Will change.

zephyr/syscall/sof_dma.c

lgirdwood · 2025-11-24T11:23:07Z

zephyr/test/userspace/README.md

@@ -0,0 +1,22 @@
+intel_hda_dma test


Love this, easy to follow and reproduce !

kv2019i

Thanks to all reviewers! Will be uploading a new series with comments addressed soonish.

kv2019i · 2025-11-24T16:56:05Z

src/include/sof/sof_syscall.h

+
+#include <stdint.h>
+
+#error "should not get here"


Oops, this is a transitional file I was supposed to remove once all contents is moved elsewhere. Will address.

kv2019i · 2025-11-24T17:21:39Z

src/lib/dma.c

 	k_spin_unlock(&dma->lock, key);
 }

+int z_impl_sof_dma_get_attribute(struct sof_dma *dma, uint32_t type, uint32_t *value)


True, good point @lgirdwood . I think I was thinking there would be more in the implementation of these functions, but it's not really needed. Let me inline these right away.

kv2019i · 2025-11-24T17:23:14Z

zephyr/CMakeLists.txt

 endif()
 zephyr_include_directories(${SOF_PLATFORM_PATH}/${PLATFORM}/include)

+zephyr_library_sources_ifdef(CONFIG_USERSPACE


@lgirdwood This is the canonical one defined in Zephyr and used all over Zephyr code when defining syscalls (in a way that still builds if user-space is not enabled in the build). I try to follow style and convetions of Zephyr even if these particular syscalls are on SOF side.

kv2019i · 2025-11-24T17:26:09Z

zephyr/syscall/sof_dma.c

+	if (!info->num_dmas)
+		return false;
+
+	for (d = info->dma_array; d < info->dma_array + info->num_dmas; d++) {


Will change.

kv2019i · 2025-11-24T17:28:14Z

zephyr/syscall/sof_dma.c

+	for (d = info->dma_array; d < info->dma_array + info->num_dmas; d++) {
+		if (d == dma) {
+			dma_ko = d;
+			break;


thanks @lyakh , more compact and still readable, will change

kv2019i · 2025-11-24T17:50:09Z

zephyr/syscall/sof_dma.c

+		case MEMORY_TO_MEMORY:
+			K_OOPS(K_SYSCALL_MEMORY_WRITE((void *)kern_next->dest_address,
+						      kern_next->block_size));
+			/* fallthrough */


Aa, thanks, changed.

kv2019i · 2025-11-24T17:53:32Z

zephyr/syscall/sof_dma.c

+	if (!kern_cfg)
+		return NULL;
+
+	while (user_next) {


s/user_next++/kern_next++/ to the last statement, but yeah, easier to read this way, will add.

kv2019i · 2025-11-24T17:57:24Z

app/userspace_overlay.conf

@@ -0,0 +1,3 @@
+CONFIG_USERSPACE=y
+CONFIG_APPLICATION_DEFINED_SYSCALL=y
+CONFIG_MAX_THREAD_BYTES=3


Hmm, I was thinking there's nothing board or Intel specific in this overlay, so it could be added as a top-level overlay. The ptl overlay does seem to use more stuff (that is more board specific), so maybe I'll drop this for now and update the docs to use the baord specific overlay instead.

kv2019i · 2025-11-24T18:02:50Z

zephyr/test/userspace/test_intel_hda_dma.c

+
+	LOG_INF("SOF thread %s (%s)",
+		k_is_user_context() ? "UserSpace!" : "privileged mode.",
+		CONFIG_BOARD_TARGET);


@lyakh I infcat copied this from your early DP PRs. This is just a convenience to have a log message printed out at start of the thread. Could be dropped as well, but given this is test code, not harmful either. Adds a nice touch to the test execution output as it print outs the board name and includes the magic "UserSpace" bit in there.

kv2019i · 2025-11-24T18:03:14Z

zephyr/test/userspace/test_intel_hda_dma.c

+	 */
+	dma = sof_dma_get(SOF_DMA_DIR_LMEM_TO_HMEM, 0, SOF_DMA_DEV_HOST, SOF_DMA_ACCESS_SHARED);
+
+#if NEEDS_FAULT_HANDLING


Let me drop this for now, doesn't need to be in this initial PR.

kv2019i · 2025-11-24T18:20:08Z

V6 pushed:

addressed review comments so far
dropped the top-level app/userspace_overlay.conf -- let's use board-specific overlays for now (already in tree)

zephyr/syscall/sof_dma.c

softwarecki

Please wrap all userspace-related changes in more specific ifdefs instead of the generic CONFIG_USERSPACE.

softwarecki · 2025-11-27T12:09:05Z

zephyr/syscall/sof_dma.c

+	 * use the Zephyr dma.h device handle to check calling
+	 * thread has access to it
+	 */
+	return k_object_is_valid(dma->z_dev, K_OBJ_ANY);


Why not K_OBJ_DRIVER_DMA ?

Good question. The DMA syscall support is being removed in Zephyr, so such definition won't be available soon. See zephyrproject-rtos/zephyr@6b350da

This definition will remain available even after the mentioned changes. It is generated by the gen_kobject_list.py script based on the driver API structure name, in this case struct dma_driver_api. The script removes the _driver_api suffix and then prefixes the name with K_OBJ_DRIVER_.

You are right @softwarecki , changed to K_OBJ_DRIVER_DMA now in V8. Thanks!

softwarecki · 2025-11-27T12:35:52Z

zephyr/syscall/sof_dma.c

+	if (!info->num_dmas)
+		return false;
+
+	for (d = info->dma_array; d < array_end; d++)


I suggest renaming d to something more descriptive, for example entry. Actually, the whole loop is unnecessary. It's enough to check if the DMA address falls within the range info->dma_array to info->dma_array + info->num_dmas.

dma - info->dma_array < info->num_dmas + align check

Ack @softwarecki . I copied the loop from existing SOF DMA code, but right, naming can be better.

I think the loop should be kept. User space can send arbitrary pointers, and we must also ensure the pointer matches start of a full kernel object, in addition to having access. Otherwise userspace can fool kernel to look up "dma->z_dev" from a middle of a struct. So the check has to ensure it is a valid pointer to kernel object, and only then proceed to use the object in kernel.

@softwarecki Sorry, I forgot to change the name. :( Let's see if this version survives the CI runs. I can rename 'd' in a follow-up if no other changes are needed. If there are changes, I'll do the rename.

@softwarecki Now changed the name

@kv2019i:

uintptr_t offset = (uintptr_t)dma - (uintptr_t)info->dma_array; if (dma < info->dma_array || dma >= array_end || offset % sizeof(struct sof_dma)) return false; return sof_dma_has_access(dma);

@softwarecki Readability wise I find that harder to follow (but maybe just me) and the modulo-divide is not free. But this does avoid the loop, so let's go with your version, updated in V9.

softwarecki · 2025-11-27T12:57:00Z

zephyr/syscall/sof_dma.c

+		K_OOPS(++i > cfg->block_count);
+		K_OOPS(k_usermode_from_copy(kern_next, user_next, sizeof(*kern_next)));


macro specifically used to terminate the user-thread

So in case of an error, the user thread will be killed and we'll end up with a memory leak from the kernel?

@softwarecki Excellent point. This does not happen now (xtensa will panic the whole system), but indeed wrong to leave this in the code. I addressed this is the new series just uploaded.

kv2019i · 2025-11-27T17:19:30Z

V7 pushed:

addressed comments from @lyakh and @softwarecki
style fixes to a few places
add more fine-granularity to CONFIG_USERSPACE. this does come with a cost, I'll add an inline comment to explain

kv2019i · 2025-11-27T17:22:19Z

zephyr/include/sof/lib/sof_dma.h

+/* include definitions from generated file */
+#include <zephyr/syscalls/sof-dma.h>
+
+#else /* !CONFIG_SOF_USERSPACE_INTERFACE_DMA */


@softwarecki @lgirdwood I now added a separate build kconfig CONFIG_SOF_USERSPACE_INTERFACE_DMA to build with CONFIG_USERSPACE but without sof-dma.

This does come with a cost that is visible (above and below this comment). When using CONFIG_USERSPACE, Zephyr autogenerates you the code to handle both user and kernel usages (zephyr/syscall/sof-dma.h). If we don't use this generic infra in our headers that expose syscalls, we need to reimplement our own wrappers like I do here. Not a deal breaker, it just looks a bit more complicated (and different than most Zephyr syscall headers). FYI, just wanted to explain why I didn't want to do this in the first place.

Thanks @kv2019i - I think we have to align with Zephyr, but add the configuraton flexibility on the SOF side.

lgirdwood · 2025-11-28T17:27:42Z

zephyr/CMakeLists.txt

 endif()
 zephyr_include_directories(${SOF_PLATFORM_PATH}/${PLATFORM}/include)

+zephyr_library_sources_ifdef(CONFIG_USERSPACE


got you - so we cant drill down further for the syscalls today

lgirdwood · 2025-11-28T17:29:26Z

zephyr/include/sof/lib/sof_dma.h

+/* include definitions from generated file */
+#include <zephyr/syscalls/sof-dma.h>
+
+#else /* !CONFIG_SOF_USERSPACE_INTERFACE_DMA */


Thanks @kv2019i - I think we have to align with Zephyr, but add the configuraton flexibility on the SOF side.

kv2019i · 2025-11-28T20:55:32Z

V8 pushed:

addressed comments from @softwarecki
renamed 'd' (forgot to do this in V7)
cleaned up ASSERT usage from test case code, use ztest.h macros instead

Expose a subset of the Zephyr DMA interface to SOF user-space threads. The functionality is selected to cover current needs of SOF DMA client usage. SOF targets that do not use userspace, are not impacted. Use a simple object lookup for kernel objects passed from user-space and check the object is a valid kernel object before proceeding to syscall implementation. This is alternative to using Zephyr gen_kobjet_list.py infra, which would require adding the SOF DMA type to the list of Zephyr kobjects. Use a similar mechanism to look up and validate the kernel object, but use runtime methods to track objects. The permission is based on DMA devices. If a thread has access to DMA device, it will get access to all channels of the DMA controller. Memory accesses are checked for permission. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

Use the sof/lib/dma.h wrapper interface to access DMA devices. This allows to run this code also from user-space. The commit has no impact to builds where userspace is not used. Also this will not impact builds where the host module is not run in user space. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

Add a new variant to boot time testing for tests that will either need the IPC host interface for test purposes and is not guaranteed to be compatible with the normla host IPC interface, or the tests cause side-effects which can influence behaviour of the firmware after tests are complete. This option is intended to run complex tests that use SOF functionality, run on target hardware, but may not coexist with normal functionality provided by SOF. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

…space Test the SOF DMA interface from a user-space thread. Use all the exported functionality using SOF_DMA_DEV_HOST. This test is using the zephyr/soc/intel/intel_adsp/tools/cavstool.py as the host-side tool. This is required as the DMA programming is split between host and DSP side and test sequences need a test endpoint on both sides. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

kv2019i · 2025-12-01T10:40:43Z

V9:

switched to loopless check for sof_dma_is_valid() as proposed by @softwarecki
no other changes

kv2019i · 2025-12-02T15:47:22Z

Ztest failure ( https://github.com/thesofproject/sof/actions/runs/19819752868/job/56779166869?pr=10341 ) is separate, fixed now in SOF main. Known fails in the jenkins CI runs.

Given no further new comments after V8 and V9, I'll proceed with merge so I can line up the next PR that builds on this.

kv2019i requested a review from jsarha October 29, 2025 19:56

kv2019i force-pushed the 202510-user-dma branch from 1043d83 to 178df79 Compare October 29, 2025 19:58

lgirdwood reviewed Oct 30, 2025

View reviewed changes

softwarecki requested review from jxstelter, serhiy-katsyuba-intel, softwarecki and tmleman October 30, 2025 15:27

kv2019i force-pushed the 202510-user-dma branch from 178df79 to 56d1e6b Compare November 6, 2025 19:22

kv2019i changed the title ~~lib: dma: add support for user-space usage (on top of PR10119)~~ lib: dma: add support for user-space usage Nov 6, 2025

kv2019i marked this pull request as ready for review November 14, 2025 12:32

Copilot AI review requested due to automatic review settings November 14, 2025 12:32

kv2019i requested review from abonislawski, bardliao, dbaluta, iuliana-prodan, lbetlej, lyakh, marcinszkudlinski, mmaka1, pblaszko and plbossart as code owners November 14, 2025 12:32

Copilot AI reviewed Nov 14, 2025

View reviewed changes

kv2019i force-pushed the 202510-user-dma branch from 85c9204 to 4d5e735 Compare November 14, 2025 12:56

kv2019i requested a review from Copilot November 14, 2025 13:01

Copilot AI reviewed Nov 14, 2025

View reviewed changes

kv2019i force-pushed the 202510-user-dma branch 2 times, most recently from 7660775 to e024fec Compare November 21, 2025 17:19

kv2019i requested review from lgirdwood and lyakh November 21, 2025 17:22

lyakh reviewed Nov 24, 2025

View reviewed changes

lgirdwood reviewed Nov 24, 2025

View reviewed changes

kv2019i commented Nov 24, 2025

View reviewed changes

kv2019i force-pushed the 202510-user-dma branch from e024fec to 6f17a50 Compare November 24, 2025 18:18

lyakh reviewed Nov 27, 2025

View reviewed changes

zephyr/syscall/sof_dma.c Outdated Show resolved Hide resolved

lyakh approved these changes Nov 27, 2025

View reviewed changes

softwarecki reviewed Nov 27, 2025

View reviewed changes

kv2019i force-pushed the 202510-user-dma branch from 6f17a50 to 272cc16 Compare November 27, 2025 17:17

kv2019i commented Nov 27, 2025

View reviewed changes

lgirdwood approved these changes Nov 28, 2025

View reviewed changes

kv2019i force-pushed the 202510-user-dma branch from 272cc16 to 5a6be58 Compare November 28, 2025 20:53

kv2019i added 4 commits December 1, 2025 12:29

kv2019i force-pushed the 202510-user-dma branch from 5a6be58 to 0a79248 Compare December 1, 2025 10:40

kv2019i merged commit 02a87a5 into thesofproject:main Dec 2, 2025
37 of 42 checks passed

softwarecki mentioned this pull request Dec 9, 2025

drivers: dai: add ability to use dai.h from user threads zephyrproject-rtos/zephyr#99811

Merged

		LOG_INF("sof_dma_get_status %d: ret %d pend %u free %u", err,
		i, stat.pending_length, stat.free);

	ret = sof_dma_reload(hd->chan->dma, hd->chan->index, 0, 0, bytes);
	ret = sof_dma_reload(hd->chan->dma, hd->chan->index, bytes);

	hda_dump_regs(HOST_OUT, HDA_REGBLOCK_SIZE, channel, "host reset");
	hda_dump_regs(HOST_OUT, HDA_REGBLOCK_SIZE, TEST_CHANNEL, "host reset");

	is disable to allow more complex tests to run.
	is disabled to allow more complex tests to run.

		EXPORT_SYMBOL(z_impl_sof_dma_get);
		EXPORT_SYMBOL(z_impl_sof_dma_put);

		K_OOPS(++i > cfg->block_count);
		K_OOPS(k_usermode_from_copy(kern_next, user_next, sizeof(*kern_next)));

lib: dma: add support for user-space usage #10341

lib: dma: add support for user-space usage #10341

Uh oh!

Conversation

kv2019i commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kv2019i commented Oct 29, 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!

kv2019i Nov 6, 2025 • 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!

kv2019i commented Nov 6, 2025

Uh oh!

kv2019i commented Nov 14, 2025

Uh oh!

kv2019i commented Nov 14, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

kv2019i commented Nov 14, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

Uh oh!

Copilot AI Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lrudyX commented Nov 19, 2025

Uh oh!

kv2019i commented Nov 21, 2025

Uh oh!

kv2019i commented Nov 21, 2025

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

kv2019i commented Oct 29, 2025 •

edited

Loading

kv2019i Nov 6, 2025 •

edited

Loading

lgirdwood left a comment •

edited

Loading