Fault injection methods and apparatuses, and related products

Abstract

The present disclosure provides a fault injection method and apparatus, and related products. The method includes: obtaining a generic fault source structure from a physical hardware platform according to a platform device structure; and generating one or more first pointers in the generic fault source structure, where the one or more first pointers point to one or more generic error status block structures, and the one or more generic error status block structures include injected error data.

Description

FAULT INJECTION METHODS AND APPARATUSES, AND RELATED PRODUCTS TECHNICAL FIELD

[0001] This disclosure relates generally to the field of fault injection, and in particular to fault injection methods, fault injection apparatuses, electronic devices, and related products.BACKGROUND

[0002] When a computing device is running, it may encounter faults that affect its normal operation. To solve this problem, fault injection is a technique used to deliberately inject faults into a computing device. By observing how the computing device reacts to these injected faults, engineers and developers may correspondingly fix or enhance the computing device's ability to handle faults. Therefore, the normal operation of the computing device is ensured.

[0003] Fault injection at a hardware level may refer to inject faults into components of the computing device. The components may be, such as processor(s), memory, or the like in the computing device. Because the components may come from different physical hardware platforms, different fault injection manners are needed for different physical hardware platforms.SUMMARY

[0004] The present disclosure provides fault injection methods, fault injection apparatuses, electronic devices, and related products, to provide a platform-independent fault injection solution.

[0005] According to a first aspect, a fault injection method is described. The method may be performed by an electronic device (e.g. a computer), or the method may be performed by a module, a circuit, a unit, or a chip in the electronic device where the module, the circuit, the unit, or the chip is responsible for the fault injection method. The method includes: obtaining a generic fault source structure from a physical hardware platform according to a platform device structure; and generating one or more first pointers in the generic fault source structure, where the one or more first pointers point to one or more generic error status block structures, and the one or more generic error status block structures include injected error data.

[0006] According to this method, the generic fault source structure is obtained from the physical hardware platform according to the platform driver structure. In addition, the one or more first pointers are generated in the generic fault source structure, where the one or more pointers point to the one or more generic error status block structures, and the one or more generic error status block structures include error data. Therefore, the fault that is indicated by the error data is injected into the physical hardware platform. By doing so, obtaining the generic fault source structure may not rely on the limited authority provided by the physical hardware platform. In this method,obtaining the generic fault source structure may rely on the platform device structure. In addition, the injection of error data may also be performed without relying on the limited authority provided by the physical hardware platform. In this method, the error data may be injected in the one or more generic error status block structures pointed by the one or more first pointers generated in the generic fault source structure. Therefore, the fault injection method provided in the present disclosure is platform-independent and able to work across different physical hardware platforms.

[0007] In some examples, the obtaining a generic fault source structure from a physical hardware platform according to a platform device structure includes: obtaining a pointer pointing to a platform driver structure; obtaining, based on the pointer pointing to the platform driver structure, a pointer pointing to the platform device structure, where the platform device structure includes a pointer pointing to the generic fault source structure; and obtaining the generic fault source structure based on the pointer pointing to the generic fault source structure.

[0008] In some examples, the pointer pointing to the generic fault source structure is included in a platform data filed of the platform device structure.

[0009] According to the foregoing examples, when obtaining the generic fault source structure, the pointer pointing to the platform driver structure is obtained; the pointer pointing to the platform device structure is obtained based on the pointer pointing to the platform driver structure where the platform device structure includes the pointer pointing to the generic fault source structure; and the generic fault source structure is obtained based on the pointer pointing to the generic fault source structure. The pointer to the generic fault source structure is included in the platform data filed of the platform device structure. It is understood that in some manners, the generic fault source structure may be accessed either by the firmware in the physical hardware platform or under a limited, platform-dependent authority of the physical hardware platform. In contrast, in the above examples, the generic fault source structure is obtained and may be accessible to users, and users may have the authority to read and update the generic fault source structure. Moreover, obtaining the generic fault source structure is platform-independent, so that it may be applied across different physical hardware platforms.

[0010] In some examples, the obtaining a pointer pointing to a platform driver structure includes: obtaining the pointer pointing to the platform driver structure according to a first name indicating the platform driver structure using a kallsyms_lookup_name function; the obtaining, based on the pointer pointing to the platform driver structure, a pointer pointing to the platform device structure, includes: obtaining a pointer pointing to a device structure according to the pointer pointing to the platform driver structure using a platform_find_device_by_driver function; and obtaining the pointer pointing to the platform device structure according to the pointer pointing to the device structure using a to_platform_device function.

[0011] According to the foregoing examples, the pointer pointing to the platform driver structure is obtained according to the first name indicating the ghes platform driver using the kallsyms_lookup_name function; and the pointer pointing to the device structure is obtained according to the pointer pointing to the platform driver structure using a platform_fmd_device_by_driver function and the pointer pointing to the platform device structure is obtained according to the pointer pointing to the device structure using a to_platform_device function. The kallsyms_lookup_name function, platform_find_device_by_driver function, and to_platform_device function are standard functions defined in the Linux™ kernel. By doing so, obtaining the platform driver structure and the platform device structure is independent of types of physical hardware platforms. In addition, the computing resource utilization may be optimized by looking up for and retrieving the required structures, rather than multiple or all structures within the Linux™ kernel.

[0012] In some examples, the method further includes: generating the one or more generic error status block structures.

[0013] In some examples, the method further includes: writing the error data into the one or more generic error status block structures.

[0014] In some examples, the writing the error data into the one or more generic error status block structures includes: generating, one or more common platform error record (CPER) structures, in the one or more generic error status block structures; and writing the error data into the one or more common platform error record structures.

[0015] According to the foregoing examples, the one or more generic error status block structures are generated. In addition, the error data may be written into the one or more generic error status block structures. When writing the error data into the one or more generic error status block structures, one or more CPER structures are generated in the one or more generic error status block structures; the error data are generated based on the generic fault source structure; and the error data are written into the one or more CPER structures. By doing so, faults (i.e. the error data) are injected and simulated as if they had actually occurred. This manner may allow the Linux™ kernel to read from the one or more generic error status block structures for error handling and diagnostics, ensuring that faults are processed as in real scenarios.

[0016] In some examples, the generating one or more first pointers in the generic fault source structure includes: assigning one or more first memory regions; adding, in the one or more first memory regions, one or more first structures for the generic fault source structure; and generating the one or more first pointers, where a first structure in the one or more first structures includes a first pointer in the one or more first pointers.

[0017] According to the foregoing examples, the one or more first memory regions are assigned;the one or more first structures are added in the one or more first memory regions for the generic fault source structure; and the one or more first pointers are generated. The first structure in the one or more first structures includes the first pointer in the one or more first pointers. By doing so, the one or more generic error status block structures including injected faults (i.e., the injected error data) are linked to the generic fault source structure by the one or more first pointers. The linking may allow the Linux™ kernel to locate and access the injected faults through the one or more first pointers within the generic fault source structure.

