A CPU error injection method, device, equipment and readable storage medium

Abstract

The present specification provides a CPU error injection method, device, equipment and readable storage medium, the method comprises: enabling the UEFI Shell under the BIOS, obtaining error injection configuration information, the error injection configuration information includes the number of cores of CPU error injection and / or error type and / or error injection times; calling the error injection tool under the specified directory in the UEFI Shell, the error injection tool is pre-stored in the specified directory; according to the error injection configuration information, the target CPU core of CPU is injected with error using the error injection tool, and the error injection log is generated according to the error injection result. Through the technical scheme of the present specification, the error injection tool is directly called and the parameters are configured to inject errors into the CPU core under the UEFI Shell environment, so that flexible CPU fault simulation is realized at low software cost, and the blank of single-path server unable to perform CPU CE injection test is filled.

Description

Technical Field

[0001] This specification relates to the field of communication technology, and in particular to a CPU error injection method, apparatus, device, and readable storage medium. Background Technology

[0002] In the field of server system design and manufacturing, the system's reliability, availability, and maintainability, commonly referred to as RAS (Reliability, Availability, and Service) characteristics, are core key indicators for measuring product quality and market competitiveness. To ensure servers can operate stably for extended periods under various harsh environments and possess sufficient fault tolerance and recovery capabilities in the event of hardware failures, manufacturers must conduct thorough and rigorous verification of their RAS functionality during product development and testing. A crucial aspect of this verification is fault injection testing, which simulates various errors that may occur in hardware components during operation to verify the effectiveness of the system's error detection, recording, reporting, and even correction or isolation mechanisms. In fault injection testing of the Central Processing Unit (CPU), the industry generally needs to simulate two basic error types: Corrected Error (CE) and Uncorrected Error (UCE). Corrected errors are usually automatically repaired by hardware error correction codes and do not affect the continued operation of the system, but their frequency of occurrence is an important parameter for measuring hardware reliability; while uncorrected errors may lead to system crashes or data corruption, making the testing system's handling and response processes crucial. Currently, the industry's conventional method for simulating such error injection in CPUs relies on dedicated toolkits provided by chip suppliers. Taking the Intel platform as an example, a typical approach involves combining the hardware tool XDP with the accompanying Cscripts scripting software to inject errors via the UltraPath Interconnect (UPI) between CPUs. Specifically, in multi-processor (e.g., dual-processor) server systems, multiple CPUs are interconnected through UPI links. The error injection tool can simulate CE or UCE faults affecting the CPU by injecting errors such as Cyclic Redundancy Check (CRC) errors into these UPI links, and then observe whether the system can correctly capture and report these error messages in the firmware or operating system.

[0003] Traditional error injection schemes based on UPI links have significant limitations, especially when testing single-socket servers (servers equipped with only a single CPU). This is because UPI is an interface used for interconnecting multiple processors; in a single-socket server configuration, there is no physical CPU interconnection channel, rendering error injection methods based on UPI impossible. This technological gap means that single-socket server products lack effective means to simulate and verify correctable errors in the CPU itself during the R&D testing phase, potentially forcing the skipping of related RAS (Recovery and Accounting) tests. This undoubtedly introduces potential quality risks before product launch; defects related to the CPU's CE (Error Correction) mechanism triggered under specific loads or states may be overlooked, potentially leading to network problems during actual deployment and operation, impacting product reputation and customer business continuity. Furthermore, existing commercial error injection solutions, such as the aforementioned XDP hardware tools, are typically expensive to procure, and their accompanying software environment setup and configuration are complex and time-consuming, increasing the overall cost and timeframe of testing. Therefore, there is an urgent need in this field for a more flexible and lower-cost CPU simulation error injection scheme that can break free from dependence on specific hardware topologies and expensive dedicated tools, especially to solve the testing challenge of correctable error injection in single-socket server CPUs, so as to improve the RAS testing system of server products and enhance the overall reliability of the products. Summary of the Invention

[0004] In view of this, this specification provides a CPU error injection method, apparatus, device, and readable storage medium to improve the problem of poor error injection effect in RAS test mentioned above.

