Fault handling method, device, storage medium and program product

Abstract

An embodiment of the present application provides a fault handling method, device, storage medium, and program product. In the fault handling method, when a target fault event occurs in a processor core in a multi-core processor system, the operating system kernel can call the target firmware to send an event notification signal to the target processor core, so that the target processor core enters an interrupt and switches to the kernel mode. Then, a target callback function corresponding to the target fault event can be executed on the target processor core to save the execution context data before entering the interrupt. Among them, the priority of the interrupt corresponding to the event notification signal sent by the target firmware is higher than the priority of the interrupt managed by the operating system kernel. Furthermore, the event notification signal will not be masked by the interrupt managed by the operating system kernel, so that the event notification signal has a certain mandatory characteristic, and the process of the target processor core saving the execution context data before entering the interrupt will not be interfered by the interrupt signal managed by the operating system kernel.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a fault handling method, device, storage medium, and program product. Background Art

[0002] ARM (Advanced RISC Machines) is a processor architecture based on the design principles of RISC (Reduced Instruction Set Computing). RISC is a processor design method that improves performance and efficiency by reducing the number and complexity of instructions. The ARM architecture can be used to design single-core or multi-core processor systems, and the Linux (an open-source operating system) kernel can run on the multi-core processor system.

[0003] During the process of running the Linux kernel on a processor system based on the ARM architecture, if an event on a certain processor core triggers a PANIC (kernel crash) fault, the processor core that triggers the fault can notify other processor cores in the processor system to pause and save the context. The processor core that triggers the fault can collect the context data saved by other processor cores and generate a kernel crash dump file (vmcore) through the KDUMP (Kernel Dump) function.

[0004] However, in some application scenarios, the processor core that triggers the PANIC fault cannot use a reliable method to notify other processor cores to save the context. Therefore, there is a need to propose a new solution. Summary of the Invention

[0005] Multiple aspects of this application provide a fault handling method, device, storage medium, and program product for obtaining reliable post-fault context save data.

[0006] An embodiment of the present application provides a fault handling method, which is applied to a multi-core processor system and includes: when a target fault event occurs in a first processor core in the multi-core processor system, sending a call instruction to a target firmware through an operating system kernel; the target firmware is at a target privilege level, and the priority of an interrupt issued by the target firmware is higher than the priority of an interrupt managed by the operating system kernel; through the target firmware, sending an event notification signal to a target processor core according to the call instruction, so that the target processor core enters an interrupt corresponding to the event notification signal and enters the target privilege level; after the target processor core enters the target privilege level, running the target firmware to switch from the target privilege level to the kernel privilege level, and in the case of being at the kernel privilege level, executing a target callback function corresponding to the target fault event to save execution context data of the target processor core before entering the interrupt corresponding to the event notification signal.

[0007] Optionally, before sending the call instruction to the target firmware through the operating system kernel, it further includes: sending an interrupt signal managed by the operating system kernel to a second processor core in the multi-core processor system through the operating system kernel, where the interrupt signal is used to notify the second processor core to enter an interrupt and save execution context data before entering the interrupt; if a response message of some processor cores in the second processor core for the interrupt signal is not received within a set time range, regarding the some processor cores as the target processor core.

[0008] Optionally, it further includes: for any processor core in the multi-core processor system, initiating a registration request to the target firmware through the operating system kernel using a target interface, where the registration request is used to register the target fault event as a specific event of the processor core; sending the event notification signal to the target processor core according to the call instruction through the target firmware, including: obtaining identification information of the target processor core and event information of the target fault event according to the call instruction through the target firmware; when it is determined according to the event information that the target fault event is a specific event registered by the target processor core, sending the event notification signal corresponding to the target fault event to the target processor core through the target interface according to the identification information of the target processor core.

[0009] Optionally, it further includes: registering, through the operating system kernel, a target callback function for processing the target fault event with the target firmware by using the target interface; executing the target callback function corresponding to the target fault event, including: querying, through the target firmware, the target callback function corresponding to the target fault event from the registered programs; and calling the operating system kernel through the target interface to enable the operating system kernel to execute the target callback function on the target processor core.

[0010] Optionally, the target interface includes: a software exception delegation interface in the multi-core processor system.

[0011] Optionally, it further includes: after saving the execution context data before entering the interrupt corresponding to the event notification signal on the target processor core, controlling, through the target firmware, the target processor core to enter a specified privilege level according to the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal.

[0012] Optionally, controlling, through the target firmware, the target processor core to enter a specified privilege level according to the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal includes: judging, through the target firmware, whether the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal is the kernel privilege level; if so, controlling the target processor core to enter the kernel privilege level to enter a paused running state at the kernel privilege level; if not, controlling the target processor core to return to the privilege level before entering the interrupt corresponding to the event notification signal.

[0013] An embodiment of the present application further provides a fault handling method applied to a multi-core processor system. The method includes: when a target fault event occurs in a first processor core in the multi-core processor system, sending a call instruction to a target firmware through an operating system kernel; the target firmware is at a target privilege level, and the priority of the interrupt issued by the target firmware is higher than the priority of the interrupt managed by the operating system kernel; through the target firmware, sending an event notification signal to a target processor core according to the call instruction to enable the target processor core to enter the interrupt corresponding to the event notification signal and execute the target callback function corresponding to the target fault event to save the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal. An embodiment of the present application further provides an electronic device, including: a memory and a processor; the memory is used for storing one or more computer instructions; the processor is used for executing the one or more computer instructions to: execute the steps in the method provided by the embodiment of the present application.