[0018] In some examples, the method further includes: generating one or more second pointers in the generic fault source structure, where a second pointer in the one or more second pointers points to a read_ack_reg structure, and the read_ack_reg structure is included in the generic fault source structure; writing, one or more indicating flags to one or more read_ack_reg structures, where an indicating flag in the one or more indicating flags indicates a true, enable, or get mode of a corresponding read_ack_reg structure.

[0019] According to the foregoing examples, the one or more second pointers are generated in the generic fault source structure where the second pointer in the one or more second pointers points to the read_ack_reg structure, and the read_ack_reg structure is included in the generic fault source structure. In addition, the one or more indicating flags each indicating a true, enable, or get mode are written into the one or more read_ack_reg structures. By doing so, the Linux™ kernel may be informed of the faults by indicating flags in the read_ack_reg structures. Moreover, the one or more read_ack_reg structures are linked to the one or more first structures through the one or more second pointers. These first structures, in turn, are linked to the one or more generic error status block structures including injected faults. Therefore, the Linux™ kernel may not only recognize that a fault has occurred but also locate and access the injected faults.

[0020] According to a second aspect, a fault injection apparatus is described. The apparatus may be configured in an electronic device (e.g. a computer), or the apparatus may be configured as a module, a circuit, a unit, or a chip in the electronic device where the module, the circuit, the unit, or the chip is responsible for the fault injection. The apparatus includes various units for performing the method according to the first aspect or any example in the first aspect. The apparatus includes an obtaining unit and a processing unit. The obtaining unit may be configured to obtain a generic fault source structure from a physical hardware platform according to a platform device structure. The processing unit may be configured to generate one or more first pointers in the generic fault source structure, where the one or more first pointers point to one or more generic error status block structures, and the one or more generic error status block structures include injected error data.

[0021] In some examples, the obtaining unit is further configured to obtain a pointer pointing to aplatform driver structure; obtain, based on the pointer pointing to the platform driver structure, a pointer pointing to the platform device structure, where the platform device structure includes a pointer pointing to the generic fault source structure; and obtain the generic fault source structure based on the pointer pointing to the generic fault source structure.

[0022] In some examples, the obtaining unit is further configured to obtain the pointer pointing to the platform driver structure according to a first name indicating the platform driver structure using a kallsyms lookup name function; obtain a pointer pointing to a device structure according to the pointer pointing to the platform driver structure using a platform_find_device_by_driver function; and obtain the pointer pointing to the platform device structure according to the pointer pointing to the device structure using a to_platform_device function.

[0023] In some examples, the pointer pointing to the generic fault source structure is included in a platform data field of the platform device structure.

[0024] In some examples, the processing unit is further configured to generate the one or more generic error status block structures.

[0025] In some examples, the processing unit is further configured to write the error data into the one or more generic error status block structures.

[0026] In some examples, the processing unit is further configured to generate one or more common platform error record structures, in the one or more generic error status block structures; and write the error data into the one or more common platform error record structures.

[0027] In some examples, the processing unit is further configured to assign one or more first memory regions; add, in the one or more first memory regions, one or more first structures for the generic fault source structure; and generate the one or more first pointers where a first structure in the one or more first structures includes a first pointer in the one or more first pointers.

[0028] In some examples, the processing unit is further configured to generate one or more second pointers in the generic fault source structure, where a second pointer in the one or more second pointers points to a read_ack_reg structure, and the read_ack_reg structure is included in the generic fault source structure; and write, one or more indicating flags to one or more read_ack_reg structures, where an indicating flag in the one or more indicating flags indicates a true, enable, or get mode of a corresponding read_ack_reg structure.

[0029] According to a third aspect, an electronic device is described. The electronic device includes processing circuitry for performing the method according to the first aspect or any example in the first aspect.

[0030] According to a fourth aspect, a chip is provided. The chip includes an input / output (I / O) interface and a processor, where the processor is configured to call and run a computer program stored in a memory, to enable an electronic device installing with the chip to execute the methodaccording to the first aspect or any example in the first aspect.

[0031] According to a fifth aspect, an electronic device is described. The electronic device includes one or more processors; and a memory coupled to the one or more processors and storing instructions for execution by the processors, where the instructions, when executed by the one or more processors, cause the electronic device to perform the method according to the first aspect or any example in the first aspect.

[0032] In some examples, the electronic device may further include an interface circuit, and the processor is configured to communicate with another apparatus / device or component through the interface circuit.

[0033] According to a sixth aspect, a computer-readable storage medium is described. The computer-readable storage medium stores computer-readable instructions, and when an electronic device reads and executes the computer-readable instructions, the electronic device is enabled to perform the method according to the first aspect or any example in the first aspect.

[0034] According to a seventh aspect, a computer program product is described. When an electronic device executes the computer program product, the electronic device is enabled to perform the method according to the first aspect or any example in the first aspect.

[0035] The present disclosure encompasses various embodiments, including not only method embodiments, but also other embodiments such as apparatus / device embodiments and embodiments related to non-transitory computer readable storage media. Embodiments may incorporate, individually, or in combinations, the features disclosed herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Numerous details are described herein to provide a thorough understanding of embodiments illustrated in accompanying drawings. However, some embodiments may be practiced without many of the specific details, and the scope of the claims is only limited by those features and aspects specifically recited in the claims. Furthermore, well-known processes, components, and materials have not necessarily been described in exhaustive detail to avoid obscuring pertinent aspects of the embodiments described herein.

[0037] FIG. 1 is a schematic diagram of a proportional distribution of a plurality of faults within a cluster system in accordance with some embodiments of the present disclosure;

[0038] FIG. 2 A is a schematic diagram of a process that real faults occur in a physical hardware platform of a computing device and these faults are processed, and a manner of simulating these faults using a virtual machine, in accordance with some embodiments of the present disclosure;

[0039] FIG. 2B is a schematic diagram of a process that faults are injected into a physical hardware platform in accordance with some embodiments of the present disclosure;

[0040] FIG. 3 is a schematic diagram of a system to which some embodiments of the present disclosure are applicable;

[0041] FIG. 4 is a flowchart of a fault injection method in accordance with some embodiments of the present disclosure;

[0042] FIG. 5 is a flowchart of another fault injection method in accordance with some embodiments of the present disclosure;

[0043] FIG. 6 is a flowchart of obtaining a generic fault source structure in accordance with some embodiments of the present disclosure;

[0044] FIG. 7 is a block diagram of a fault injection apparatus in accordance with some embodiments of the present disclosure; and

[0045] FIG. 8 is a block diagram of an electronic device in accordance with some embodiments of the present disclosure.DETAILED DESCRIPTION

