Virtual Address Mapping for Shared Code in Multi-Processor Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing solutions for executing the same executable code on multiple processors result in cache waste and performance issues due to repeated copying of code, and the use of GS and kernel GS registers by guest operating systems prevents hypervisors from accessing per-processor structures efficiently.
Innovation Solution
A virtual address mapping system where a single physical copy of code is shared across multiple processing units, with each unit accessing its own data using a common offset value, ensuring efficient data addressing and preventing cache overload by mapping code and data portions to separate virtual addresses with a unique offset.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Speed
If the same executable code is copied into different physical memory locations for each processing unit, then fast per-processor memory access is achieved, but cache content is wasted and thrashed, lowering performance and requiring larger memories
Solution Approach 1:
The patent merges the code execution functionality across multiple processing units by allowing them to share a single physical copy of executable code in memory. Instead of copying code to each processor, the system enables concurrent access to the same code region, combining the code resource into a shared entity that serves multiple processors simultaneously.
Solution Approach 2:
The patent makes the single code memory region universal by enabling it to serve multiple processing units for code execution. The same physical memory location containing executable code becomes a multi-functional resource that can be accessed by different processors, eliminating the need for processor-specific code copies.
2Ease of operation
If GS and kernel GS registers are used by guest operating systems in virtual machines, then per-processor structure access is enabled for guests, but hypervisors cannot use these registers to access their own per-processor structures
Solution Approach 1:
The patent segments the register usage by processing unit type. It introduces distinct register allocation schemes where virtual processing units (guests) use GS/kernel GS registers for per-processor structure access, while the hypervisor uses alternative mechanisms (such as different register sets or memory mapping approaches) to access its own per-processor structures, preventing register conflicts.
Solution Approach 2:
The patent introduces an intermediary layer in the form of a hypervisor-specific memory mapping or alternative register interface. This intermediary mechanism allows the hypervisor to access per-processor structures without directly competing for the GS/kernel GS registers that are reserved for guest operating systems, thereby mediating the resource conflict.
3Quantity of substance
If executable code is shared across multiple processing units without copying, then memory requirements are reduced and cache efficiency is improved, but mechanisms are needed to provide fast access to per-processor structures
Solution Approach 1:
The patent transitions from horizontal code distribution (copying code across processors) to vertical data organization (structuring per-processor data in memory with predictable offsets). By organizing per-processor structures in separate memory regions with fixed offset relationships from the shared code base, the system enables fast access through dimensional separation of code and data spaces.
Solution Approach 2:
The patent performs preliminary setup of memory mappings and offset calculations during system initialization. Per-processor structure locations are pre-determined and cached in processor registers or control structures, allowing processors to quickly access their own data structures without performing complex address calculations during runtime, thus maintaining fast access speeds despite shared code.
Data Source
AI summary
A method and apparatus for virtual address mapping are provided. The method includes determining an offset value respective of at least a first portion of code stored on a code memory unit, generating a first virtual code respective of the first portion of code and a second virtual code respective of a second portion of code stored on the code memory unit; mapping the first virtual code to a first virtual code address and the second virtual code to a second virtual code address; generating a first virtual data respective of the first portion of data and a second virtual data respective of the second portion of data; and mapping the first virtual data to a first virtual data address and the second virtual data to a second virtual data address.