Closed skalk closed 2 weeks ago
All platforms fail to build...
.../repos/base-hw/src/core/kernel/cpu.cc:25:10: fatal error: hw/memory_consts.h: No such file or directory
25 | #include <hw/memory_consts.h>
Commit 69507865692b768a2a077991fcc21388e0fe468a fixes builds inside build directory by explicitly stating the dependency to hw/memory_consts.h. But, ./tool/depot/create UPDATE_VERSIONS=1 FORCE=1 genodelabs/bin/x86_64/base-hw-pc
still fails. Note, using make -j1
in a clean build directory triggers the issue reliably.
@chelmuth sorry for the hassle! Fixup commit 1835000 is still needed to build the base-hw-* packages.
We're almost there. The last missing piece is memory_consts.s on riscv/migv, which ommit https://github.com/genodelabs/genode-riscv/commit/c5ffe94ce6a9917dbed70ae5208366db2ef67ac7 addresses. @skalk please check
@chelmuth: yes almost, I've found another minor issue of the commit corrected by fixup commit 8b8aa43. You riscv fixup commit seems correct to me.
Nowadays, we have a fixed size array of per CPU kernel-stacks and CPU objects (aggregating e.g., scheduler, timer, idle thread,...) within the base-hw kernel. This static array approach is problematic in case of platforms with CPU counts not known at compilation time. Either we loose a lot of memory to keep space for all potential CPUs, or we don't support all of the available ones. Also the CPU numbering doesn't need to be continous necessarily, which led to a translation step in between CPU number and array access in the past on x86. Furthermore, the continous per CPU kernel-stack array had no room for a stack-boundary protection page.
Having a dedicated virtual memory area per CPU with a fixed layout including stack, cpu object data, and potential for more cpu local data is a natural step to solve above described limitations, and to open room for future optimizations if cpu-local in-kernel operation gets extended without polluting global data (and locks).
As a first step, it is planned to move kernel stacks and cpu objects inside a dedicated virtual memory area across all architectures. Thereby, the area gets backed with memory in bootstrap after knowing the concrete CPU count.
This issue was part of former issue #1252