Introduce Kernel Partitioning #745
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a fundamental kernel partitioning mechanism, significantly enhancing resource isolation and management capabilities. It refactors core operating system components, including memory management, scheduling, and inter-process communication, to be partition-aware. This change allows for stricter control over how processes consume resources and interact with each other, leveraging hardware features like MMUs/MPUs for robust separation. The scheduler now supports distinct scheduling windows for different partitions, and memory allocations are tracked per partition, laying the groundwork for more secure and predictable real-time systems. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a new memory partitioning and scheduling mechanism, primarily affecting ARMv7M, ARMv7R, and ARMv8M architectures. Key changes include modifying the pmap_t structure to link directly to a hal_syspage_part_t for MPU configuration, refactoring pmap_switch and pmap_isAllowed to utilize this new structure, and removing dynamic MPU region management functions. The syspage.h and architecture-specific syspage.h files are updated to define syspage_part_t and syspage_sched_window_t structures, allowing for per-partition memory and scheduling configurations. Process and thread management functions, such as proc_start, vm_objectGet, vm_pageAlloc, and vm_pageFree, are updated to accept a syspage_part_t argument, enabling resource tracking and access control based on partitions. Additionally, IPC functions (proc_send, proc_recv) now include msg_isAllowed checks based on partition flags, and the scheduler (proc/threads.c) is enhanced to support multiple scheduling windows and per-partition ready/sleeping queues. Review comments highlight critical security vulnerabilities in NOMMU systems where syscalls_sys_munmap and syscalls_sys_mprotect could allow unprivileged processes to modify or unmap kernel memory due to a lack of ownership verification. Another comment points out potential memory leaks in the _threads_init function if vm_kmalloc calls fail, as allocated resources are not properly freed.
Unit Test Results10 860 tests 10 190 ✅ 54m 40s ⏱️ Results for commit 298fa23. ♻️ This comment has been updated with latest results. |
19dc388 to
b7c90f7
Compare
adamgreloch
left a comment
There was a problem hiding this comment.
This is quite a complex functionality. I'd add some more comments about the introduced scheduling scheme (explicit description of background+cyclical partitions) and explain a bit the wakeup manipulations
|
Why does this PR include commits from master (by adamgreloch and jmaksymowicz)? |
Ideally, I would like to rebase feature/partitioning to master, but I don't have the write permissions. EDIT: this time fixed by recreating the |
79c82a4 to
1ef56c6
Compare
|
/gemini review |
|
Warning Gemini is experiencing higher than usual traffic and was unable to create the review. Please try again in a few hours by commenting |
1ef56c6 to
f2de3ca
Compare
f2de3ca to
f9d347a
Compare
|
/gemini review come on tin-man |
There was a problem hiding this comment.
Code Review
This pull request introduces support for partitions and scheduling windows across multiple architectures, enabling resource isolation and time-partitioned execution. Key changes include updating memory management (vm_pageAlloc, vm_pageFree, vm_objectGet) to track usage per partition, modifying the scheduler to handle per-window ready queues and sleeping trees, and enforcing partition-based access controls for IPC and process spawning. Review feedback identifies critical risks of NULL pointer dereferences in the thread initialization logic if scheduling windows or partitions are not explicitly defined in the syspage.
f9d347a to
7e55990
Compare
5480ed5 to
3a4fc4b
Compare
85b1b60 to
6832a74
Compare
6832a74 to
ee99d9a
Compare
e5a231d to
a0294c4
Compare
4a5705f to
cfd8180
Compare
|
/gemini review again, lots of new changes happened since |
There was a problem hiding this comment.
Code Review
This pull request introduces spatial and temporal partitioning by adding partition structures, tracking memory usage per partition, and implementing scheduler windows. However, several critical issues must be addressed. These include security vulnerabilities in the optimized MPU context switching loops for ARMv7-M and ARMv8-M that could bypass spatial isolation, potential kernel crashes from missing NULL pointer checks on partitions and scheduler configurations, integer overflows in partition memory limit checks, and missing bounds checks in scheduler loops and MPU region counts that could lead to out-of-bounds reads or crashes.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
cfd8180 to
52cd55f
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces partition-based scheduling and memory allocation limits across various architectures and kernel subsystems, updating page allocation, memory mapping, process spawning, and thread scheduling to support partition-specific resource tracking. The code review highlights several critical compatibility issues on MMU-enabled systems where physical maps are NULL, which would cause kernel panics or spawn/exec failures. Additionally, feedback points out potential NULL pointer dereferences when partitions or scheduler configurations are missing, register corruption in ARMv8-M inline assembly due to a missing earlyclobber constraint, and potential out-of-bounds reads in MPU configuration if allocCnt is not capped.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
It seems gemini gets lost in larger PR's like this, it makes a lot of false assumptions (phMaps being NULL on kmap/MMU, malicious syspage validation etc.). To anybody reviewing it (human or AI), I recommend going commit-by-commit, as I am putting some effort to keep these changes neatly organized. In the future, when there is more resources to review these changes and actually merge them, it might be a good idea to split that into multiple PRs. |
|
Please resolve all false positive comments created by Gemini. |
Introduce full MPU regions reconfiguration on context switch, allowing for more flexibile configuration of memory maps on MPU targets. Performed tests show no memory coherence problems and minor improvements in pmap_switch performance. According to ARM documentation, cache maintenance is not required, as long as memory maps are not overlapping, and that assumption is already present in Phoenix-RTOS. Changes include * additional hal_syspage_prog_t structure, initialized in loader, containing program configuration of MPU regions in form of ready-to-copy register values * pmap_t structure contain pointer to above structure instead of regions bitmask * pmap_switch disables MPU and performs full reconfiguration, optimized with LDMIA/STMIA assembly operations * handling of process's kernel-code access is moved to loader JIRA: RTOS-1149
Add syspage_part_t struct to keep partition configuration, starting with MPU registers. JIRA: RTOS-1149
Introduce scheduler windows to allow for partitions temporal separation. Move timer update to _threads_schedule on all cores to reduce the use of threads_common.spinlock and make wakeup calculation atomic with schedule JIRA: RTOS-1149
Introduce accounting mechanism for partition allocated pages to provide resource safety for critical partitions, as there is no other mechanism for separating physical maps for targets with MMU. JIRA: RTOS-1149
Standard, synchronous messaging system is unsuitable for inter-partition communication, especially without timeouts which are not supported yet. For Inter-Partition Communication non-blocking, shared-memory based communication is recommended. JIRA: RTOS-1149
Reduce inter-partition interference by separating partition sleeping trees. JIRA: RTOS-1149
JIRA: RTOS-1285
Increase syspageCopied to fit partitions and scheduling windows in syspage space. JIRA: RTOS-1149
Support for physical maps on MMU targets to allow for greater isolation and better utilization of platforms with NUMA. JIRA: RTOS-1244
Unify system behavior between MMU and NOMMU targets. TASK: RTOS-1149
a0294c4 to
a61719e
Compare
52cd55f to
298fa23
Compare
Description
Introduce spatial and temporal partitioning support in the kernel.
Key changes:
syspage_part_tpartition abstraction holding partition configurationWork-In-Progress partitioning documentation
Motivation and Context
Separation mechanisms for safety-critical and mixed-criticality systems where spatial and temporal isolation between groups of processes must be guaranteed.
Types of changes
How Has This Been Tested?
Checklist:
Special treatment