[0005] The specific technical solution is as follows: This specification provides a CPU error injection method applied to a server. The method includes: enabling UEFI Shell under BIOS, obtaining error injection configuration information, the error injection configuration information including the number of CPU cores to be injected and / or error type and / or number of error injections; calling an error injection tool in a specified directory in UEFI Shell, the error injection tool being pre-stored in the specified directory; using the error injection tool to inject errors into the target CPU cores according to the error injection configuration information, and generating an error injection log based on the error injection results.

[0006] As a technical solution, the error injection tool is pre-stored in a removable storage medium, which is pre-connected to the server according to the error injection test requirements.

[0007] As a technical solution, the step of injecting errors into the target CPU core of the CPU using an error injection tool based on the error injection configuration information includes: in response to the confirmation result of the error injection configuration information verification being correct, obtaining the APICID based on the number of cores, setting the error code based on the error type, injecting the error into the MCA control register associated with the target CPU core, and triggering the error.

[0008] As a technical solution, the step of using an injection tool to inject errors into the target CPU core of the CPU according to the injection configuration information, and generating an injection log according to the injection results, includes: reviewing the injection results, and prompting for review of the injection configuration information based on the review results of failed injections.

[0009] This specification also provides a CPU error injection device for use in servers. The device includes: a first module for enabling UEFI Shell under BIOS and obtaining error injection configuration information, the error injection configuration information including the number of CPU cores to be injected and / or error type and / or number of error injections; a second module for calling an error injection tool in a specified directory in UEFI Shell, the error injection tool being pre-stored in the specified directory; and a third module for using the error injection tool to inject errors into the target CPU cores of the CPU according to the error injection configuration information, and generating an error injection log based on the error injection results.

[0010] As a technical solution, the error injection tool is pre-stored in a removable storage medium, which is pre-connected to the server according to the error injection test requirements.

[0011] As a technical solution, the step of injecting errors into the target CPU core of the CPU using an error injection tool based on the error injection configuration information includes: in response to the confirmation result of the error injection configuration information verification being correct, obtaining the APICID based on the number of cores, setting the error code based on the error type, injecting the error into the MCA control register associated with the target CPU core, and triggering the error.

[0012] As a technical solution, the step of using an injection tool to inject errors into the target CPU core of the CPU according to the injection configuration information, and generating an injection log according to the injection results, includes: reviewing the injection results, and prompting for review of the injection configuration information based on the review results of failed injections.

[0013] This specification also provides an electronic device, including a processor and a readable storage medium storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the aforementioned CPU error injection method.

[0014] This specification also provides a readable storage medium storing machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the aforementioned CPU error injection method.

[0015] The technical solutions provided in this specification offer at least the following beneficial effects: By directly invoking the error injection tool and configuring parameters within the UEFI Shell environment to inject errors into the CPU core, the reliance on dedicated hardware debugging tools (such as XDP) and specific CPU interconnect topologies (such as UPI) is eliminated. Its technical advantage lies in achieving flexible CPU fault simulation at a lower software cost, particularly filling the gap in single-socket servers where CPU correctable error (CE) injection testing is impossible. It also simplifies test environment setup and improves the coverage and efficiency of RAS testing. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the drawings used in the description of the embodiments of this specification or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings of the embodiments of this specification.

[0017] Figure 1 This is a flowchart of a CPU error injection method in one embodiment of this specification; Figure 2 This is a structural diagram of a CPU error injection device according to one embodiment of this specification; Figure 3 This is a hardware structure diagram of an electronic device according to one embodiment of this specification.

[0018] Reference numerals: Module 1 21, Module 22, Module 3 23. Detailed Implementation

[0019] The terminology used in the embodiments described herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this specification. The singular forms “a,” “described,” and “the” as used in this specification and claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to any and all possible combinations comprising one or more of the associated listed items.

[0020] It should be understood that although the terms first, second, third, etc., may be used to describe various information in embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" may also be interpreted as "when," "when," or "in response to a determination."

[0021] In view of this, this specification provides a CPU error injection method, apparatus, device, and readable storage medium to at least improve one of the above-mentioned technical problems.

[0022] The specific technical solution is described below.