[0046] In the following description, reference is made to the accompanying drawings, which form part of the present disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and include structural or logical changes not depicted in the accompanying drawings. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0047] Reliability, availability, and serviceability (RAS) are fundamental features of computing devices. One aspect of these features is an ability of computing devices to respond to and / or recover from faults so that the computing devices are able to maintain the performance under different conditions. The computing device may be implemented by any of a personal computer, a computer dedicated to operating and / or monitoring systems relating to a data center, an electronic device (such as, but not limited to, a mobile device, a tablet device, a server, a controller unit, a control device, a monitoring device etc.), and / or any combination thereof appropriate to the relevant task at hand. The computing device may include various components such as processor(s), memory, driver(s), network interface(s), storage device(s), or the like. It is understood that a fault may occur at any component of the computing device. For example, a fault may occur at a driver, where driver files may become corrupted due to unexpected power loss, virus infection, disk errors, etc.

[0048] FIG. 1 illustrates a proportional distribution of various faults within a cluster system. It is noted that the cluster system may be a server, a server cluster, a workstation, a workstation cluster,etc. These cluster systems may include various computing devices. As shown in FIG. 1 , faults in high bandwidth memory (HBM), faults in board power supply, faults in firmware, and faults in driver take a large proportion in faults in the cluster system.

[0049] When a fault occurs in a memory, for example, the fault occurs in the memory in the high-performance computer (HPC), it may cause severe consequences. In addition, HBM faults may be the top 1 of faults in the cluster system, for example, as shown in FIG. 1, HBM faults account for 35%, ranking first among all faults in the cluster system. The memory fault injection is a procedure that affects memory failure prediction accuracy, detection, and recovery measures. When a fault occurs in a board power supply, the computing device is unstable, which also is a factor that affects the performance of the computing device. The fault injection on the board power supply may also affect prediction, detection, and recovery of faults in the board power supply. Therefore, faults are injected into these components such as processor(s), memory, driver(s), network interface(s), and storage device(s), which is used to fix or enhance the computing device's performance.

[0050] Fault injection is a widely used technique to deliberately inject faults into computing devices. This technique allows engineers and developers to deliberately inject certain types of faults, rather than waiting for faults to occur within the computing devices. By observing how the computing devices react to these injected faults, engineers and developers may correspondingly fix or enhance the computing devices' ability to handle faults. Handling faults may refer to responding to and / or recovering from faults.

[0051] Fault injection may be categorized into software fault injection and hardware fault injection. Software fault injection refers to inject faults into software applications or programs. In contrast, hardware fault injection may inject faults into a physical hardware platform where the physical hardware platform may refer to a set of compatible components on which software applications or programs can be run. Due to the nature of the physical hardware platform, hardware fault injection may be more complex.

[0052] FIG. 2A illustrates a process that real faults occur in a physical hardware platform of a computing device and these faults are processed. As mentioned above, the computing device may include various components such as processor(s), memory, driver(s), network interface(s), storage device(s), or the like. These components are compatible and may form the physical hardware platform on which software applications or programs can run. For example, in FIG. 2 A, a host operation system (OS) may run on the physical hardware platform.

[0053] For the physical hardware platform, there are a firmware and fault-related tables 1.

[0054] The firmware may be software embedded in component(s) of the physical hardware platform such as a motherboard, storage device, or network interface. The firmware may act as an intermediary between the physical hardware platform and the host OS.

[0055] The fault-related tables 1 may include a plurality of structures or tables related to faults or errors, such as, but not limited to, hardware error source table (HEST) and error record serialization table (ERST), etc. Each of the plurality of structures or tables may represent an aspect of the fault information. It is noted that the terms “error” and “fault” are used interchangeably in this disclosure and have the same meaning. In addition, the fault-related tables may be referred to by different names, depending on the specifications followed by the physical hardware platform, which is not limited herein. For example, when the physical hardware platform follows the advanced platform error interface (APEI) standard, the fault-related tables may be referred to as APEI tables. When the physical hardware platform follows the system management basic input / output system (SMBIOS) standard, the fault-related tables may be referred to as SMBIOS tables.

[0056] The host OS may manage hardware resources in the physical hardware platform and provide services for executing software applications or programs. Furthermore, the user space programs & services 201 are software applications or programs that run on top of the host OS. These software applications or programs provide functionalities that users may directly interact with, such as web browsers, text editors, or system management tools. It is understood that the host OS may not be visible or directly controllable by users. In contrast, users may be able to view, and control the user space programs & services 201 by interaction.

[0057] In FIG. 2A, for example, for a Linux™ host OS, it may include a Linux™ kernel. The Linux™ kernel is a component of the Linux™ host OS, responsible for managing system resources and providing services to applications or programs. A Linux™ generic hardware error source (GHES) driver is included in the Linux™ kernel. The Linux™ kernel may include various drivers, and among these drivers, the Linux™ GHES driver may handle error reports from the physical hardware platform. The Linux™ GHES driver may be referred to as the GHES driver for brevity.

[0058] When a real fault occurs in the physical hardware platform, the firmware may perform steps 211 and 212. In step 211, the firmware may detect the real fault and update some tables or structures in the fault-related tables 1 based on the detected real fault, which is a default way of writing the fault. Users may not inject faults by this default way. After updating the fault-related tables 1, in step 212, the firmware may notify the GHES driver in the host OS about the detected fault. When the GHES driver receives a notification from the firmware, the GHES driver may perform step 213. In step 213, the GHES driver may read fault information from the fault-related tables 1. For example, the firmware sends an interrupt request (IRQ) to the GHES driver and the GHES driver may read fault information from the fault-related tables 1 according to the IRQ. After the fault information is read by the GHES driver, the Linux™ kernel may take actions to handle this real fault. In some cases, the Linux™ kernel may handle the fault within the kernel by executing predefined recovery procedures. In some other cases, the Linux™ kernel may performstep 214 and notify the fault to the user space programs & services 201.

[0059] It is understood that in situations where the real fault occurs in the physical hardware platform, steps 211, 212, 213, and 214 may be performed. It is noted that in a majority of situations, the fault-related tables 1 may only be updated by the firmware, and users may have no access to the fault-related tables 1 via the firmware. For the hardware fault injection, when real faults are introduced into the physical hardware platform, physical damages to the computing device may be caused to make the firmware in the physical hardware platform to write the faults in the fault-related tables 1, but this manner may cause irreversible damages. Therefore, simulating hardware faults become feasible.