[0014] An embodiment of the present application also provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, it can implement the steps in the method provided by the embodiment of the present application.

[0015] An embodiment of the present application also provides a computer program product, including: a computer program / instructions, and when the computer program / instructions are executed by a processor, it can implement the steps in the method provided by the embodiment of the present application.

[0016] In the embodiment of the present application, when a target fault event occurs in a processor core in a multi-core processor system, the operating system kernel can call the target firmware to send an event notification signal to the target processor core. After the target processor core enters the interrupt corresponding to the event notification signal and switches to the kernel mode, a target callback function corresponding to the target fault event can be executed on the target processor core to save the execution context data of the target processor core before entering the interrupt. In this implementation, the target firmware is at the target privilege level, while the operating system kernel is at the kernel privilege level, which makes the interrupt issued by the target firmware not managed and scheduled by the operating system kernel. The priority of the interrupt corresponding to the event notification signal issued by the target firmware is higher than the priority of the interrupt managed by the operating system kernel running on the target processor core, and the event notification signal issued by the target firmware will not be masked by the interrupt managed by the operating system kernel, making the event notification signal issued by the target firmware have a certain mandatory characteristic. The process of saving the execution context data before entering the interrupt will not be interfered by the interrupt signal managed by the operating system kernel. Furthermore, the saved fault scene data can be made more complete and reliable. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The schematic embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation of the present application. In the drawings:

[0018] Figure 1 It is a schematic diagram of the privilege levels defined in the ARM architecture for v8 and above versions;

[0019] Figure 2 It is a flowchart of the fault handling method provided by an exemplary embodiment of the present application;

[0020] Figure 3 It is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0021] To make the objectives, technical solutions and advantages of this application more clear, the following will clearly and completely describe the technical solutions of this application in combination with specific embodiments of this application and the corresponding drawings. Obviously, the described embodiments are only a part rather than all of the embodiments of this application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this application without creative efforts shall fall within the scope of protection of this application.

[0022] The terms used in the embodiments of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. The singular forms "a", "the" and "said" used in the embodiments of the present invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. "Plural" generally includes at least two, but does not exclude the case of including at least one.

[0023] It should be understood that the term "and / or" used herein is only a kind of association relationship describing associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " herein generally represents an "or" relationship between the associated objects before and after.

[0024] It should also be noted that the term "comprises", "comprising" or any other variant thereof is intended to cover a non-exclusive inclusion, so that a product or system including a series of elements not only includes those elements but also includes other elements not explicitly listed, or further includes elements inherent to such product or system. Without further limitation, an element defined by the statement "comprising a..." does not exclude the existence of additional identical elements in the product or system including the said element.

[0025] To more clearly describe the technical solutions provided by the embodiments of this application, the following first introduces the relevant terms involved in the embodiments of this application:

[0026] ARM64 is a multi-core processor system based on the ARM architecture that supports 64-bit operating systems. Multi-core means multiple processor cores.

[0027] Linux Kernel is an open-source operating system kernel. The Linux kernel, together with user-space tools, libraries and applications, constitutes a complete Linux operating system.

[0028] KDUMP is a function of the Linux kernel used to generate a kernel crash dump file, namely the vmcore file, when the system crashes. The vmcore file contains the memory state at the time of system crash and can be used to analyze the cause of the crash.

[0029] The GIC (Generic Interrupt Controller) is a hardware component in the ARM architecture for managing interrupts. It is responsible for receiving interrupt signals from various peripherals and from the processor cores, and passing these requests to the processor cores for processing.

[0030] The GIC CPU interface, which is part of the GIC, is directly connected to each CPU core and is responsible for handling interrupt signals related to that CPU core. Each CPU core has a corresponding GIC CPU interface that can receive interrupt signals and determine which interrupts should be passed to the CPU core for processing.

[0031] IPI (Inter-Processor Interrupt) is an interrupt used between processors that enables one processor to send an interrupt signal to another processor.

[0032] NMI (Non-Maskable Interrupt) is a high-priority interrupt that cannot be masked by software and is typically used to handle emergency situations or critical events, such as fault detection.

[0033] The Secure World is an independent execution environment in the ARM architecture for running code and data that requires high security. It is isolated from the Non-Secure World to prevent code in the Non-Secure World from accessing or tampering with resources in the Secure World.

[0034] The privilege level, also known as the exception level or execution level, is used to define the operations that a processor core can perform and the resources it can access in different modes. For example, Figure 1As shown, in some ARM architectures with v8 and above versions, several privilege levels from low to high, namely EL0, EL1, EL2, and EL3, are defined, and each level has different permissions and uses. In the ARM64 system, the operating system kernel runs at the EL1 level or the EL2 level, and the EL1 level or the EL2 level can be called the kernel privilege level. The EL3 level is the highest privilege level in the ARMv8 and above versions of the architecture, and is usually used to perform security-sensitive operations and has full control over system resources. EL3 is part of the secure world and provides a high level of protection and isolation. In a multi-core ARM64 architecture, each processor core can independently switch between different privilege levels. For example, a certain processor core can execute a user-space program at the EL0 privilege level, another processor core can execute a system call at the EL1 privilege level, and yet another processor core can execute virtual machine code at the EL2 privilege level.