[0023] In one embodiment, this specification provides a CPU error injection method applied to a server. The method includes: enabling UEFI Shell under BIOS, obtaining error injection configuration information, the error injection configuration information including the number of CPU cores to be injected and / or error type and / or number of error injections; calling an error injection tool in a specified directory in UEFI Shell, the error injection tool being pre-stored in the specified directory; using the error injection tool to inject errors into the target CPU cores of the CPU according to the error injection configuration information, and generating an error injection log based on the error injection results.

[0024] Specifically, such as Figure 1 This includes the following steps, the order of which can be changed depending on the needs of the actual application scenario: Step S11: Enable UEFI Shell under BIOS and obtain error configuration information, including the number of CPU cores with errors and / or error type and / or number of errors.

[0025] By utilizing the UEFI (Unified Extensible Firmware Interface) Shell environment, simulated fault injection into the server's central processing unit (CPU) can be performed. Unlike traditional solutions that rely on the operating system (OS) or specific hardware debugging tools (such as Intel XDP), this method operates during the system startup process and before the operating system loads, thereby gaining the most direct and highest-level access to the hardware.

[0026] Ensure that the target server's BIOS (Basic Input / Output System) or UEFI firmware supports and is configured with the UEFI Shell boot option. Access the server's firmware settings interface (usually accessed during startup by pressing a specific key, such as Delete, F2, or F10). In the Boot or Advanced configuration menu, locate options such as "UEFI Shell," "Launch UEFI Shell," or similar options, and enable them or add them to the boot device list. This allows the server to enter a command-line UEFI Shell environment after the Power-On Self-Test (POST) without directly loading the regular operating system. This environment provides basic access and manipulation capabilities to system hardware resources (such as memory, I / O space, PCI devices, and various UEFI protocols), laying the necessary runtime foundation for subsequent debugging tools.

[0027] Step S12: Invoke the error-completion tool in the specified directory of the UEFI Shell. The error-completion tool is pre-stored in the specified directory.

[0028] The error injection tool itself is a specialized UEFI application, such as CoreErr.efi, where EFI is the standard executable file extension for Extensible Firmware Interface applications. This tool needs to be pre-written and compiled by developers, encapsulating all the logic required for error injection interaction with a specific CPU platform (such as the Intel Xeon Scalable processor family). The tool's development is linked to the CPU manufacturer's publicly available architecture manuals, such as Intel's Software Developer's Manual (SDM), which details the addresses, bit field meanings, and access methods of Model Specific Registers (MSRs) used for error reporting and injection. The core function of the tool is to read and write these specific MSRs with the highest privileges (Ring 0 level) through services provided by the UEFI Shell or directly embedded assembly instructions, thereby triggering the CPU's internal error logging and processing logic to simulate real hardware errors. The completed CoreErr.efi file needs to be placed on a removable storage medium, such as a USB flash drive (U-disk). The file system format of this USB flash drive must be supported by the UEFI environment, commonly FAT32. Implementers can simply copy the CoreErr.efi file to the root directory of a USB drive or any folder that is easy to remember, without having to install any additional drivers or software on the target server, which greatly simplifies the deployment process.

[0029] Step S13: Based on the error injection configuration information, use the error injection tool to inject errors into the target CPU core of the CPU, and generate an error injection log based on the error injection results.

[0030] Once the environment and tools are ready, you can begin the specific error-checking operation. First, start the target server and ensure the system enters the UEFI Shell from the configured path. After successful entry, the UEFI Shell command-line prompt will appear on the screen, such as "Shell>". At this point, the Shell has complete control of the hardware, but no operating system has been loaded. The operator first needs to locate the USB drive containing the CoreErr.efi tool. In the UEFI Shell, all storage devices (including hard drives, USB drives, optical discs, etc.) are mapped as "file system handles," typically presented as fs0:, fs1:, blk0:, etc. The operator can use the map command to list all currently available file system mappings. For example, after entering the map command, you might see output like "fs0:Alias(s):HD0a1:;BLK1:" and "fs1:Alias(s):USB0:;BLK3:". Typically, fs0 represents the first hard drive partition, while fs1 or higher numbers may represent the inserted USB drive. Operators need to identify the USB drive's handle based on the device description (e.g., containing the word "USB") or by attempting to switch directories and list files. Assuming the USB drive corresponds to fs1:, the operator must enter the command `fs1:` and press Enter to switch the current working directory to the USB drive's file system. After a successful switch, the prompt will change to `fs1:\>`. Subsequently, the operator can use the `ls` or `dir` commands to list the files in the current directory and confirm the existence of the CoreErr.efi tool.