[0060] Some hardware fault injection manners inject faults into a virtual hardware platform. In these manners, a virtual machine may be first created, which is a software-based simulation of the computing device. The virtual hardware platform may be created within the virtual machine to simulate the physical hardware platform of the computing device, and the fault may be injected into the virtual hardware platform. However, the virtual hardware platform may not accurately reflect conditions of the physical hardware platform, since the physical hardware platform is the actual hardware platform including tangible components such as processors, memory, and storage devices. Moreover, some physical hardware platforms may not be simulated or running on the virtual machine.

[0061] With reference to FIG. 2 A again, a manner of simulating these faults using a virtual machine is shown. The physical hardware platform may be virtualized as the virtual hardware platform. The virtual hardware platform is software that runs on top of the physical hardware platform and the host OS or the virtual hardware platform is software that runs on another computing device for simulating. The virtual hardware platform is not a physical entity. The virtual hardware platform may include fault-related tables 2 that include similar information as fault-related tables 1 and are not reiterated herein.

[0062] The guest OS is an OS that runs on the virtual hardware platform. It is understood that although the guest OS operates as if it has access to its own hardware, the guest OS utilizes resources of the physical hardware platform. Similar to the host OS, the guest OS may control and manage the virtual hardware platform's resources, providing a virtual environment for user space programs & services 202 to run.

[0063] The user space programs & services 202 may function similarly to the user space programs & services 201, except it runs on the guest OS and virtual hardware platform. Hence it is not reiterated herein for brevity.

[0064] The fault-related tables 2 first may be updated to inject a fault. In Step 221 , the guest kernel, which is a simulated Linux™ kernel, may be notified about this fault. The guest kernel may handle iothe fault within the guest kernel or perform step 222 by notifying the user space programs & services 202.

[0065] It is understood that the virtual hardware platform and the guest OS are abstractions and simulations of the physical hardware platform and host OS, respectively. Therefore, the virtual hardware platform and guest OS may not be the same as the physical hardware and host OS, and may not have the same characteristics, operations, resources, or operations as the physical hardware platform and host OS. In addition, manners that inject faults into virtual hardware platforms may not apply to physical hardware platforms.

[0066] Some other hardware fault injection manners inject faults into the physical hardware platform. These manners may be developed during a system-on-chip (SoC) architecture phase. That is, hardware developer team may provide in advance availability to inject faults through model specific registers, or RAS registers. However, these manners may have some drawbacks - depend of firmware version and may may rise system hang. Furthermore, it is understood that there may be many types of physical hardware platforms, and the computing device may include one or more physical hardware platforms. In these manners, the faults may be injected through platform-specific components such as platform-specific registers. Therefore, these manners may work on one type of physical hardware platform but not on other types of physical hardware platforms.

[0067] Therefore, embodiments of the present disclosure provide a hardware fault injection method that simulates faults by modifying tables and structures related to fault information in the physical hardware platforms, rather than causing real damage to the computing device or injecting faults into the virtual hardware platform or injecting faults during the SoC architecture phase.

[0068] There are some manners that may enable users to access the fault-related tables 1 to modify tables and structures related to fault information in the physical hardware platforms. However, in these manners, users may only access the fault-related tables 1 under a limited authority, for example, an application programming interface (API) provided by the physical hardware platform. Furthermore, the limited authority provided by the physical hardware platform may not apply to another physical hardware platform. Therefore, the limited authority in these manners is platformdependent but may not work across different platforms.

[0069] In view of this, embodiments of the present disclosure provide a fault injection method that injects fault into the physical hardware platform and may work across different platforms.

[0070] In this method, a manner of obtaining a generic fault source structure from a physical hardware platform is provided and one or more generic error status block structures are written into the generic fault source structure to inject one or more faults into the physical hardware platform. It is understood that a physical hardware platform may include one generic fault source iistructure, which is related to identifying and reporting faults within the computing device. The details of the generic fault source structure will be introduced in later embodiments.

[0071] As shown in FIG. 2B, the generic fault source structure is included in the fault-related tables 1. According to this method provided in embodiments of the present disclosure, as shown in step 231, this method may allow users to operate, from the user space programs & services 201, to access functions in the Linux™ kernel. In step 232, by using the Linux™ kernel, users may obtain and modify the generic fault source structure to inject faults into the physical hardware platform. By steps 231 and 232, generic fault source structures from different physical hardware platforms may be processed. By doing so, this method is platform-independent and may be able to inject faults into different physical hardware platforms.

[0072] To better understand some embodiments of the present disclosure, a system 300 applicable to some embodiments of the present disclosure is introduced in combination with FIG. 3. As shown in FIG. 3, the system 300 includes a processing unit 310, a bus 320, a memory unit 330, and an input / output (I / O) interface 340. The processing unit 310, the memory unit 330, and the I / O interface 340 may communicate with each other through the bus 320. It is understood that the function of the system 300 may be refer to the Linux™ OS and user space programs & services 201 as mentioned above.

[0073] In some embodiments, the system 300 may be configured on a computing device, such as, but not limited to, a computer, a laptop, or a server. In some other embodiments, the system 300 may be configured on a plurality of computing devices. For example, in a distributed computing environment, the processing unit 310 may be on a compute node, the memory unit 330 may be on a storage node, the I / O interface 340 may be on an I / O server. It is understood that the computing device mentioned in combination with FIG. 3 may refer to the computing device mentioned above to be injected with faults where the method provided in embodiments of the present disclosure, or may refer to another computing device that is not injected with faults and only used to implement the method provided in embodiments of the present disclosure.

[0074] The processing unit 310 may include one or more processors such as, but not limited to, a central processing unit (CPU), graphics processing unit (GPU), or other devices that are capable of executing instructions and performing computations.

[0075] The bus 320 may be, but not limited to, a peripheral component interconnect (PCI) bus, universal serial bus, institute of electrical and electronics engineers (IEEE) 1394 “Firewire” bus, small computer system interface (SCSI) bus, serial advanced technology attachment (Serial-ATA) bus, aeronautical radio incorporated (ARINC) bus, etc., to which various units are electronically coupled.

[0076] The memory unit 330 may be configured to store program instructions suitable for beingexecuted by the processing unit 310. Also, the memory unit 330 may be configured in a form of a computer-readable storage medium, such as a volatile memory, random access memory (RAM), and / or non-volatile memory, for example, flash memory.

[0077] The computer-readable storage medium, which may be part of the memory unit 330, may include a volatile or non-volatile type, removable or non-removable medium that may store information using any manner or strategy. Information may include computer-readable instructions, data structures, program modules, or other data.

[0078] The I / O interface 340 may be configured to communicate between the system 300 and external devices or networks. It may include components such as, but not limited to, network interfaces (e.g., Ethernet, InfiniBand), storage interfaces (e.g., non-volatile memory express (NVMe), serial attached small computer system interface (SCSI) (SAS), and peripheral interfaces).

[0079] The system 300 is described above, which may be configured to implement the fault injection method 400 as illustrated in FIG. 4. The fault injection method 400 is now described with reference to FIG. 4. As shown in FIG. 4, the fault injection method 400 includes step 410 and step 420.

[0080] In step 410, a generic fault source structure is obtained from a physical hardware platform according to a platform device structure.

[0081] The method 400 commences at step 410 with the processing unit 310 obtaining the generic fault source structure from the physical hardware platform according to the platform device structure.

[0082] In some embodiments, the generic fault source structure is included in the fault-related tables 1 in FIG. 2 A or FIG. 2B. The generic fault source structure may include information such as error severity, error type, and error timestamp in a standardized format.

[0083] In some embodiments, the fault-related tables 1 may be HEST tables, and advanced configuration and power interface (ACPI or acpi) may be provided for the HEST tables. The generic fault source structure may be referred to as acpi_hest_generic or acpi_hest_generic_v2. The generic fault source structure may be further referred to other or future version on the HEST tables. The acpi_hest_generic or acpi_hest_generic_v2 may include address of generic address structure (GAS) into physical memory.

[0084] In some embodiments, the platform device structure is indicated by a platform driver structure.

[0085] The platform driver structure is a structure in the Linux™ kernel and includes information describing drivers in the physical hardware platform. In some embodiments, the platform driver structure may be referred to as platform_driver structure.

[0086] The platform device structure is a structure in the Linux™ kernel and includes informationdescribing devices in the physical hardware platform such as processors and memory, etc. In some embodiment, the platform device structure may be referred to as platform_device structure.

[0087] In some embodiments, the platform driver structure or the pointer pointing to the platform driver structure may be obtained first; the platform device structure or the pointer pointing to the platform device structure may be obtained according to the platform driver structure or the pointer pointing to the platform driver structure; and the generic fault source structure may be obtained according to the platform device structure.

[0088] In step 420, one or more first pointers in the generic fault source structure are generated, where the one or more first pointers point to one or more generic error status block structures, and the one or more generic error status block structures include error data.

[0089] The method 400 proceeds to step 420 with the processing unit 310 generating the one or more first pointers in the generic fault source structure.

[0090] The generic error status block structures may include different types of error information such as memory error, CPU error, custom RAS Error, etc.

[0091] The above pointer such as the first pointer or the pointer pointing to the platform device structure or platform driver structure may be a variable that indicates a memory address or physical address of another variable or structure. For example, the processing unit 310 may obtain a pointer from a structure, and by executing some programs, the processor 310 may obtain another structure according to the memory address or physical address indicated by the pointer.

[0092] It is understood that the Linux™ kernel may not find the generic error status block structures directly. Instead, the Linux™ kernel may find the generic fault source structure first and obtain a pointer to the generic error status block structure and find the generic error status block structure according to the obtained pointer and read error data from the generic error status block structure. When the Linux™ kernel read error data from the generic error status block structure, the Linux™ kernel may handle the fault of the error data.

[0093] Therefore, referring back to step 420, the one or more generic error status block structures may be established and the error data may be injected into the one or more generic error status block structures. The one or more first pointers pointing to the one or more generic error status block structures are generated. Therefore, the Linux™ kernel may access the one or more generic error status block structures through the one or more first pointers to handle the corresponding faults.

[0094] It is noted that in step 420, the error data refers to the injected faults. The error data may be data copied from existing error data, or data generated based on the generic fault source structure. The source of the error data is not limited herein.

[0095] According to the foregoing embodiments, the generic fault source structure is obtainedfrom the physical hardware platform according to the platform driver structure. In addition, the one or more first pointers are generated in the generic fault source structure, where the one or more pointers point to the one or more generic error status block structures, and the one or more generic error status block structures include error data. Therefore, the fault that is indicated by the error data is injected into the physical hardware platform. By doing so, obtaining the generic fault source structure may not rely on the limited authority provided by the physical hardware platform. In this method, obtaining the generic fault source structure may rely on the platform device structure. In addition, the injection of error data may also be performed without relying on the limited authority provided by the physical hardware platform. In this method, the error data may be injected in the one or more generic error status block structures pointed by the one or more first pointers generated in the generic fault source structure. Therefore, the fault injection method provided in the present disclosure is platform-independent and able to work across different physical hardware platforms.

[0096] FIG. 5 is a flowchart of another fault injection method 500 in accordance with some embodiments of the present disclosure. As shown in FIG. 5, in some embodiments, step 410 may include steps 510, 520, and 530.

[0097] In step 510, a pointer pointing to a platform driver structure is obtained.

[0098] In some embodiments, the pointer pointing to the platform driver structure may refer to a generic hardware error source (ghes)_platform_driver pointer, and the ghes_platform_driver pointer is obtained according to a first name indicating the platform driver structure using a kallsyms_lookup_name function. In addition, the platform driver structure is obtained according to the ghes_platform_driver pointer.

[0099] For the Linux™ kernel, the platform driver structure may refer to a ghes driver structure “platform_driver” installed on the OS or a ghes platform driver; there is a ghes_platform_driver pointer that points to the platform driver structure, and this ghes_platform_driver pointer may refer to a ghes_platform_driver_ptr (that is, the ghes_platform_driver_ptr is the pointer of the basic ghes driver structure “platform_driver” installed on the OS). When the ghes_platform_driver pointer is obtained, the platform driver structure may be obtained according to the ghes_platform_driver pointer.

[0100] For the ghes_platform_driver pointer, it is not exported explicitly from the Linux1 Mkernel. Therefore, a function is used to export the ghes_platform_driver pointer, for example, a kallsyms_lookup_name function may be used. The first name indicating the platform driver structure may be inputted into the kallsyms_lookup_name function, and the kallsyms_lookup_name function may return the ghes_platform_driver pointer. The ghes driver structure “platform_driver” installed on the OS is obtained according to the ghes_platform_driver pointer.

[0101] After obtaining the pointer pointing to platform driver structure, in step 520, a pointer pointing to the platform device structure is obtained.

[0102] In some embodiments, the obtaining of the pointer to the platform device structure may include the following steps.

[0103] First, a pointer pointing to a device structure is first obtained by inputting the pointer pointing to the platform driver structure into a platform_find_device_by_driver function. Second, the pointer pointing to the platform device structure is obtained by inputting the pointer pointing to the device structure into a to_platform_device function.

[0104] After obtaining the pointer pointing to platform device structure, process 500 may proceed to step 530. In step 530, a generic fault source structure is obtained based on the pointer pointing to the generic fault source structure.

[0105] After obtaining the pointer pointing to platform device structure, the platform device structure is obtained according to the pointer pointing to the platform device structure.

[0106] In some embodiments, the obtaining of the generic fault source structure may start from obtaining a pointer that points to the generic fault source structure. In some embodiments, the pointer is included in the platform device structure.

