CPU Core Fault Isolation in Failed Secondary AMP Instances
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing asymmetric multiprocessing (AMP) systems face challenges in isolating and recovering CPU cores from a failed secondary instance without impacting the primary instance, particularly during system upgrades, leading to undesirable shutdowns and downtime.
Innovation Solution
Implementing a fault isolation mechanism that includes a custom panic handler and non-maskable interrupt (NMI) handler to isolate faults within the secondary instance, allowing recovery of CPU cores by switching the context of the bootstrap core to the primary instance using shared memory and real mode trampoline page directory table addresses.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a conventional panic handler is used in the secondary instance, then the fault can be detected and handled, but the entire system shuts down including the primaryinstance, causing loss of time and reliability degradation
Solution Approach 1:
The patent segments the fault handling mechanism by implementing instance-specific panic handlers that operate independently within each AMP instance. The secondary instance's panic handler is configured to detect and isolate faults within its own context without propagating to the primaryinstance, enabling selective fault containment and maintaining system continuity during upgrades
Solution Approach 2:
The patent introduces an intermediary mechanism through the shared memory space and controlled panic handler interaction. The secondary instance's panic handler acts as an intermediary that can signal the primaryinstance through shared memory without directly controlling the primaryinstance's execution, allowing coordinated fault isolation and recovery while maintaining primaryinstance operation
2Ease of repair
If the secondaryinstance fails during boot, then fault detection is possible, but CPU cores cannot be recovered and must be restarted, increasing loss of time
Solution Approach 1:
The patent implements preliminary action by having the secondaryinstance's panic handler prepared in advance to detect boot failures and isolate affected CPU cores before they can cause system-wide shutdown. The panic handler is pre-configured with knowledge of the boot process stages and can immediately begin fault isolation when a failure occurs, enabling faster recovery
Solution Approach 2:
The patent applies discarding and recovering by allowing the secondaryinstance to discard its failed boot state and isolated fault information back to the primaryinstance through shared memory. The primaryinstance can then recover the CPU cores by rewriting the bootstrap core context to point to the primaryinstance's execution state, effectively recovering cores without full system restart
3Reliability
If fault isolation is implemented between AMP instances, then system reliability improves, but device complexity increases due to additional handlers and shared memory mechanisms
Solution Approach 1:
The patent applies universality by designing the panic handler mechanism to serve multiple functions: fault detection, fault isolation, and coordinated recovery. The same panic handler infrastructure used in the secondaryinstance can be leveraged by the primaryinstance for recovery operations, reducing overall system complexity compared to having separate dedicated isolation mechanisms
Solution Approach 2:
The patent uses copying by having the secondaryinstance's panic handler create a simplified copy of the fault state information in shared memory rather than copying the entire execution context. This selective copying approach provides sufficient information for the primaryinstance to recover CPU cores without duplicating complex runtime state, balancing reliability with complexity
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
According to certain embodiments, a system includes one or more processors and one or more computer-readable non-transitory storage media comprising instructions that, when executed by the one or more processors, cause one or more components to perform operations including executing a software process of a secondary instance, the secondary instance running in parallel with a primary instance and associated with a plurality of cores including a bootstrap core, registering a non-maskable interrupt for the bootstrap core in the secondary instance, determining whether the secondary instance is in a fault state, wherein, if the secondary instance is in the fault state, halting the plurality of cores associated with the secondary instance, without impact to the primary instance, and recovering the bootstrap core by switching a context of the bootstrap core from the secondary instance to the primary instance via the non-maskable interrupt.