Skip to content

180 adaptation for avz support #181

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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

daniel-rossier
Copy link
Contributor

This PR brings a new way to configure heap and stack size in SO3. Now, sizes are configured by means of Kconfig variables. It also fixes several potential issues with the previous hardcoded stack sizes in the linking script.
Furthermore, a lot of changes have been made at AVZ (hypervisor level) to get a more aligned version as it is used in the SOO framework.
All defconfig and its files have been cleaned up and adapted accordingly.

@daniel-rossier daniel-rossier linked an issue Jul 21, 2025 that may be closed by this pull request
@daniel-rossier daniel-rossier self-assigned this Jul 21, 2025
Copy link
Contributor

@AndreCostaaa AndreCostaaa left a comment

Choose a reason for hiding this comment

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

If you want to go forward with the toolchain changes, I would maybe open a new PR, that simply adds the toolchain here
https://github.com/smartobjectoriented/so3/blob/main/docker/Dockerfile.env#L26-L29

Once we merge that PR, we can then rebase main here and make the CI go green

Additionally, all of the AVZ and SOO configs aren't tested by the CI, we already test virt_fb configs so we should also add those configs since there's gonna be a lot of changes in the upcoming months to that part of the codebase. Adding new SO3 configs should be as easy as adding new entries here:

CONFIG: ['virt32_fb_defconfig',
'virt64_fb_defconfig',
'virt32_lvperf_defconfig',
]

Unless there are specific dependencies missing and in that case they also need to get added to the Dockerfile mentionned above. We could imagine getting rid of the dockerfile and instead have the CI install the necessary dependencies so that we can more easily go forward with these types of changes

Let me know what you think about those ideas

CONFIG_ARCH="arm64"
CONFIG_CROSS_COMPILE="aarch64-none-linux-gnu-"
CONFIG_CROSS_COMPILE="aarch64-none-elf-"
Copy link
Contributor

Choose a reason for hiding this comment

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

So is the musl idea put on standby for now ?

I'm fine with changing it but please install it in the docker image env Dockerfile:

# Download aarch64-none-linux-gnu toolchain
RUN wget https://armkeil.blob.core.windows.net/developer/Files/downloads/gnu-a/10.3-2021.07/binrel/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz
RUN tar -xvf gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz
RUN rm gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz

Copy link
Contributor Author

@daniel-rossier daniel-rossier Aug 2, 2025

Choose a reason for hiding this comment

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

Well, this is for the kernel compilation, not for the user space. We have to keep the linux toolchain since it's used by the user space. We will migrate to a MUSL toolchain in the coming months.
Does it make sense?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes it does, different toolchains for the kernel and user space. Sounds good to me
We still need to install it in the dockerfile though to make the CI pass

@@ -672,6 +684,6 @@ void threads_init(void)
{
int i;

for (i = 0; i < THREAD_MAX; i++)
for (i = 0; i < CONFIG_MAX_THREADS; i++)
Copy link
Contributor

Choose a reason for hiding this comment

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

I got a bit confused at first why here we're using CONFIG_MAX_THREADS while PROC_MAX_THREADS is used at line 205

Would you consider removing this define: #define PROC_MAX_THREADS CONFIG_MAX_THREADS and simply using CONFIG_MAX_THREADS throughout the code ? It would make the code easier to reason with

Copy link
Contributor Author

@daniel-rossier daniel-rossier Aug 2, 2025

Choose a reason for hiding this comment

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

Yes, I agree. Even if the number_of_proc X CONFIG_MAX_THREADS will be incorrect since CONFIG_MAX_THREADS means the number of threads in the whole system.
In the future, we should consider to divide CONFIG_MAX_THREADS by the max. number of process which would be more accurate. Or should we implement this now?

Copy link
Contributor

Choose a reason for hiding this comment

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

Can be done in another PR, we could remove that #define so that we use the same constant throughout the whole code. What do you think ?

daniel-rossier and others added 2 commits August 2, 2025 09:47
Co-authored-by: André Costa <[email protected]>
Co-authored-by: André Costa <[email protected]>
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.

Adaptation for AVZ support
2 participants