[0031] Once the tool is located, the most crucial step is constructing and executing the injection command. This involves acquiring and transmitting "injection configuration information," which the injection tool receives via command-line arguments. The tool supports three core parameters: -c specifies the target CPU core number, -t specifies the type of error to inject, and -r specifies the number of consecutive injections. These parameters together constitute the complete definition of a single injection task. Now, let's illustrate the entire process with a concrete example. Suppose a tester needs to test a single-processor server with 8 physical CPU cores (considering hyper-threading, there might be 16 logical processors, but here, injection is typically targeted at physical cores). The tester plans to inject a correctable error (CE) into CPU core number 1 (note that numbering usually starts from 0, so -c 1 might refer to the second physical core), and to test the system's error accumulation and logging capabilities, wants to inject the same error three times consecutively.

[0032] According to this plan, testers need to switch to the directory where the tool is located in the UEFI Shell command line and enter the complete command: CoreErr.efi -c 1 -t ce -r 3. After pressing Enter, the command will begin execution. The tool CoreErr.efi will first parse the passed parameters: -c 1 tells the tool that the target of this operation is logical core 1 (the tool may need to handle the mapping between physical cores and logical cores internally); -t ce specifies that the error type is "correctable error"; -r 3 requires the tool to perform the error injection operation three times consecutively. After the parameters are parsed correctly, the tool will begin to execute the core's error injection logic. First, based on the current running environment and the -c parameter, the target CPU core is determined. In the UEFI environment, multi-processor (multi-core) information can be obtained and processed through protocols such as EFI_MP_SERVICES_PROTOCOL, thereby binding the execution context to the specified core. Next, according to the -t ce parameter, the tool will select the register configuration corresponding to "correctable error" from the internally predefined error mode library. For Intel CPUs, injecting correctable errors typically involves programming the Machine Check Error Report (MSR). For example, a tool might write a pre-calculated value to a specific MSR of the target core (such as IA32_MCI_CTL or a specific error-specific control register), where certain bits are set to simulate a specific correctable error condition, such as a correction error in the last level cache (LLC). This write operation itself appears to the CPU hardware as equivalent to detecting a real such error event. The CPU's integrated error detection circuitry "captures" this injected error and processes it according to the process defined by its internal microcode: First, the error information (such as error address, type, severity, etc.) is recorded in another set of machine check registers (such as IA32_MCI_STATUS); second, since this is a "correctable" error (CE), the CPU's internal error correction logic (such as ECC) is simulated as if the error has been corrected, and a bit is set in the corresponding status register to indicate that a corrected error event has occurred; finally, depending on the CPU and platform firmware (BIOS / UEFI) configuration, this error event may notify the firmware through a system interrupt (such as Corrected Machine Check Interrupt, CMCI), or it may simply be recorded in a register, waiting for the firmware or operating system to periodically poll and read it.

[0033] After completing an injection operation, the tool checks the -r 3 parameter. Since it requires three consecutive injections, the tool will repeat the above programming operation on the target MSR after a short delay (possibly achieved by looping and idling), and execute it twice more.

[0034] Each operation independently triggers the CPU error logging process. After all three error injection attempts are completed, the tool collects the execution results and attempts to read the MSRs (Maximum Recorders) that record error states to verify whether the errors were successfully logged. For example, it checks whether the bit indicating "error condition valid" in the IA32_MCI_STATUS register is set, or whether the value of the error count register has increased. Based on the read register states, the tool determines whether the error injection task was successful or failed. This result, along with the tool name, input parameters, execution date and timestamp, target CPU core ID, error type, requested and actual injection counts, and the values ​​(or summaries) of critical status registers, is formatted into a set of text lines as the error injection log. The tool prints this log information to the screen using the standard output service provided by the UEFI Shell. For example, the screen might display: "[INFO] CoreErr.efi executed. Parameters: Core=1, Type=CE, Repeat=3. [SUCCESS]3 CE errors injected successfully to Core 1. MCStatus: 0x9C00008000010090."

