Secondary CPU MMU Initialization via Page Fault Exception
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multiple CPU systems, initializing the memory management unit (MMU) during the bring-up of secondary CPUs is challenging due to the potential for address conflicts between the physical addresses of the bring-up code and the virtual addresses of the OS kernel code or data, especially on architectures where memory locations are arbitrary, leading to failed initialization processes.
Innovation Solution
The method involves executing an activation instruction to cause the MMU to perform address mapping based on page tables, triggering a page fault exception for an unmapped virtual address, and then fetching and executing instructions from a mapped virtual address to ensure proper initialization of the secondary CPU, decoupling the virtual and physical memory mapping of the bring-up code.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If identity mapping (VA equals PA) is used for bring-up code, then the bring-up code can be located at a fixed address, but this approach fails on architectures with arbitrary memory locations due to conflicts with kernel code or data
Solution Approach 1:
The patent changes the memory mapping parameters by introducing a temporary page table entry that maps a virtual address to a physical address different from the identity mapping. This allows the bring-up code to be executed at a virtual address that maps to a safe physical location, avoiding conflicts with kernel code while maintaining address stability during execution.
Solution Approach 2:
The patent introduces a page table as an intermediary layer between virtual addresses and physical addresses. The page table temporarily maps the bring-up code's virtual address to a safe physical address, acting as a mediator that resolves the conflict between arbitrary memory locations and the need for stable code execution addresses.
2Device complexity
If MMU is activated with identity mapping, then virtual addresses equal physical addresses simplifying the process, but this causes execution flow to be unintentionally diverted to kernel code or data when memory locations are arbitrary
Solution Approach 1:
The patent temporarily modifies the page table parameters to create a safe mapping for the bring-up code. By setting a page table entry to map a specific virtual address to a safe physical address, the system maintains simple address mapping during bring-up while preventing execution flow diversion to kernel code.
Solution Approach 2:
The patent performs preliminary setup of the page table before activating the MMU for bring-up code execution. The page table is configured in advance to map the bring-up code's virtual address to a safe physical address, ensuring that when the MMU is activated, the correct mapping is already in place and execution flow is directed to the intended location.
3Adaptability or versatility
If bring-up code is located at arbitrary memory locations, then architecture flexibility is improved, but conflicts with kernel code or data occur when MMU is activated
Solution Approach 1:
The patent uses the page table as an intermediary to resolve address conflicts. The page table maps virtual addresses to physical addresses, allowing the bring-up code to be located at arbitrary memory locations while preventing conflicts with kernel code by directing access to safe physical addresses through the page table mapping.
Solution Approach 2:
The patent dynamically changes the memory mapping parameters by creating a temporary page table entry that maps the bring-up code's virtual address to a safe physical address. This parameter change allows arbitrary memory locations to be used while avoiding address conflicts with kernel code or data.
Data Source
AI summary
In a computer system with multiple central processing units (CPUs), initialization of a memory management unit (MMU) for a secondary CPU is performed using an exception generated by the MMU. In general, this technique leverages the exception handling features of the secondary CPU to switch the CPU from executing secondary CPU initialization code with the MMU “off” to executing secondary CPU initialization code with the MMU “on.” Advantageously, in contrast to conventional techniques for MMU initialization, this exception-based technique does not require identity mapping of the secondary CPU initialization code to ensure proper execution of the secondary CPU initialization code.