[0035] ATF (Trusted Firmware-A (TF-A), trusted firmware - privilege) is the firmware running at the EL3 level in ARM64 and is used to provide secure boot and runtime services. In a multi-core processor system, the ATF firmware can request and respond to communication between processor cores.

[0036] SDEI (Software Delegated Exception Interface) is an interface provided by the firmware in the ARM64 architecture. This interface allows the firmware to delegate certain types of exceptions (such as interrupts) to the operating system kernel for handling. The operating system kernel can register and enable the handling of specific exception events through the SDEI interface and provide target callback functions to handle these events. When the corresponding exception event occurs, the firmware can switch the processor core to the kernel privilege level and call the operating system kernel to execute the target callback function to handle the specific exception event.

[0037] SDEI EVENT (Software Delegated Exception Interface Event) is an interrupt or other exception event passed to the operating system kernel through the SDEI mechanism. The operating system kernel can register and handle these events through the SDEI interface, thereby achieving more efficient interrupt handling.

[0038] SDEI Signal Event 0 (SDEI_EVENT_SIGNAL 0) is a specific type of SDEI EVENT used to notify the operating system kernel of certain specific events or state changes.

[0039] When an exception occurs while the Linux kernel is running on an ARM64 system, the PANIC function can be called to trigger the processing flow of the fault event. The processor core that triggers the PANIC fault can notify other cores to perform context saving. Context saving refers to saving the context data of the current execution environment when an interrupt, exception, or task switch occurs. However, in the Linux kernel running on an ARM64 system, there is a risk of failure when saving the context based on a normal IPI, which may lead to the inability to fully obtain the context data of the execution environment and affect exception analysis. For example, when some PANIC faults occur, some processor cores cannot be interrupted by a normal IPI, and thus cannot save the context data of the execution environment.

[0040] A solution for saving the exception context is a solution based on "pseudo" non-maskable interrupt (pseudo-NMI). In this solution, the GIC CPU interface supports setting the interrupt priority, and the GIC CPU interface supports interrupt priority filtering, which means that when the priority of an interrupt is higher than the interrupt priority set by the GIC CPU interface, this interrupt will be responded to. In the pseudo-NMI solution, the priority of the IPI used for context saving can be increased, and the priorities of other normal interrupts can be set lower than the priority of this IPI interrupt. At the same time, the interrupt filtering priority of the GIC CPU interface is set higher than the normal interrupt priority and lower than the priority of this IPI interrupt. Based on this solution, when a PANIC fault occurs, the IPI interrupt used for context saving can normally interrupt other processor cores, so that all processor cores save the execution context information. However, this solution requires setting the function support related to pseudo-NMI in the Linux kernel, which may cause performance impact on the Linux kernel in some usage scenarios.

[0041] Another solution for saving the exception context is a solution based on GIC NMI. In this solution, when the GIC supports NMI, the IPI can be set as a non-maskable interrupt in the GIC. Then, for any processor core, when a PANIC occurs, other processor cores can be reliably notified to perform context saving through the IPI. However, currently, a large number of GICs in ARM64 environments do not support NMI.

[0042] In view of the above technical problems, the embodiments of the present application provide a solution. The following will describe in detail the technical solutions provided by the embodiments of the present application with reference to the accompanying drawings.

[0043] Figure 2 It is a schematic flowchart of a fault handling method provided by an exemplary embodiment of the present application. The method may include the steps as Figure 2 shown:

[0044] Step 201: When a target fault event occurs in the first processor core of a multi-core processor system, send a call instruction to the target firmware through the operating system kernel; the target firmware is at a target privilege level, and the priority of the interrupt issued by the target firmware is higher than the priority of the interrupt managed by the operating system kernel.

[0045] Step 202: Through the target firmware, send an event notification signal to the target processor core according to the call instruction, so that the target processor core enters the interrupt corresponding to the event notification signal and enters the target privilege level.

[0046] Step 203: After the target processor core enters the target privilege level, run the target firmware to switch from the target privilege level to the kernel privilege level, and in the case of being at the kernel privilege level, execute the target callback function corresponding to the target fault event to save the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal.

[0047] The execution entity of this embodiment may be a multi-core processor system, which may be a multi-core processor system based on the ARM architecture, for example, it may be a multi-core processor system based on the ARM64 architecture. The multi-core processor system includes multiple processor cores, firmware, and an operating system kernel running on the processor cores. Among them, the operating system kernel may be the Linux kernel.

[0048] In this embodiment, when any processor core in the multi-core processor system triggers a target fault event, it can notify other processor cores in the multi-core processor system to perform on-site saving, which is used to enable each processor core to save its execution context data, including register status, stack information, memory status, interrupt status, device status, and log information. The processor core that has a target fault event can collect the execution context data saved by other processor cores and generate a kernel crash dump file for the collected execution context data through the KDUMP function.

[0049] In this embodiment, the target fault event refers to a type of fault that requires on-site saving for subsequent fault analysis and debugging, such as but not limited to: PANIC fault, memory error (such as memory parity error, memory chip damage), software fault, security vulnerability, or interrupt handling error, etc. This embodiment includes but is not limited to this.

[0050] In this embodiment, for the convenience of description, the processor core where a target fault event occurs in the multi-core processor system is described as the first processor core, and the processor core that needs to perform in-situ preservation is described as the second processor core. Here, "first" and "second" are only for facilitating the distinction between different processor cores and are not used to limit the order, position, and quantity of the processor cores.

[0051] Taking the target fault event being a PANIC fault as an example, when the first processor core has a PANIC fault, the operating system kernel can handle the PANIC fault. When handling the target fault event, the operating system kernel can call the panic() function to stop the multi-core processor system and obtain information for diagnosing the fault. During the process of calling the panic() function, the operating system kernel can call the target firmware in the multi-core processor system to achieve communication between multiple processor cores. Based on this, in step 201, the operating system kernel can send a call instruction to the target firmware in the multi-core processor system to send an event notification signal corresponding to the target fault event to the target processor core in the multi-core processor system through the target firmware. Among them, the target processor core can be all or part of the processor cores in the second processor core.

[0052] After the operating system kernel sends a call instruction to the target firmware, the first processor core enters the target privilege level corresponding to the target firmware. In some optional embodiments, the target privilege level corresponding to the target firmware is Figure 1 the EL3 level shown. After the first processor core enters the privilege level where the target firmware is located, the first processor core can run the target firmware. In step 202, the target firmware can send an event notification signal to the target processor core according to the call instruction of the operating system kernel, so that the target processor core enters the interrupt corresponding to the event notification signal and enters the target privilege level corresponding to the target firmware.

[0053] In this embodiment, the target firmware can be any firmware running at the EL3 level. For example, it can be the ATF firmware running at the EL3 level. The firmware running at the EL3 level has full control over the hardware resources or software resources at other levels. When the target firmware runs at the EL3 level, it can handle security interrupts at the EL3 level. When the operating system kernel runs at the EL1 level or the EL2 level, the operating system kernel can execute non-security interrupts at the EL1 level or the EL2 level. The priority of security interrupts is higher than that of non-security interrupts. When a target failure event occurs in the first processor core, the target firmware running at the EL3 level can use the processing method of security interrupts to send an event notification signal with a higher interrupt priority to the target processor core. That is to say, the priority of the interrupt corresponding to the event notification signal sent by the target firmware is higher than that of the interrupts managed by the operating system kernel, so that the event notification signal sent by the target firmware cannot be masked by the interrupt signals managed by the operating system kernel. After receiving the event notification signal sent by the target firmware, the target processor core can enter the interrupt and switch to the target privilege level corresponding to the target firmware, that is, the EL3 level.

[0054] In step 203, after the target processor core enters the target privilege level corresponding to the target firmware, the target processor core can run the target firmware, and the target firmware can switch the target processor core to the kernel privilege level, that is, the EL1 or EL2 level. After the target processor core enters the kernel privilege level, the target callback function corresponding to the target failure event can be executed on the target processor core.

[0055] In this step, the target callback function corresponding to the target failure event can be a pre-defined function that can be called by the operating system kernel. In some embodiments, when the types of failure events that occur in the processor core are different, different types of failure events can pre-define different callback functions, and each callback function is used to execute the processing logic corresponding to the corresponding type of failure event. In this embodiment, the target callback function is a callback function having a corresponding relationship with the target failure event and is used to execute the processing logic corresponding to the target failure event. Optionally, when the target failure event is a PANIC failure event, the target callback function can be used to save the execution context data before the target processor core enters the interrupt corresponding to the event notification signal when it is executed. The execution context data can include at least one of register status, stack information, memory status, interrupt status, device status, and log information. The above execution context data can be used to generate a kernel crash dump file for analyzing the cause of the failure after the failure.

[0056] In this embodiment, when a target failure event occurs in a processor core of a multi-core processor system, the operating system kernel can call the target firmware to send an event notification signal to the target processor core. After the target processor core enters the interrupt corresponding to the event notification signal and switches to the kernel mode, the target callback function corresponding to the target failure event can be executed on the target processor core to save the execution context data of the target processor core before entering the interrupt. In this implementation, the priority of the interrupt corresponding to the event notification signal sent by the target firmware is higher than the priority of the interrupt managed by the operating system kernel running on the target processor core, and the event notification signal sent by the target firmware cannot be masked by the interrupt managed by the operating system kernel, making the event notification signal sent by the target firmware have a certain mandatory characteristic. The process of saving the execution context data before entering the interrupt will not be interfered by the interrupt signal managed by the operating system kernel. Furthermore, the saved fault scene data can be made more complete and reliable.

[0057] In some exemplary embodiments, before sending a call instruction to the target firmware through the operating system kernel, the operating system kernel can first send an interrupt signal managed by the operating system kernel to a second processor core in the multi-core processor system. This interrupt signal is used to notify the second processor core to enter the interrupt and save the execution context data before entering the interrupt. Among them, the second processor core can be one or more processor cores that need to perform on-site preservation in the multi-core processor system except for the first processor core. Among them, the interrupt signal managed by the operating system kernel can be a normal IPI or a pseudo-NMI, and this embodiment does not make any restrictions. After the operating system kernel sends the interrupt signal to the second processor core, it can wait for the response message of the second processor core.

[0058] In some embodiments, when the interrupt signal is a normal IPI that can be masked, on some processor cores, this type of interrupt signal may be masked by the interrupt mask, resulting in the failure to successfully perform the on-site preservation operation. When the interrupt signal is a pseudo-NMI, in some abnormal situations, it will also cause the failure to successfully perform the on-site preservation operation on some processor cores.

[0059] For any processor core in the second processor core, if the context save operation is successfully executed after entering the interrupt corresponding to the interrupt signal, a response message can be returned to the operating system kernel. If the interrupt signal is masked by the interrupt mask or an exception occurs, the processor core cannot respond to the interrupt signal and cannot return a response message to the operating system kernel. For the operating system kernel, if the response messages returned by some of the processor cores in the second processor core for the interrupt signal are not received, these processor cores can be used as target processor cores. Subsequently, the operating system kernel can call the target firmware to send an event notification signal to the target processor core, so as to force the target processor core to enter the interrupt process in a higher-priority interrupt manner.

[0060] In this embodiment, the operating system kernel preferentially notifies the second processor core to perform context save through IPI or pseudo-NMI. In the case where some processor cores cannot successfully perform context save through IPI, the method of sending an event notification signal to the target processor core based on the target firmware is then enabled to notify the target processor core to perform context save, so that the IPI or pseudo-NMI method can complement the context save method based on the target firmware and the SDEI mechanism, further improving the reliability of the context save operation after a failure.

[0061] In some alternative embodiments, the target firmware can interact with the operating system kernel in the multi-core processor system through the target interface. Optionally, the target interface can be a custom-developed communication interface, or can be a software exception delegation interface (SDEI).

[0062] Optionally, the operating system kernel can register specific events of the processor core on the target firmware through the target interface. For any processor core in the multi-core processor system, the operating system kernel can initiate a registration request to the target firmware through the target interface, and the registration request is used to register the target fault event as a specific event of the processor core. Correspondingly, when the target firmware sends an event notification signal to the target processor core according to the call instruction, the target firmware can obtain the identification information of the target processor core and the event information of the target fault event according to the call instruction, and when it is determined according to the event information that the target fault event is a specific event registered by the target processor core, according to the identification information of the target processor core, send an event notification signal corresponding to the target fault event to the target processor core through the target interface. Optionally, the call instruction sent by the operating system kernel to the target firmware can carry the identification information of the target processor core and the event information of the target fault event, and the target firmware can obtain the identification information of the target processor core and the event information of the target fault event by parsing the call instruction.

[0063] Taking the target interface as SDEI as an example, in the ARM architecture, SDEI events include multiple types, where SDEI_EVENT_SIGNAL 0 is a specific event type used to notify the operating system kernel of this specific event when a specific event occurs. In this embodiment, the specific event may be a target fault event on the first processor core. The operating system kernel can register the target fault event as an event of the SDEI_EVENT_SIGNAL 0 type on the target firmware through the SDEI interface and activate the function of this event. When the target fault event occurs, the target firmware can send an event notification signal of the SDEI_EVENT_SIGNAL 0 type to the target processor core through the SDEI interface.

[0064] In this implementation, by registering the target fault event in the target firmware, it is possible to send an event notification signal with a higher interrupt priority when the target fault event occurs, and high-priority interrupts can be achieved without modifying the hardware.

[0065] In some alternative embodiments, the operating system kernel can also use the target interface to register a target callback function for processing the target fault event on the target firmware. The target callback function is used to execute the processing logic after the target fault event occurs. When the types of fault events are different, the operating system kernel can use the target interface to register different programs for different types of fault events. Correspondingly, after the target firmware switches the target processor core to the kernel privilege level, the target firmware can query the target callback function corresponding to the target fault event from the registered programs and call the operating system kernel to execute the target callback function on the target processor core.

[0066] Taking the target interface as SDEI and the target firmware as ATF firmware as an example, in a multi-core processor system, the operating system kernel can use any processor core to initiate a registration request to the ATF firmware through the SDEI interface. The registration request of this processor core is used to register the target fault event as a specific event of the SDEI_EVENT_SIGNAL 0 type in the ATF firmware. The operating system kernel can provide a target callback function for the specific event of the SDEI_EVENT_SIGNAL 0 type, and this target callback function is the processing logic when the specific event of the SDEI_EVENT_SIGNAL 0 type occurs. When the target fault event occurs, the operating system kernel can send a call instruction to the ATF firmware, and this call instruction can include the identification information of the target processor core and the event information of the target fault event. When the ATF firmware determines that the target fault event is a specific event of the SDEI_EVENT_SIGNAL 0 type, it can send an event notification signal to the target processor core through the SDEI interface, so that the target processor core switches to the EL3 level after entering the interrupt. After the target processor core enters the EL3 level, the target firmware can switch the target processor core to the EL1 or EL2 level, and call the operating system kernel through the SDEI interface, so that the operating system kernel executes the target callback function corresponding to the specific event of the SDEI_EVENT_SIGNAL 0 type on the target processor core.

[0067] In this embodiment, when the target callback function is executed by any processor core, it can be used to save the execution context data of this processor core before entering the interrupt process corresponding to the event notification signal. In this implementation, the execution operation of the target callback function is not affected by enabling interrupts or disabling interrupts in the lower privilege levels managed by the operating system kernel, realizing a highly reliable on-site saving scheme.

[0068] In some alternative embodiments, the callback function is executed in the context environment of SDEI. After the callback function completes the on-site saving, it can notify the ATF firmware of the execution status and return to the specified execution site. Optionally, after the target processor core saves the execution context data, the target callback function can return a completion notification message to the target firmware. Before the target processor core enters the interrupt corresponding to the event notification signal, it may operate in the environment of the EL1 level or the EL0 level. After the target processor core saves the execution context data, the target firmware can control the target processor core to enter the specified privilege level according to the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal. Among them, the specified privilege level can be the privilege level before the interrupt or other privilege levels. Based on this implementation, the interrupt initiated by the target firmware through the target interface can meet the specifications corresponding to the target interface, thus ensuring the stability and security of the multi-core processor system.

[0069] Optionally, the target firmware can determine whether the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal is the kernel privilege level. If so, the target firmware can control the target processor core to enter the kernel privilege level to enter the suspended running state at the kernel privilege level. Specifically, after entering the kernel privilege level, the operating system kernel can return the target processor core from the target callback function to a specified function, which is a function that executes in an infinite loop to suspend the target processor core. If the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal is not the kernel privilege level, the target firmware can control the target processor core to return to the privilege level before entering the interrupt corresponding to the event notification signal. When returning to the privilege level before the interrupt, the target firmware can restore the register values before executing the callback function, including general registers, stack pointers, status registers, etc., to ensure that the restored state is consistent with the state before entering the callback function, so as to reduce the risk of potential problems.

[0070] In this embodiment, when the callback function is executed in the context of SDEI, after the callback function finishes executing and saves the scene, it notifies the ATF firmware of the execution status and returns to the specified execution scene, which can ensure that the processing process of the callback function does not block the normal interrupt processing path. Returning immediately to the specified execution scene after the SDEI callback is completed can reduce the possibility of triggering another interrupt during the process of processing one interrupt, thereby reducing the risk of interrupt nesting and deadlock. In addition, the risk of having multiple pending interrupts (i.e., interrupts in the pending state) can be reduced, and the risk that some important interrupts are postponed indefinitely, resulting in deadlocks or other unstable states can be reduced.

[0071] It should be noted that in some other alternative embodiments of the embodiments of the present application, when a target failure event occurs in the first processor core in a multi-core processor system, the first processor core can send a call instruction to the target firmware through the operating system kernel. The target firmware is at the target privilege level, and the priority of the interrupt issued by the target firmware is higher than the priority of the interrupt managed by the operating system kernel. The first processor core can send an event notification signal to the target processor core through the target firmware according to the call instruction, so that the target processor core enters the interrupt corresponding to the event notification signal and executes the target callback function corresponding to the target failure event to save the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal.

[0072] In this embodiment, the target firmware may encapsulate the processing logic related to on-site preservation. After the target processor core enters the interrupt corresponding to the event notification signal, the target callback function corresponding to the target fault event may be executed through the target firmware to save the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal. Alternatively, the target firmware may call other firmware in the target privilege level or call other modules in the kernel privilege level to execute the target callback function corresponding to the target fault event to save the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal, which will not be elaborated herein.

[0073] It should be noted that the execution subject of each step of the method provided in the above embodiments may be the same device, or the method may also be executed by different devices as the execution subject. For example, the execution subject of steps 201 to 203 may be device A; for another example, the execution subject of steps 201 and 202 may be device A, and the execution subject of step 203 may be device B; and so on.

[0074] In addition, in some of the processes described in the above embodiments and the accompanying drawings, multiple operations appear in a specific order, but it should be clearly understood that these operations may not be executed in the order in which they appear in this article or may be executed in parallel. The operation numbers such as 201 and 202 are only used to distinguish different operations, and the numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions such as "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a sequence, nor do they limit that "first" and "second" are of different types.

[0075] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0076] Figure 3 Schematically shows the structural diagram of an electronic device provided by an exemplary embodiment of the present application, as Figure 3 shown, the electronic device includes: a memory 301 and a processor 302. Among them, the processor 302 is a multi-core processor.

[0077] A memory 301 for storing computer programs and configurable to store various other data to support operations on an electronic device. Examples of such data include instructions for any application or method for operating on the electronic device.

[0078] A processor 302, coupled to the memory 301, for executing the computer program in the memory 301 to: when a target failure event occurs in a first processor core in a multi-core processor system, send a call instruction to target firmware through an operating system kernel; the target firmware is at a target privilege level, and the priority of an interrupt issued by the target firmware is higher than the priority of an interrupt managed by the operating system kernel; through the target firmware, send an event notification signal to a target processor core according to the call instruction, so that the target processor core enters the interrupt corresponding to the event notification signal and enters the target privilege level; after the target processor core enters the target privilege level, run the target firmware to switch from the target privilege level to the kernel privilege level, and in the case of being at the kernel privilege level, execute a target callback function corresponding to the target failure event to save the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal.

[0079] Optionally, before sending a call instruction to the target firmware through the operating system kernel, the processor 302 is further configured to: send an interrupt signal managed by the operating system kernel to a second processor core in the multi-core processor system through the operating system kernel, the interrupt signal being used to notify the second processor core to enter an interrupt and save the execution context data before entering the interrupt; if a response message from some processor cores in the second processor core to the interrupt signal is not received within a set time range, use the some processor cores as the target processor core.

[0080] Optionally, the processor 302 is further configured to: for any processor core in the multi-core processor system, send a registration request to the target firmware through the operating system kernel using a target interface, the registration request being used to register the target failure event as a specific event of the processor core; when sending an event notification signal to the target processor core according to the call instruction through the target firmware, the processor 302 is specifically configured to: obtain the identification information of the target processor core and the event information of the target failure event according to the call instruction through the target firmware; when it is determined according to the event information that the target failure event is a specific event registered by the target processor core, send the event notification signal corresponding to the target failure event to the target processor core through the target interface according to the identification information of the target processor core.

[0081] Optionally, the processor 302 is further configured to: register, through the operating system kernel, a target callback function for processing the target fault event with the target firmware by using the target interface; when the processor 302 executes the target callback function corresponding to the target fault event, it is specifically configured to: query, through the target firmware, the target callback function corresponding to the target fault event from the registered programs; and call the operating system kernel through the target interface to enable the operating system kernel to execute the target callback function on the target processor core.

[0082] Optionally, the target interface includes: a software exception delegation interface in the multi-core processor system.

[0083] Optionally, the processor 302 is further configured to: after saving the execution context data before entering the interrupt corresponding to the event notification signal in the target processor core, control the target processor core to enter a specified privilege level through the target firmware according to the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal.

[0084] Optionally, when the processor 302 calls the target firmware to control the target processor core to enter a specified privilege level according to the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal through the target firmware, it is specifically configured to: determine, through the target firmware, whether the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal is the kernel privilege level; if so, control the target processor core to enter the kernel privilege level to enter a suspended running state at the kernel privilege level; if not, control the target processor core to return to the privilege level before entering the interrupt corresponding to the event notification signal.

[0085] Figure 3 The illustrated electronic device can also be used to execute the following fault handling method. The electronic device is a multi-core processor system. The processor 302 is specifically configured to: when a target fault event occurs in the first processor core in the multi-core processor system, send a call instruction to the target firmware through the operating system kernel; the target firmware is at a target privilege level, and the priority of the interrupt issued by the target firmware is higher than the priority of the interrupt managed by the operating system kernel; through the target firmware, send an event notification signal to the target processor core according to the call instruction to enable the target processor core to enter the interrupt corresponding to the event notification signal and execute the target callback function corresponding to the target fault event to save the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal.

[0086] Further, as Figure 3As shown, the electronic device further includes: other components such as a communication component 303, a power supply component 304, a display component 305, and an audio component 306. Figure 3 Only some components are schematically shown, which does not mean that the electronic device only includes Figure 3 the components shown. Figure 3 Among them, the components within the dashed box are optional components, rather than mandatory components, and can be determined according to the product form of the electronic device. The electronic device in this embodiment can be implemented as a terminal device such as a desktop computer, a laptop computer, a smart phone, or an IOT device, or can also be a server device such as a conventional server, a cloud server, or a server array. If the electronic device in this embodiment is implemented as a terminal device such as a desktop computer, a laptop computer, or a smart phone, it may include Figure 3 the components within the dashed box; if the electronic device in this embodiment is implemented as a server device such as a conventional server, a cloud server, or a server array, it may not include Figure 3 the components within the dashed box.

[0087] Among them, the memory 301 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic disk, or an optical disk.

[0088] The above-mentioned communication component 303 is configured to facilitate communication between the device where the communication component is located and other devices in a wired or wireless manner. The device where the communication component is located can access a wireless network based on a communication standard, such as a mobile communication network such as 2G, 3G, 4G / LTE, 5G, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel.

[0089] Among them, the power supply component 304 is used to provide power for various components of the device where the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device where the power supply component is located.

[0090] The display component includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions, but also detect the duration and pressure associated with the touch or swipe operation.

[0091] The above audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), which is configured to receive external audio signals when the device where the audio component is located is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals can be further stored in the memory or sent via the communication component. In some embodiments, the audio component further includes a speaker for outputting audio signals.

[0092] In this embodiment, when a target fault event occurs in a processor core of a multi-core processor system, the operating system kernel can call the target firmware to send an event notification signal to the target processor core. After the target processor core enters the interrupt corresponding to the event notification signal and switches to the kernel mode, the target callback function corresponding to the target fault event can be executed on the target processor core to save the execution context data of the target processor core before entering the interrupt. In this implementation, the priority of the interrupt corresponding to the event notification signal sent by the target firmware is higher than the priority of the interrupts managed by the operating system kernel running on the target processor core, and the event notification signal sent by the target firmware cannot be masked by the interrupts managed by the operating system kernel, making the event notification signal sent by the target firmware have a certain mandatory characteristic. The process of saving the execution context data before entering the interrupt will not be interfered by the interrupt signals managed by the operating system kernel. Furthermore, the saved fault scene data can be made more complete and reliable.

[0093] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, and when the computer program is executed, it can implement each step executable by an electronic device in the above method embodiment. Among them, the computer-readable storage medium can be implemented by volatile or non-volatile or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices or any other non-transmission medium.

[0094] Accordingly, an embodiment of the present application further provides a computer program product, the computer program product includes a computer program or instructions, and when the computer program or instructions are executed by a processor, the processor can implement each step in the above method embodiment. It should be understood that each process or a combination of multiple processes in the above method flow can be implemented by the computer program or instructions. In addition, these computer programs or instructions can be applied to the processors of general-purpose computers, special-purpose computers, embedded processors or other programmable data processing devices, so that the processors of general-purpose computers, special-purpose computers, embedded processors or other programmable data processing devices can be used as devices to implement the corresponding functions in the above method embodiment.

[0095] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of another identical element in the process, method, commodity or device including the element.

[0096] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A fault handling method, characterized in that: Applied to a multi-core processor system, the method comprises: When a target fault event occurs in a first processor core in a multi-core processor system, a call instruction is sent to a target firmware through an operating system kernel; the target firmware is at a target privilege level, and the priority of an interrupt issued by the target firmware is higher than the priority of an interrupt managed by the operating system kernel; Sending, by the target firmware, an event notification signal to a target processor core in the multi-core processor system according to the call instruction, so that the target processor core enters an interrupt corresponding to the event notification signal and enters the target privilege level; After the target processor core enters the target privilege level, the target firmware is run to be switched from the target privilege level to the kernel privilege level by the target firmware, and when in the kernel privilege level, the target callback function corresponding to the target fault event is executed to save the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal, and the interrupt corresponding to the event notification signal is not masked by the interrupt managed by the operating system kernel.

2. The method according to claim 1, characterized in that Before sending the call instruction to the target firmware through the operating system kernel, the method further includes: Sending, through the operating system kernel, an interrupt signal managed by the operating system kernel to a second processor core in the multi-core processor system, wherein the interrupt signal is used to notify the second processor core to enter an interrupt and save execution context data before entering the interrupt; If no response message to the interrupt signal is received from some of the processor cores in the second processor core within a set time range, the some of the processor cores are used as the target processor cores.

3. The method according to claim 1, characterized in that Also includes: For any processor core in the multi-core processor system, a registration request is initiated to the target firmware through the operating system kernel and a target interface, wherein the registration request is used to register the target fault event as a specific event of the processor core; Sending an event notification signal to a target processor core according to the calling instruction through the target firmware includes: Acquiring, by the target firmware, identification information of the target processor core and event information of the target fault event according to the calling instruction; When it is determined according to the event information that the target fault event is a specific event registered by the target processor core, an event notification signal corresponding to the target fault event is sent to the target processor core through the target interface according to the identification information of the target processor core.

4. The method according to claim 3, characterized in that Also includes: By means of the operating system kernel, registering a target callback function for processing the target fault event with the target firmware using the target interface; Executing the target callback function corresponding to the target fault event includes: Querying, through the target firmware, a target callback function corresponding to the target fault event from the registered programs; The operating system kernel is called through the target interface so that the operating system kernel executes the target callback function on the target processor core.

5. The method according to claim 3 or 4, characterized in that: The target interface includes: a software exception delegation interface in the multi-core processor system.

6. The method according to claim 5, characterized in that Also includes: After the target processor core saves the execution context data before entering the interrupt corresponding to the event notification signal, the target processor core is controlled to enter a specified privilege level through the target firmware according to the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal.

7. The method according to claim 6, characterized in that The target firmware is used to control the target processor core to enter a specified privilege level according to the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal, including: Determining, by the target firmware, whether the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal is a kernel privilege level; If yes, controlling the target processor core to enter a kernel privilege level, so as to enter a suspended operation state in the kernel privilege level; If not, the target processor core is controlled to return to the privilege level before entering the interrupt corresponding to the event notification signal.

8. A fault handling method, characterized in that: Applied to a multi-core processor system, the method comprises: When a target fault event occurs in a first processor core in a multi-core processor system, a call instruction is sent to a target firmware through an operating system kernel; the target firmware is at a target privilege level, and the priority of an interrupt issued by the target firmware is higher than the priority of an interrupt managed by the operating system kernel; Through the target firmware, an event notification signal is sent to the target processor core in the multi-core processor system according to the calling instruction, so that the target processor core enters the interrupt corresponding to the event notification signal, and executes the target callback function corresponding to the target fault event to save the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal. The interrupt corresponding to the event notification signal is not masked by the interrupt managed by the operating system kernel.

9. An electronic device, characterized in that: include: Memory and processor; The memory is used to store one or more computer instructions; The processor is configured to execute the one or more computer instructions to: perform the steps in the method according to any one of claims 1-8.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps in the method described in any one of claims 1 to 8 can be implemented.

11. A computer program product, characterized in that include: A computer program / instruction, which, when executed by a processor, can implement the steps of the method according to any one of claims 1 to 8.

Images