[0107] In some examples, the pointer to the generic fault source structure is included in a platform data field of the platform device structure. After obtaining the pointer to the generic fault source structure, the generic fault source structure may be obtained.

[0108] In some embodiments, a function is used to obtain the physical address of the generic fault source structure, based on the pointer to the generic fault source structure. The physical address is on physical bus. Then, the data of the generic fault source structure may be copied from physical bus to virtual memory, so that it may be read. In some embodiments, the function of obtaining the physical address of the generic fault source structure may be referred to as apei_read().

[0109] According to the foregoing embodiments, when obtaining the generic fault source structure, the pointer pointing to the platform driver structure is obtained; the pointer pointing to the platform device structure is obtained based on the pointer pointing to the platform driver structure where the platform device structure includes the pointer pointing to the generic fault source structure; and the generic fault source structure is obtained based on the pointer pointing to the generic fault source structure. The pointer to the generic fault source structure is included in the platform data filed of the platform device structure. It is understood that in some manners, the generic fault source structure may be accessed either by the firmware in the physical hardware platform or under a limited, platform-dependent authority of the physical hardware platform. In contrast, in the above examples, the generic fault source structure is obtained and may be accessible to users, and users may have the authority to read and update the generic fault sourcestructure. Moreover, obtaining the generic fault source structure is platform-independent, so that it may be applied across different physical hardware platforms.

[0110] Referring back to FIG. 5, after the step 530, steps 540, 550 and 560 may be performed.

[0111] It is noted that the order of executing steps 540, 550 and 560 is not fixed and is not limited herein. For example, in some embodiments, step 550 may be performed first, followed by step 540 and step 560, or step 540 may be performed first, followed by step 550 and step 560, or step 560 may be performed first, followed by step 540 and step 550. The steps 540, 550 and 560 are now described respectively.

[0112] It is further noted that a step 541, steps 551 and 552 are performed after the step 540 and 550 respectively. The step 560 may be performed before or after step 561. Therefore, for example, step 550 may be performed first, followed by steps 551 and 552, then step 540 may be performed, followed by step 541, at last, step 561 may be performed, followed by step 560. Furthermore, steps 550, 551, and 552 may refer to step 420.

[0113] In step 540, one or more generic error status block structures are generated, where the one or more generic error status block structures may be used to store the error data.

[0114] It is noted that the generic error status block structures may be referred to by different names, such as acpi_hest_generic_status structures, which is not limited herein.

[0115] In some embodiments, after generating the one or more generic error status block structures, step 541 is performed. In step 541 , the error data are written into the one or more generic error status block structures.

[0116] As described before, the error data refer to the injected fault, and the error data may be copied from existing error data, or generated based on information such as error types and error severity defined in generic fault source structure. The source of the error data is not limited herein.

[0117] In some embodiments, the error data are written into one or more common platform error record (CPER) structures of the one or more generic error status block structures. In these embodiments, before writing the error data, the one or more common platform error record structures are first created.

[0118] The CPER structures provide a standardized format for recording hardware error information. The CPER may enable the OS and other system management tools to access the information of the error, such as the nature of the error, its location within the system, and when it occurred. The OS and other system management tools may obtain precise error information for diagnosis and corrective actions through CPER.

[0119] It is noted that one generic error status block structure may include one or more CPER structures. In some embodiments, for one generic error status block structure, the error data may be written in one CPER structure of the generic error status block structure. In some otherembodiments, the error data may be written in two or more CPER structures of the generic error status block structure, which is not limited herein.

[0120] In some embodiments, a ghes_copy_tofrom_phys function may be used for writing the error data into one or more generic error status block structures.

[0121] The ghes_copy_tofrom_phys function is part of the GHES driver in the Linux™ kernel. The ghes_copy_tofrom_phys function may be used to safely write the error data without interference with the injected error data or the data in the generic error status block structure. The ghes_copy_tofrom_phys function may lock interrupts to prevent interference, and use a system call to safely copy error data from virtual memory to specific physical memory locations accessible via the PCI system bus.

[0122] According to the foregoing embodiments, the one or more generic error status block structures are generated. In addition, the error data may be written into the one or more generic error status block structures. When writing the error data into the one or more generic error status block structures, one or more CPER structures are generated in the one or more generic error status block structures; the error data are generated based on the generic fault source structure; and the error data are written into the one or more CPER structures. By doing so, faults (i.e. the error data) are injected and simulated as if they had actually occurred. This manner may allow the Linux™ kernel to read from the one or more generic error status block structures for error handling and diagnostics, ensuring that faults are processed as in real scenarios.

[0123] Referring back to FIG. 5, in step 550, one or more one or more memory regions are assigned. It is understood that the one or more memory regions refer to the physical regions of memory, and the physical regions are accessible by hardware. In some embodiments, the allocating the one or more memory regions may be implemented by a function, such as, but not limited to, ghes_new function.

[0124] Then, in step 551, one or more first structures are added to the generic fault source structure, in the one or more first memory regions created in step 550.

[0125] In some embodiments, the first structure may be a GHES structure, which may be a template or basis structure that is generated based on the specifications in the generic fault source structure, and the GHES structure may have a predefined, fixed format.

[0126] It is noted that the first structure may be of other formats, which is not limited herein.

[0127] Then, in step 552, one or more first pointers may be generated, where a first structure in the one or more first structures includes a first pointer in the one or more first pointers.

[0128] In some embodiments, the one or more first pointers may point to the physical addresses of the one or more generic error status block structures.

[0129] An exemplary generic fault source structure 600 is shown in FIG. 6, where the generic faultsource structure 600 includes N GHES structures, and N is a positive integer.

[0130] It is noted that generic fault source structures may include other types of structures other than the GHES structure, which is not limited and omitted herein.

[0131] As shown in FIG. 6, a first structure may be added to the generic fault source structure, and the first structure includes a first pointer points to a generic error status block structure. It is noted that although FIG. 6 only illustrates one first structure. In some embodiments, a plurality of first structures may be added to the generic fault source structure. It is further noted that, each first structure may correspond to one or more generic error status block structure.

[0132] According to the foregoing embodiments, the one or more first memory regions are assigned; the one or more first structures are added in the one or more first memory regions for the generic fault source structure; and the one or more first pointers are generated. The first structure in the one or more first structures includes the first pointer in the one or more first pointers. By doing so, the one or more generic error status block structures including injected faults (i.e., the injected error data) are linked to the generic fault source structure by the one or more first pointers. The linking may allow the Linux™ kernel to locate and access the injected faults through the one or more first pointers within the generic fault source structure.

[0133] Referring back to FIG. 5, in step 560, one or more second pointers are generated in the generic fault source structure, where a second pointer points to a read_ack_reg structure.

[0134] The read_ack_reg structures may be used to inform the OS about the updated physical memory region of the one or more first structures. It is noted that the read_ack_reg structures may be referred to as other names, which is not limited herein.

[0135] In step 561, one or more indicating flags are written to one or more read_ack_reg structures.

[0136] It is noted that the order of performing step 560 and 561 is not fixed, which is not limited herein.

[0137] In some embodiments, a read_ack_reg structure may include an indicating flag. The indicating flag may be a number, an alphabet, or any other identifiers that differentiate modes, which is not limited herein. For example, the indicating flag may be a number including 0, 1, 2, or 3, and each number represents a mode.

[0138] In some embodiments, the indicating flag may indicate a true, enable, or get mode.

[0139] In some embodiments, an indicating flag may be set as true mode, which suggests that the read_ack_reg structure is activated. In some embodiments, an indicating flag may be set as enable mode, which suggests that the error source is enabled; in some embodiments, an indicating flag may be set as get mode, which suggests that the OS may check status about read error. In some examples, a field in the read_ack_reg structure is set as 0 for indicating the OS that the error is not read error.

[0140] In some embodiments, the writing of the indicating flags may be implemented by a function such as, but not limited to, apei_write function.

[0141] In some embodiments, after the faults are injected, the Linux™ kernel may extract memory error and execute error behavior. In some embodiments, a ghes_proc function may be used to process and handle errors reported by the generic fault source structure.

[0142] According to the foregoing embodiments, the one or more second pointers are generated in the generic fault source structure where the second pointer in the one or more second pointers points to the read_ack_reg structure, and the read_ack_reg structure is included in the generic fault source structure. In addition, the one or more indicating flags each indicating a true, enable, or get mode are written into the one or more read_ack_reg structures. By doing so, the Linux™ kernel may be informed of the faults by indicating flags in the read_ack_reg structures. Moreover, the one or more read_ack_reg structures are linked to the one or more first structures through the one or more second pointers. These first structures, in turn, are linked to the one or more generic error status block structures including injected faults. Therefore, the Linux™ kernel may not only recognize that a fault has occurred but also locate and access the injected faults.

[0143] The fault injection method according to the embodiments of the present disclosure is described above in combination with FIGS. 1 to 6. The fault injection apparatus of the embodiments of the present disclosure will be described below in combination with FIG. 7.

[0144] FIG. 7 is a block diagram of a fault injection apparatus in accordance with some embodiments of the present disclosure. The fault injection apparatus may be configured to perform the foregoing method embodiments, and therefore can also achieve beneficial effects of the foregoing method embodiments. In the embodiments of the present disclosure, the fault injection apparatus may be an electronic device or a module of the electronic device (for example, a chip or a circuit).

[0145] As shown in FIG. 7, the fault injection apparatus 700 includes an obtaining unit 710 and a processing unit 720. The fault injection apparatus 700 is used to implement the foregoing method embodiments as shown in FIG. 4.

[0146] The obtaining unit 710 may be configured to obtain a generic fault source structure from a physical hardware platform according to a platform device structure The processing unit 720 may be configured to generate one or more first pointers in the generic fault source structure, where the one or more first pointers point to one or more generic error status block structures, and the one or more generic error status block structures include injected error data.

[0147] In some embodiments, the obtaining unit 710 is configured to obtain a pointer pointing to a platform driver structure; obtain, based on the pointer pointing to the platform driver structure, a pointer pointing to the platform device structure, where the platform device structure includes apointer pointing to the generic fault source structure; and obtain the generic fault source structure based on the pointer pointing to the generic fault source structure.

[0148] In some embodiments, the obtaining unit 710 is configured to obtain the pointer pointing to the platform driver structure according to a first name indicating the platform driver structure using a kallsyms_lookup_name function; obtain a pointer pointing to a device structure according to the pointer pointing to the platform driver structure using a platform_fmd_device_by_driver function; and obtain the pointer pointing to the platform device structure according to the pointer pointing to the device structure using a to_platform_device function.

[0149] In some embodiments, the pointer pointing to the generic fault source structure is included in a platform data filed of the platform device structure.

[0150] In some embodiments, the processing unit 720 is further configured to generate the one or more generic error status block structures.

[0151] In some embodiments, the processing unit 720 is configured to write the error data into the one or more generic error status block structures.

[0152] In some embodiments, the processing unit 720 is configured to generate one or more common platform error record structures, in the one or more generic error status block structures; and write the error data into the one or more common platform error record structures.

[0153] In some embodiments, the processing unit 720 is configured to assign, one or more first memory regions; add, in the one or more first memory regions, one or more first structures to the generic fault source structure; and generate, the one or more first pointers, where a first structure in the one or more first structures includes a first pointer in the one or more first pointers.

[0154] In some embodiments, the processing unit 720 is further configured to generate one or more second pointers in the generic fault source structure, where a second pointer in the one or more second pointers points to a read_ack_reg structure, and the read_ack_reg structure is included in the generic fault source structure; and write, one or more indicating flags to one or more read_ack_reg structures, where an indicating flag in the one or more indicating flags indicates a true, enable or get mode of corresponding read_ack_reg structure.

[0155] A more detailed description of functions of the obtaining unit 710 and processing unit 720 can be referred to the relevant description in the foregoing method embodiments shown in FIG. 4, FIG. 5, and FIG. 6.

[0156] Furthermore, as shown in FIG. 8, an electronic device 800 for implanting the foregoing method embodiments may be provided according to embodiments of the present disclosure. The electronic device 800 includes a processor 810 and an interface circuit 820. The processor 810 and the interface circuit 820 are coupled to each other. It is understood that the interface circuit 820 can be a transceiver or an I / O interface. In some embodiments, the electronic device 800 mayPCI7RU2025 / 0000Wfurther include a memory 830, and the memory 830 is configured to store instructions that, when executed by the processor 810, cause the electronic device 800 to perform any of the methods described above. The memory 830 is further configured to store input data required by the processor 810 to when it runs the instructions or the data produced after the processor 810 has run the instructions.

[0157] In some other examples, the electronic device 800 includes a processor 810, and the interface circuit 820 may also be understood as part of the processor 810.

[0158] When the electronic device 800 is used to implement the method shown in FIG. 4 or FIG.5, it may be interpreted as an electronic device itself, a module in the electronic device, a circuit or chip, or a combination thereof. The processor 810 is used to implement the functions of the processing unit 720, and the interface circuit 820 is used to implement the functions of the obtaining unit 710. For example, the electronic device 800 may further include a memory 830, the processor 810 and the interface circuit 820 are connected to the memory 830 over a circuit or a wire, and the processor 810 is configured to read and execute instructions stored in the memory 830.

[0159] In the present disclosure, the terms “a” or “an” are defined to mean “at least one”, that is, these terms do not exclude a plural number of items, unless stated otherwise.

