llext: fully relocatable llext modules in virtual memory - #11037
llext: fully relocatable llext modules in virtual memory#11037lgirdwood wants to merge 3 commits into
Conversation
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
left a comment
There was a problem hiding this comment.
Need to use single virtual page source for all virtual page allocations.
| #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); |
There was a problem hiding this comment.
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.
…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>
b5c9b93 to
4dd5e85
Compare
| size_t num_pages = ALIGN_UP(size, PAGE_SZ) / PAGE_SZ; | ||
| void *vma; | ||
|
|
||
| vma = vpage_reserve(num_pages); |
There was a problem hiding this comment.
Today this is both text/data, but will have to be updated later to split text/data.
There was a problem hiding this comment.
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; |
| } | ||
|
|
||
| /* check we found allocation element */ | ||
| CHECKIF(!pages) { |
There was a problem hiding this comment.
is there any value in having this be either an assertion or a NOP depending on configuration?
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. |
Fully relocatable modules, they - TODO need to reuse virtual memory block allocator.