[0035] Meanwhile, to persistently save the records, the implementation uses UEFI file write operations to append these logs to a text file (such as error_injection_log.txt) on a USB drive or a local FAT partition on the server, facilitating subsequent offline analysis.

[0036] In practical implementation, how should the tool respond when invalid command-line arguments are entered? If the user enters `CoreErr.efi -c 256 -t ce -r 1`, and the current CPU only has 16 logical cores, the tool's internal parameter validation logic should detect that the core number "256" is outside the valid range (e.g., 0-15). In this case, the tool should not attempt to inject an error, but should immediately return a clear error message to the user, such as: "[ERROR] Invalid core number: 256. Valid range is 0-15." and exit execution. Similarly, if the error type parameter is `-t abc` (not `ce` or `uce`), or the injection count `-r` is negative, the tool should perform validation and provide an appropriate error message. Another common exception is the tool's failure to access CPU registers. This may be because the currently running core does not support certain MSRs, or the platform firmware locks access to these registers. In this case, the tool may raise a general protection exception (#GP) when attempting to execute RDMSR (Read Model-Specific Register) or WRMSR (Write Model-Specific Register) instructions. A robust tool should circumvent or catch such exceptions through UEFI's exception handling mechanism or pre-defined CPUID instruction checks, and report errors in a user-friendly manner, such as "[ERROR] Failed to access MSR 0x17C on core 1. The register might be not supported or locked." Furthermore, in scenarios involving continuous injection (with the -r parameter greater than 1), if an error is found after an injection that was not correctly recorded by the CPU (e.g., a status bit not set), the tool can choose to record a warning message and decide whether to continue attempting subsequent injections or abort the entire task.

[0037] In a UEFI Shell environment, use commands provided by the system firmware or another tool to read the CPU's machine check register set and directly check for new error records. A more common verification method is to continue booting the operating system. Enter the `exit` command in the UEFI Shell to exit the shell, allowing the system to continue the normal boot process and load the pre-installed operating system (such as Linux or Windows). Once in the operating system, testers can use the tools provided by the operating system to check the hardware error log. In Linux systems, the `demesg` command can be used to view messages in the kernel ring buffer; CPU error events are usually logged as "Machine check events logged" or "CPU: Hypervisor corrected error," etc. The dedicated tool `mcelog` can be used to decode and record machine check anomalies; it provides detailed information such as the CPU, core, error type, and address where the error occurred, and compares it with the injected error type. In Windows systems, the Event Viewer can be used to check the system log under Windows Logs, looking for events originating from "MachineCheck" or "WHEA-Logger." By comparing the logs generated by the error injection tool with the hardware error logs collected by the operating system, testers can fully verify whether the CPU error injection successfully triggered the complete RAS error handling pipeline from hardware to firmware to operating system.

[0038] In one embodiment, the error-injection tool is pre-stored in a removable storage medium, which is pre-connected to the server according to error-injection testing requirements.

[0039] In one implementation, the step of injecting errors into the target CPU core of the CPU using an error injection tool based on the error injection configuration information includes: in response to the confirmation result that the error injection configuration information is correct, obtaining the APICID based on the number of cores, setting the error code based on the error type, injecting the error into the MCA control register associated with the target CPU core, and triggering the error.

[0040] In one implementation, the step of using an injection tool to inject errors into the target CPU core of the CPU according to the injection configuration information, and generating an injection log according to the injection result, includes: reviewing the injection result, and prompting for review of the injection configuration information based on the review result of the failed injection.

[0041] In one implementation, such as Figure 2This specification also provides a CPU error injection device for use in servers. The device includes: a first module for enabling UEFI Shell under BIOS and obtaining error injection configuration information, the error injection configuration information including the number of CPU cores to be injected and / or error type and / or number of error injections; a second module for calling an error injection tool in a specified directory in UEFI Shell, the error injection tool being pre-stored in the specified directory; and a third module for using the error injection tool to inject errors into the target CPU cores of the CPU according to the error injection configuration information, and generating an error injection log based on the error injection results.

[0042] In one embodiment, the error-injection tool is pre-stored in a removable storage medium, which is pre-connected to the server according to error-injection testing requirements.

[0043] In one implementation, the step of injecting errors into the target CPU core of the CPU using an error injection tool based on the error injection configuration information includes: in response to the confirmation result that the error injection configuration information is correct, obtaining the APICID based on the number of cores, setting the error code based on the error type, injecting the error into the MCA control register associated with the target CPU core, and triggering the error.

[0044] In one implementation, the step of using an injection tool to inject errors into the target CPU core of the CPU according to the injection configuration information, and generating an injection log according to the injection result, includes: reviewing the injection result, and prompting for review of the injection configuration information based on the review result of the failed injection.

[0045] The implementation methods of the apparatus are the same as or similar to the corresponding implementation methods, and will not be described again here.

[0046] In one embodiment, this specification provides an electronic device including a processor and a readable storage medium storing machine-executable instructions executable by the processor. The processor executes the machine-executable instructions to implement the aforementioned CPU error injection method. From a hardware perspective, a hardware architecture diagram can be found... Figure 3 As shown.

[0047] In one embodiment, this specification provides a readable storage medium storing machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the aforementioned CPU error injection method.

[0048] Here, a readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, a readable storage medium can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0049] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0050] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0051] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification can take the form of a completely hardware implementation, a completely software implementation, or an implementation combining software and hardware aspects. Furthermore, embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0052] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments thereof. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0053] Furthermore, these computer program instructions can also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in the process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0054] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0055] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification can take the form of a completely hardware implementation, a completely software implementation, or an implementation combining software and hardware aspects. Furthermore, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0056] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A CPU error injection method, characterized in that, Applied to a server, the method includes: Enable UEFI Shell under BIOS to obtain error configuration information, including the number of CPU cores with errors and / or error type and / or number of errors. Invoke the error-completion tool located in the specified directory in the UEFI Shell. The error-completion tool is pre-stored in the specified directory. Based on the error injection configuration information, the error injection tool is used to inject errors into the target CPU core of the CPU, and an error injection log is generated based on the error injection results.

