Multi-core Guest OS Loading via Hypervisor Memory Mapping
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Safety-critical avionics processing systems face challenges in meeting startup timing requirements due to the complexity of hosting multiple guest operating systems (GOS) in multi-core processors, particularly in cold starts and immediate resumption during warm starts.
Innovation Solution
A system and method for loading guest operating systems (GOS) in a multi-core processing environment that utilizes system RAM for rapid execution, where a default core loads and maps the hypervisor and GOS runtime images to other cores, leveraging faster RAM speeds to simplify and accelerate the startup process.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If multiple GOS images are loaded into system RAM for simultaneous hosting on multi-core processors, then the system can host multiple guest operating systems concurrently, but the startup timing requirements become more complex and difficult to meet
Solution Approach 1:
The patent applies preliminary action by pre-loading the hypervisor runtime image into system RAM before the GOS runtime images are needed. This allows the hypervisor to be ready in high-speed memory when the system boots, eliminating the need to load it from flash memory during the time-critical startup phase. The hypervisor is loaded once and then mapped to multiple cores, preparing the foundation for subsequent GOS loading while meeting startup timing requirements.
Solution Approach 2:
The patent uses copying by creating multiple mappings of the single hypervisor runtime image to different processor cores through memory mapping. Instead of loading separate copies of the hypervisor for each core, the system creates virtual memory mappings that allow multiple cores to access the same hypervisor instance in RAM. This reduces memory usage while enabling concurrent execution on multiple cores, and accelerates startup compared to loading from flash.
2Speed
If GOS runtime images are loaded from flash memory to system RAM for execution, then the GOS can execute rapidly, but the loading process becomes complex during cold starts and warm restarts
Solution Approach 1:
The patent applies segmentation by dividing the loading process into distinct phases: first loading the hypervisor runtime image separately, then loading individual GOS runtime images. Each core that needs to run a GOS loads only its specific GOS image rather than all GOS images, and the hypervisor is loaded once and shared across cores. This segmentation simplifies the overall loading process by breaking it into manageable stages and reducing redundant loading operations.
Solution Approach 2:
The patent applies universality by using system RAM as a multi-functional resource that serves both as the loading destination for hypervisor images and as the execution memory for GOS images. The same memory regions are used for both purposes depending on the phase of operation. Additionally, the hypervisor runtime image serves multiple functions by being mapped to multiple processor cores, allowing a single image to support concurrent execution on multiple cores.
3Reliability
If the system uses cold start procedures to boot after nonuse, then all components can be initialized, but instruments must become operational within 10 to 20 seconds which is difficult with multiple GOS loading
Solution Approach 1:
The patent applies preliminary action by loading the hypervisor runtime image into system RAM during the initialization phase before any GOS loading occurs. This preliminary loading of the hypervisor establishes the virtualization infrastructure in high-speed memory, enabling subsequent GOS images to be loaded and executed rapidly. This preliminary setup ensures that the time-critical path for instrument operational status is not blocked by sequential loading of multiple large GOS images from flash memory.
4Productivity
If the system performs warm restart to resume operations immediately, then operational continuity is maintained, but safety-critical sensors and displays must resume within a fraction of a second which complicates multiple GOS loading
Solution Approach 1:
The patent applies copying by creating memory mappings of the hypervisor runtime image to multiple processor cores simultaneously. During warm restart, this allows the hypervisor to be rapidly restored in memory and made available to multiple cores without sequential loading delays. The memory mapping mechanism enables near-simultaneous activation of multiple GOS instances across different cores, meeting the sub-second warm restart requirements for safety-critical systems while maintaining operational continuity.
Data Source
AI summary
A system and related method for guest OS loading in a multi-core processing environment optimizes the startup process by loading a hypervisor runtime image to an allocated memory location, from which the processing cores individually activate and execute the runtime image rather than reloading the runtime image. For guest operating systems executing across multiple processing cores, a single core may load the associated guest OS image to allocated memory space in the system RAM. The remaining cores on which that guest OS is configured to execute may then copy the loaded guest OS image to their own respective allocated system RAM, and execute the copied guest OS images therefrom.