[0160] In the present disclosure, unless stated otherwise, the terms “connected” and “coupled”, and derivatives and variants thereof, refer herein to any structural or functional connection or coupling, either direct or indirect, between two or more elements. For example, connection or coupling between the elements can be acoustical, mechanical, optical, electrical, thermal, logical, or any combinations thereof.

[0161] In the present disclosure, the expression “based on” is intended to mean “based at least partly on”, that is, this expression can mean “based solely on” or “based partially on”, and so should not be interpreted in a limited manner. More particularly, the expression “based on” could also be understood as meaning “depending on”, “representative of’, “indicative of’, “associated with” or similar expressions.

[0162] In the present disclosure, the terms “system” and “network” may be used interchangeably in different embodiments of this disclosure. “At least one” means one or more, and “a plurality of’ means two or more. The term “and / or” describes an association relationship of associated objects, and indicates that three relationships may exist. For example, A and / or B may indicate the following three cases: Only A exists, both A and B exist, and only B exists, where A and B may be singular or plural. The character “ / ” indicates an “or” relationship between associated objects. “At least one of the following items (pieces)” or a similar expression thereof indicates any combination of these items, including a single item (piece) or any combination of a plurality ofitems (pieces). For example, “at least one of A, B, or C” includes: only A; only B; only C; A and B; A and C; B and C; or A, B, and C, and “at least one of A, B, and C” may also be understood as including: only A; only B; only C; A and B; A and C; B and C; or A, B, and C. In addition, unless otherwise specified, ordinal numbers such as “first” and “second” in embodiments of this disclosure are used to distinguish between a plurality of objects, and are not used to limit a sequence, a time sequence, priorities, or importance of the plurality of objects.

[0163] A person skilled in the art should understand that embodiments of this disclosure may be provided as a method, an apparatus (or system), a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium), or a computer program product. Therefore, this disclosure may use a form of a hardware-only embodiment, a software-only embodiment, or an embodiment with a combination of software and hardware. Moreover, this disclosure may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, an optical memory, and the like) that includes computer-usable program code.

[0164] This disclosure is described with reference to the flowcharts and / or block diagrams of the method, the device (system), and the computer program product according to this disclosure. It should be understood that computer program instructions may be used to implement each process and / or each block in the flowcharts and / or the block diagrams and a combination of a process and / or a block in the flowcharts and / or the block diagrams. The computer program instructions may be provided for a general-purpose computer, a dedicated computer, an embedded processor, or a processor of another programmable data processing device and enable a machine to execute the instructions. When executed by any computer or the processor of a programmable data processing device, the instructions cause the apparatus to implement specific functions as described in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams. The computer program instructions may alternatively be stored in a computer-readable memory that can indicate a computer or another programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate an artifact that includes an instruction apparatus. The instruction apparatus implements a specific function in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams.

[0165] The computer program instructions may alternatively be loaded onto a computer or another programmable data processing device, so that a series of operations and steps are performed on the computer or the another programmable device, so that computer-implemented processing is generated. Therefore, the instructions executed on the computer or on another programmable device provide steps for implementing specific functions as described in one or more proceduresin the flowcharts and / or one or more blocks in the block diagrams.

[0166] It is clear that a person skilled in the art can make various modifications and variations to this disclosure without departing from the scope of this disclosure. This disclosure is intended to cover these modifications and variations of this disclosure provided that they fall within the scope of protection defined by the following claims and their equivalent technologies.

Claims

CLAIMS1. A fault injection method, comprising:obtaining a generic fault source structure from a physical hardware platform according to a platform device structure; andgenerating one or more first pointers in the generic fault source structure, wherein the one or more first pointers point to one or more generic error status block structures, and the one or more generic error status block structures comprise injected error data.

2. The method of claim 1, wherein the obtaining a generic fault source structure from a physical hardware platform according to a platform device structure, comprises:obtaining a pointer pointing to a platform driver structure;obtaining, based on the pointer pointing to the platform driver structure, a pointer pointing to the platform device structure, wherein the platform device structure comprises ac the generic fault source structure; andobtaining the generic fault source structure based on the pointer pointing to the generic fault source structure.

3. The method of claim 2, wherein the obtaining a pointer pointing to a platform driver structure comprises:obtaining the pointer pointing to the platform driver structure according to a first name indicating the platform driver structure using a kallsyms_lookup_name function;the obtaining, based on the pointer pointing to the platform driver structure, a pointer pointing to the platform device structure, comprises:obtaining a pointer pointing to a device structure according to the pointer pointing to the platform driver structure using a platform_fmd_device_by_driver function; and obtaining the pointer pointing to the platform device structure according to the pointer pointing to the device structure using a to_platform_device function.

4. The methods of any one of claims 1 to 3, wherein the pointer pointing to the generic fault source structure is comprised in a platform data filed of the platform device structure.

5. The method of any one of claims 1 to 4, further comprising:generating the one or more generic error status block structures.PC17RU2025 / 0000106. The method of claim 5, further comprising:writing the error data into the one or more generic error status block structures.

7. The method of claim 6, wherein the writing the error data into the one or more generic error status block structures comprises:generating, one or more common platform error record structures, in the one or more generic error status block structures; andwriting the error data into the one or more common platform error record structures.

8. The method of any one of claims 1 to 7, wherein the generating one or more first pointers in the generic fault source structure comprises:assigning one or more first memory regions;adding, in the one or more first memory regions, one or more first structures into the generic fault source structure; andgenerating the one or more first pointers, wherein a first structure in the one or more first structures comprises a first pointer in the one or more first pointers.

9. The method of any one of claims 1 to 8, further comprising:generating one or more second pointers in the generic fault source structure, wherein a second pointer in the one or more second pointers points to a read_ack_reg structure, and the read_ack_reg structure is comprised in the generic fault source structure; andwriting, one or more indicating flags to one or more read_ack_reg structures, wherein an indicating flag in the one or more indicating flags indicates a true, enable, or get mode of a corresponding read_ack_reg structure.

10. A fault injection apparatus comprising units for performing the method according to any one of claims 1 to 9.

11. An electronic device comprising processing circuitry for performing the method according to any one of claims 1 to 9.

12. A chip, comprising an input / output (I / O) interface and a processor, wherein the processor is configured to call and run a computer program stored in a memory, to enable an electronic device installed with the chip to perform the method according to any one of claims 1 to 9.

13. An electronic device, comprising:one or more processors; anda memory storing instructions which, when executed by the one or more processors, cause the electronic device to perform the method of any one of claims 1 to 9.

14. A computer-readable storage medium having instructions stored thereon which, when executed by an electronic device, cause the electronic device to perform the method of any one of claims 1 to 9.

15. A computer program product storing instructions which, when executed, cause an electronic device to perform the method of any one of claims 1 to 9.

Images