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 Results7 958 tests 7 292 ✅ 40m 46s ⏱️ For more details on these failures, see this check. Results for commit d070577. ♻️ 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
7e55990 to
f71f39d
Compare
77700ae to
fe883f8
Compare
c4d58c6 to
2db3826
Compare
2db3826 to
1bf3c6e
Compare
|
Changed base branch to avoid problems with branch protection while rebasing and CI errors spam. At the same time, changed the implementation from by default creating partition-per-app to single default partition, as it seems like a cleaner for the future features. Introduced Per-CPU scheduler configuration for improved elasticity Removed NOMMU multimap allocation, as it was only partially implemented and broke with the new conception of default partition. Will be introduced in the future together with MMU NUMA support. |
1bf3c6e to
d8dab34
Compare
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
d8dab34 to
9e8494f
Compare
8cf9a9e to
f972678
Compare
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
9e8494f to
d070577
Compare
Description
Introduce spatial and temporal partitioning support in the kernel.
Key changes:
syspage_part_tpartition abstraction holding partition configurationNOTE: this is a starting point version, related partitioning features will be in active development during upcoming weeks/months.
Work-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