2. The method according to claim 1, characterized in that, The error-injection tool is pre-stored in a removable storage medium, which is pre-connected to the server according to error-injection testing requirements.

3. The method according to claim 1, characterized in that, The step of using an injection tool to inject errors into the target CPU core of the CPU according to the injection configuration information includes: In response to the confirmation result that the error configuration information is correct, the APICID is obtained according to the number of cores, the error code is set according to the error type, the error is injected into the MCA control register associated with the target CPU core and the error is triggered.

4. The method according to claim 1, characterized in that, The step of using an injection tool to inject errors into the target CPU core of the CPU according to the injection configuration information, and generating an injection log based on the injection results, includes: The system will review the injection error results and prompt you to review the injection error configuration information based on the review results of the failed injection errors.

5. A CPU error injection device, characterized in that, Applied to a server, the device includes: The first module is used to enable UEFI Shell under BIOS and obtain error configuration information, including the number of CPU cores with error injection and / or error type and / or number of error injections. The second module is used to call the error-injection tool in a specified directory in the UEFI Shell. The error-injection tool is pre-stored in the specified directory. The third module is used to inject errors into the target CPU core of the CPU using the injection tool according to the injection configuration information, and to generate an injection log based on the injection results.

6. The apparatus according to claim 5, characterized in that, The error-injection tool is pre-stored in a removable storage medium, which is pre-connected to the server according to error-injection testing requirements.

7. The apparatus according to claim 5, characterized in that, The step of using an injection tool to inject errors into the target CPU core of the CPU according to the injection configuration information includes: In response to the confirmation result that the error configuration information is correct, the APICID is obtained according to the number of cores, the error code is set according to the error type, the error is injected into the MCA control register associated with the target CPU core and the error is triggered.

8. The apparatus according to claim 5, characterized in that, The step of using an injection tool to inject errors into the target CPU core of the CPU according to the injection configuration information, and generating an injection log based on the injection results, includes: The system will review the injection error results and prompt you to review the injection error configuration information based on the review results of the failed injection errors.

9. An electronic device, characterized in that, include: A processor and a readable storage medium storing machine-executable instructions that can be executed by the processor to implement the method of any one of claims 1-4.

10. A readable storage medium, characterized in that, The readable storage medium stores machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the method described in any one of claims 1-4.

Images