Loading management hypervisors from a system control processor
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Booting management hypervisors in traditional systems imposes significant requirements on system firmware, particularly Unified Extensible Firmware Interface (UEFI) drivers, making implementation difficult and costly, and some devices lack necessary UEFI support for host device hardware.
Innovation Solution
Execute a first stage bootloader of a management hypervisor from a system control processor (SCP) as a Linux or POSIX-like user-space application, utilizing block, filesystem, network, console, and I/O facilities to build boot data handoff structures for hardware identification and memory maps.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If UEFI firmware with drivers is used for booting management hypervisors, then system compatibility and hardware support are improved, but implementation cost and complexity increase significantly
Solution Approach 1:
The patent introduces a bootloader as an intermediary component that runs in user space rather than requiring kernel space drivers. This bootloader acts as a mediator between the UEFI firmware and the management hypervisor, handling hardware interaction through standard system calls instead of requiring complex driver implementations. The bootloader translates hardware-specific operations into generic system calls that work across different hardware platforms, thereby maintaining system compatibility while reducing implementation complexity.
Solution Approach 2:
The system enables self-service by allowing the bootloader to automatically detect and initialize hardware resources using standard system calls without requiring pre-configured drivers. The bootloader queries hardware information through the operating system's system call interface and dynamically configures itself, eliminating the need for manual driver installation and configuration. This self-service approach reduces implementation complexity while maintaining hardware support through automatic adaptation.
2Adaptability or versatility
If UEFI drivers are implemented for all device hardware, then hardware support capability is improved, but development investment and cost increase
Solution Approach 1:
The patent implements universality by designing a bootloader that can interact with diverse hardware through a unified interface of standard system calls. Instead of creating separate driver code for each hardware device, the bootloader uses generic system call mechanisms provided by the operating system to access hardware resources. This multi-functional approach allows the same bootloader code to support multiple hardware platforms without requiring device-specific driver implementations, thereby maintaining hardware support capability while reducing development investment.
Solution Approach 2:
The system employs parameter changes by dynamically querying hardware characteristics through system calls and adjusting its behavior based on the detected hardware configuration. Rather than hardcoding driver parameters for specific devices, the bootloader changes its operational parameters based on runtime hardware detection. This allows the system to adapt to different hardware configurations without requiring separate driver code for each device type, reducing development costs while maintaining versatility.
3Power
If traditional kernel space drivers are used, then direct hardware control is improved, but system requirements and firmware dependencies increase
Solution Approach 1:
The patent transitions from the traditional kernel space dimension to user space, representing a dimensional change in the software architecture. By moving the bootloader to user space, the system maintains hardware control capability through the operating system's system call interface while avoiding the complexities of kernel space programming. This dimensional shift allows direct hardware interaction without requiring firmware drivers, as the user space bootloader can request hardware resources through standardized system calls that are handled by the operating system kernel.
Data Source
AI summary
Disclosed are various examples of loading management hypervisors from a system control processor. In some examples, a host device executes a first stage bootloader of a management hypervisor from a system control processor. The first stage bootloader loads management hypervisor data and firmware instructions into a main processor memory of a main processor, and initializes the main processor to execute the firmware instructions. The system then jumps to a second stage bootloader that configures and launches the management hypervisor using the management hypervisor data.