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.
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 |
b7c90f7 to
79c82a4
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
Add syspage_part_t struct to keep partition configuration, starting with MPU registers and arrays of maps for allocation and access. JIRA: RTOS-1149
Iterate over all allocation maps from syspage_part_t struct when allocating memory using mmap to increase allocation flexibility. Allows for uncached map selection eg. for buffers for HW communication. Verify map access inside munmap and mprotect. 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
Increase syspageCopied to fit partitions and scheduling windows in syspage space. JIRA: RTOS-1149
79c82a4 to
1ef56c6
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