Skip to content

llext: fully relocatable llext modules in virtual memory - #11037

Open
lgirdwood wants to merge 3 commits into
thesofproject:mainfrom
lgirdwood:topic/llext-relocatable
Open

llext: fully relocatable llext modules in virtual memory#11037
lgirdwood wants to merge 3 commits into
thesofproject:mainfrom
lgirdwood:topic/llext-relocatable

Conversation

@lgirdwood

Copy link
Copy Markdown
Member

Fully relocatable modules, they - TODO need to reuse virtual memory block allocator.

When CONFIG_LLEXT_TYPE_ELF_RELOCATABLE is active, bypass appending
static address flags (-Ttext, --section-start, -Tdata) in the linker
helper script. This keeps section base addresses at 0.
Also adjust the offset calculator to avoid integer parsing errors
when all section addresses are set to 0.

Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>

@lgirdwood lgirdwood left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to use single virtual page source for all virtual page allocations.

Comment thread src/library_manager/llext_manager.c Outdated
#include <zephyr/llext/elf.h>

#define LLEXT_LIB_PAGES (CONFIG_LIBRARY_REGION_SIZE / PAGE_SZ)
SYS_BITARRAY_DEFINE_STATIC(lib_vma_bitarray, LLEXT_LIB_PAGES);

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see zephyr/lib/alloc.c and the zephyr TLB driver for ACE platforms, we want to have a single VMA allocation i.e. teh one used by vpage allocator should be used.

lrgirdwo added 2 commits July 28, 2026 21:34
…table modules

Implement page-level virtual memory mapping for LLEXT libraries by
reserving VMA ranges from the single shared vpage allocator
(zephyr/lib/vpage.c), the same allocator already used by the vregion
pipeline-resource-management code. This avoids introducing a second,
private virtual-address allocator/region for libraries and keeps all
virtual page bookkeeping in one place.

Compile section layout at load-time to allocate virtual addresses and
rewrite section sh_addr headers in-place. This enables Zephyr LLEXT to
naturally relocate references.

Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Enable CONFIG_LLEXT_EXPORT_BUILTINS_BY_SLID=y in llext_relocatable.conf
to link relocatable LLEXT modules against build-time function signature
hashing, providing load-time ABI mismatch protection.

Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
@lgirdwood
lgirdwood force-pushed the topic/llext-relocatable branch from b5c9b93 to 4dd5e85 Compare July 28, 2026 20:35
size_t num_pages = ALIGN_UP(size, PAGE_SZ) / PAGE_SZ;
void *vma;

vma = vpage_reserve(num_pages);

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Today this is both text/data, but will have to be updated later to split text/data.

@lgirdwood
lgirdwood marked this pull request as ready for review July 29, 2026 13:23
@lgirdwood lgirdwood changed the title WIP: fully relocatable llext modules in virtual memory llext: fully relocatable llext modules in virtual memory Jul 29, 2026

@lyakh lyakh left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find this PR a bit confusing:
The first commit seems to remove fixed addresses from link scripts, but only some parts of it. There is quite a large amount of code in Python and cmake that currently handle address calculation, all that seems to be left intact. Is this already working? Is this enough to switch to linking for whatever addresses SRAM ends up mapped for? Don't think it can work - we link in DRAM only once, and if we map LLEXT SRAM to different addresses without relinking this won't be correct.
The second patch is switching from VMH to vpage. That would be good, but not necessarily directly related.
The third patch enabled SLID LLEXT linking which seems to be unrelated too.
Is this a draft?


static uintptr_t llext_manager_alloc_vma(size_t size)
{
size_t num_pages = ALIGN_UP(size, PAGE_SZ) / PAGE_SZ;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DIV_ROUND_UP()

Comment thread zephyr/lib/vpage.c
}

/* check we found allocation element */
CHECKIF(!pages) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there any value in having this be either an assertion or a NOP depending on configuration?

@lgirdwood

Copy link
Copy Markdown
Member Author

I find this PR a bit confusing: The first commit seems to remove fixed addresses from link scripts, but only some parts of it. There is quite a large amount of code in Python and cmake that currently handle address calculation, all that seems to be left intact. Is this already working? Is this enough to switch to linking for whatever addresses SRAM ends up mapped for? Don't think it can work - we link in DRAM only once, and if we map LLEXT SRAM to different addresses without relinking this won't be correct. The second patch is switching from VMH to vpage. That would be good, but not necessarily directly related. The third patch enabled SLID LLEXT linking which seems to be unrelated too. Is this a draft?

Not a draft, its from a larger series for another feature that is being worked on. It is missing some changes though which have been squashed elsewhere. Copilot review is pending credits.

The key point is that we dont fix addresses at build time as modules should be independently built from each other. i.e. we work in a similar way to Linux modules where memory location is determine at runtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants