Fault processing method and device, storage medium and program product

Abstract

The embodiment of the invention provides a fault processing method and device, a storage medium and a program product. In the fault processing method, when a processor core in the multi-core processor system has a target fault event, an operating system kernel can call target firmware to send an event notification signal to a target processor core, so that the target processor core enters an interruption state and is switched to a kernel state. Thereafter, a target callback function corresponding to the target fault event may be executed on the target processor core to save execution context data prior to entering the interrupt. Wherein the priority of the interrupt corresponding to the event notification signal sent by the target firmware is higher than that of the interrupt managed by the kernel of the operating system, so that the event notification signal is not shielded by the interrupt managed by the kernel of the operating system, and the event notification signal has a certain forcing characteristic; the process that the target processor core stores the execution context data before entering the interrupt is not interfered by an interrupt signal managed by an operating system kernel.

Description

Technical Field

[0001] The present application relates to the field of computer technology, 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 RISC (Reduced Instruction Set Computing) design principles. RISC is a processor design approach 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, which can run the Linux kernel (an open source operating system).

[0003] When running the Linux kernel on an ARM-based processor system, if an event on a processor core triggers a PANIC (kernel panic) fault, the processor core that triggered the fault can notify other processor cores in the system to pause and save the current state. The processor core that triggered the fault can collect the current state data saved by other processor cores and use the KDUMP (Kernel Dump) function to generate a kernel crash dump file (vmcore).

[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 perform field preservation. Therefore, a new solution is needed. Summary of the Invention

[0005] Various aspects of the present application provide a fault handling method, device, storage medium, and program product for obtaining reliable post-fault on-site data preservation.

[0006] An embodiment of the present application provides a fault handling method, which is applied to a multi-core processor system, comprising: when a target fault event occurs in the 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 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; 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 executing a target callback function corresponding to the target fault event while at the kernel privilege level to save the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal.

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

[0008] Optionally, it also includes: for any processor core in the multi-core processor system, through the operating system kernel, using the target interface to initiate a registration request to the target firmware, the registration request is used to register the target fault event as a specific event of the processor core; through the target firmware, according to the call instruction, sending an event notification signal to the target processor core, including: through the target firmware, according to the call instruction, obtaining the identification information of the target processor core and the event information of the target fault event; when it is determined that the target fault event is a specific event registered by the target processor core according to the event information, 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 also includes: through the operating system kernel, using the target interface to register a target callback function for handling the target fault event to the target firmware; executing the target callback function corresponding to the target fault event, including: through the target firmware, querying the target callback function corresponding to the target fault event from the registered program; calling the operating system kernel through the target interface so that the operating system kernel executes 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 also includes: after the target processor core saves the execution context data before entering the interrupt corresponding to the event notification signal, through the target firmware, controlling 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, the target firmware is called to control the target processor core to enter a specified privilege level based on the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal, including: judging by 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 yes, controlling the target processor core to enter the kernel privilege level to enter a suspended operation state in the kernel privilege level; if no, 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 also provides a fault handling method, which is applied to a multi-core processor system, the method comprising: when a target fault event occurs in the first processor core in the multi-core processor system, sending 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, sending 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 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. An embodiment of the present application also provides an electronic device, comprising: a memory and a processor; the memory is used to store one or more computer instructions; the processor is used to execute the one or more computer instructions to: perform the steps in the method provided in the embodiment of the present application.

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

[0015] An embodiment of the present application further provides a computer program product, comprising: a computer program / instructions, which, when executed by a processor, can implement the steps of the method provided in the embodiment of the present application.

[0016] In an 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 may invoke 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 kernel mode, a target callback function corresponding to the target fault event may be executed on the target processor core to save the execution context data of the target processor core before entering the interrupt. In this embodiment, the target firmware is at the target privilege level, while the operating system kernel is at the kernel privilege level. This means that the interrupt issued by the target firmware is not managed and scheduled by the operating system kernel. The interrupt corresponding to the event notification signal issued by the target firmware has a higher priority than the interrupt managed by the operating system kernel running on the target processor core. The event notification signal issued by the target firmware will not be masked by the interrupt managed by the operating system kernel, giving the event notification signal issued by the target firmware a certain mandatory characteristic. The process of saving the execution context data before entering the interrupt will not be interfered with by the interrupt signal managed by the operating system kernel. As a result, the saved fault scene data can be 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 illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 This is a diagram of the privilege levels defined in ARM architecture v8 and above; Figure 2 A flowchart of a fault handling method provided by an exemplary embodiment of the present application; Figure 3 A schematic structural diagram of an electronic device provided as an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0018] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0020] It should be understood that the term "and / or" as used herein is merely a description of the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. Furthermore, the character " / " in this document generally indicates that the associated objects are in an "or" relationship.

[0021] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a product or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such a product or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the product or system comprising the element.

[0022] In order to more clearly describe the technical solutions provided by the embodiments of the present application, the following first introduces the relevant terms involved in the embodiments of the present application: ARM64 is a multi-core processor system based on the ARM architecture that supports 64-bit operating systems. Multi-core refers to multiple processor cores.

[0023] The 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.

[0024] KDUMP is a Linux kernel feature that generates a kernel crash dump file, also known as a vmcore file, when the system crashes. The vmcore file contains the memory state at the time of the crash and can be used to analyze the cause of the crash.

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

[0026] The GIC CPU interface, 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, which receives interrupt signals and determines which interrupts should be passed to the CPU core for processing.

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

[0028] 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.

[0029] The Secure World is an independent execution environment in the ARM architecture, used to run code and data that require high security. It is isolated from the Non-Secure World to prevent code in the Non-Secure World from accessing or tampering with the resources of the Secure World.

[0030] Privilege levels, also known as exception levels or execution levels, define the operations that a processor core can perform and the resources it can access in different modes. Figure 1As shown in Figure 1, in some ARM architectures (v8 and above), privilege levels are defined, from low to high, as EL0, EL1, EL2, and EL3. Each level has different permissions and uses. In ARM64 systems, the operating system kernel runs at EL1 or EL2, which are referred to as kernel privilege levels. EL3 is the highest privilege level in ARM architectures (v8 and above), typically used to perform security-sensitive operations and grant 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, one processor core can execute userspace programs at EL0, another processor core can execute system calls at EL1, and yet another processor core can execute virtual machine code at EL2.

[0031] ATF (Trusted Firmware-A (TF-A)) is firmware running at the EL3 level in ARM64, providing secure boot and runtime services. In multi-core processor systems, ATF firmware can request and respond to communications between processor cores.

[0032] The Software Delegated Exception Interface (SDEI) is a firmware-provided interface in the ARM64 architecture that allows the firmware to delegate certain exception types, such as interrupts, to the operating system kernel. The operating system kernel can register with the firmware through the SDEI interface to enable handling of specific exception events and provide a target callback function to handle these events. When a corresponding exception event occurs, the firmware switches the processor core to kernel privilege level and calls the operating system kernel to execute the target callback function to handle the specific exception event.

[0033] SDEI EVENT (Software Exception Delegate 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.

[0034] SDEI signal event 0 (SDEI_EVENT_SIGNAL 0) is a specific type of SDEI EVENT used to notify the operating system kernel of certain events or status changes.

[0035] When an exception occurs while the Linux kernel is running on an ARM64 system, the PANIC function can be called to trigger the fault event handling process. 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 ordinary IPIs, which can result in the inability to fully obtain the context data of the execution environment, affecting exception analysis. For example, when some PANIC faults occur, some processor cores cannot be interrupted by ordinary IPIs, and thus the context data of the execution environment cannot be saved.

[0036] One solution for preserving exception context is based on a pseudo non-maskable interrupt (pseudo-NMI). In this solution, the GIC CPU interface supports interrupt priority setting and interrupt priority filtering. This means that interrupts are only serviced if their priority is higher than the interrupt priority set by the GIC CPU interface. In this pseudo non-maskable interrupt solution, the interrupt priority of the IPI used for context preservation is increased, and the priority of other normal interrupts is set lower than that of the IPI interrupt. Furthermore, the interrupt filtering priority of the GIC CPU interface is set higher than that of normal interrupts but lower than that of the IPI interrupt. With this solution, the IPI interrupt used for context preservation can still interrupt other processor cores in the event of a PANIC failure, allowing all processor cores to preserve execution context information. However, this solution requires support for pseudo-NMI-related functions in the Linux kernel, which can impact Linux kernel performance in some scenarios.

[0037] Another approach for saving exception context is based on GIC-based NMIs. In this approach, if the GIC supports NMIs, the IPI can be configured as a non-maskable interrupt in the GIC. Consequently, when a PANIC occurs, any processor core can reliably notify other processor cores through the IPI to save the context. However, many GICs in ARM64 environments currently do not support NMIs.

[0038] In response to the above technical problems, the embodiments of the present application provide a solution. The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0039] Figure 2 is a flowchart of a fault handling method provided by an exemplary embodiment of the present application, which may include: Figure 2 Steps shown: Step 201: 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.

[0040] Step 202: Send an event notification signal to a target processor core through the target firmware 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.

[0041] 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 when in 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.

[0042] The execution subject of this embodiment can be a multi-core processor system, which can be a multi-core processor system based on the ARM architecture, for example, 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. The operating system kernel can be a Linux kernel.

[0043] In this embodiment, when any processor core in a multi-core processor system triggers a target fault event, it can notify the other processor cores in the multi-core processor system to perform a context save. This context save 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 experienced the target fault event can collect the execution context data saved by the other processor cores and generate a kernel crash dump file from the collected execution context data using the KDUMP function.

[0044] In this embodiment, the target fault event refers to the fault type that needs to be saved on-site for subsequent fault analysis and debugging, such as but not limited to: PANIC fault, memory error (such as memory check error, memory chip damage), software fault, security vulnerability or interrupt processing error, etc. This embodiment includes but is not limited to these.

[0045] In this embodiment, for ease of description, the processor core in a multi-core processor system where a target failure event occurs is referred to as the first processor core, and the processor core requiring context preservation is referred to as the second processor core. The terms "first" and "second" are used solely to distinguish between the different processor cores and are not intended to limit the order, location, or number of the processor cores.

[0046] Taking the target fault event as a PANIC fault as an example, when a PANIC fault occurs in the first processor core, the PANIC fault can be handled by the operating system kernel. 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. In the process of calling the panic() function, the operating system kernel can call the target firmware in the multi-core processor system to realize communication between the multi-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 processor cores or part of the processor cores in the second processor core.

[0047] 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 EL3 level shown. After the first processor core enters the privilege level of the target firmware, 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 initiates the interrupt corresponding to the event notification signal and enters the target privilege level corresponding to the target firmware.

[0048] In this embodiment, the target firmware can be any firmware running at the EL3 level, for example, the ATF firmware running at the EL3 level. Firmware running at the EL3 level has full control over hardware resources or software resources at other levels. When the target firmware runs at the EL3 level, it can handle secure 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-secure interrupts at the EL1 level or the EL2 level, and the priority of secure interrupts is higher than that of non-secure interrupts. When a target fault event occurs in the first processor core, the target firmware running at the EL3 level can use a secure interrupt processing method to send an event notification signal with a higher interrupt priority to the target processor core. In other words, the interrupt corresponding to the event notification signal issued by the target firmware has a higher priority than the interrupt managed by the operating system kernel, thereby preventing the event notification signal sent by the target firmware from being blocked by the interrupt signal managed by the operating system kernel. After receiving the event notification signal sent by the target firmware, the target processor core can enter an interrupt and switch to the target privilege level corresponding to the target firmware, namely the EL3 level.

[0049] 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, i.e., EL1 or EL2. After the target processor core enters the kernel privilege level, the target callback function corresponding to the target fault event can be executed on the target processor core.

[0050] In this step, the target callback function corresponding to the target fault event can be a predefined function that can be called by the operating system kernel. In some embodiments, when the types of fault events occurring in the processor core are different, different types of fault events can predefine different callback functions, and each callback function is used to execute the processing logic of the corresponding type of fault event. In this embodiment, the target callback function is a callback function that has a corresponding relationship with the target fault event, and is used to execute the processing logic corresponding to the target fault event. Optionally, when the target fault event is a PANIC fault 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 may include: register status, stack information, memory status, interrupt status, device status and log information. The above-mentioned execution context data can be used to generate a kernel crash dump file for analyzing the cause of the fault after the fault.

[0051] In this embodiment, 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 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 embodiment, 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. The event notification signal issued by the target firmware will not be masked by the interrupt managed by the operating system kernel, so that the event notification signal issued by the target firmware has a certain mandatory characteristic. The process of saving the execution context data before entering the interrupt will not be interfered with by the interrupt signal managed by the operating system kernel. Therefore, the saved fault scene data can be made more complete and reliable.

[0052] In some exemplary embodiments, before sending a call instruction to the target firmware via the operating system kernel, an interrupt signal managed by the operating system kernel may be sent to the second processor core in the multi-core processor system via the operating system kernel. The interrupt signal is used to notify the second processor core to enter an interrupt and save the execution context data before entering the interrupt. The second processor core may be one or more processor cores other than the first processor core in the multi-core processor system that need to be saved on-site. The interrupt signal managed by the operating system kernel may be a normal IPI or a pseudo-NMI, which is not limited in this embodiment. After sending the interrupt signal to the second processor core, the operating system kernel may wait for a response message from the second processor core.

[0053] In some embodiments, when the interrupt signal is a maskable regular IPI, this type of interrupt signal may be masked by the interrupt mask on some processor cores, resulting in failure to successfully execute the context save operation. When the interrupt signal is a pseudo-NMI, some abnormal circumstances may also cause some processor cores to fail to successfully execute the context save operation.

[0054] 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 shielded 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 message returned by some processor cores in the second processor core is not received in response to the interrupt signal, these processor cores can be used as target processor cores. Afterwards, the operating system kernel can call the target firmware to send an event notification signal to the target processor core, so as to use a higher priority interrupt method to forcibly control the target processor core to enter the interrupt process.

[0055] In this embodiment, the operating system kernel preferentially notifies the second processor core to perform on-site save through IPI or pseudo-NMI, and when some processor cores cannot successfully perform on-site save through IPI, it enables the target firmware to send an event notification signal to the target processor core to notify the target processor core to perform on-site save, so that the IPI or pseudo-NMI method can complement the on-site save method based on the target firmware and SDEI mechanism, further improving the reliability of the on-site save operation after a failure.

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

[0057] 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. Accordingly, 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 that the target fault event is a specific event registered by the target processor core according to the event information, the target firmware sends an 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. 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. 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.

[0058] Taking the target interface as SDEI as an example, in the ARM architecture, SDEI events include multiple types, among which 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 can be a target fault event on the first processor core. The operating system kernel can register the target fault event as an event of type SDEI_EVENT_SIGNAL 0 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 type SDEI_EVENT_SIGNAL 0 to the target processor core through the SDEI interface.

[0059] In this embodiment, by registering the target fault event in the target firmware, an event notification signal with a higher interrupt priority can be sent through the target firmware when the target fault event occurs, and a high priority interrupt can be achieved without modifying the hardware.

[0060] In some optional embodiments, the operating system kernel may also utilize the target interface to register a target callback function for handling a target fault event with the target firmware. This target callback function is used to execute the processing logic after the target fault event occurs. When the fault event type is different, the operating system kernel may utilize the target interface to register different programs for different types of fault events. Accordingly, after the target firmware switches the target processor core to the kernel privilege level, the target firmware may query the registered program for the target callback function corresponding to the target fault event and call the operating system kernel to execute the target callback function on the target processor core.

[0061] For example, if the target interface is SDEI and the target firmware is ATF firmware, in a multi-core processor system, the operating system kernel can use any processor core to initiate a registration request to the ATF firmware via the SDEI interface. This processor core's registration request is used to register the target fault event in the ATF firmware as a specific event of type SDEI_EVENT_SIGNAL 0. The operating system kernel can provide a target callback function for this specific event of type SDEI_EVENT_SIGNAL 0. This target callback function contains the processing logic for the specific event of type SDEI_EVENT_SIGNAL 0. When the target fault event occurs, the operating system kernel can send a call instruction to the ATF firmware. This call instruction can include the identification information of the target processor core and event information of the target fault event. Upon determining that the target fault event is a specific event of type SDEI_EVENT_SIGNAL 0, the ATF firmware can send an event notification signal to the target processor core via the SDEI interface, causing the target processor core to initiate an interrupt and switch to EL3. 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.

[0062] 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 that processor core before entering the interrupt process corresponding to the event notification signal. In this embodiment, the execution of the target callback function is not affected by the interrupt enabling and disabling at lower privilege levels managed by the operating system kernel, achieving a highly reliable context preservation solution.

[0063] In some optional embodiments, the callback function is executed in the context of the SDEI. After the callback function completes execution and is saved on-site, the ATF firmware execution status can be notified and the execution status can be returned to the designated 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, the target processor core may perform operations in an environment at 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 a specified privilege level based on the privilege level of the target processor core before entering the interrupt corresponding to the event notification signal. The specified privilege level can be the privilege level before the interrupt or another privilege level. Based on this embodiment, the interrupt initiated by the target firmware through the target interface can meet the specifications corresponding to the target interface, thereby ensuring the stability and security of the multi-core processor system.

[0064] Optionally, the target firmware may 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 may control the target processor core to enter the kernel privilege level to enter a suspended running state in the kernel privilege level. Specifically, after entering the kernel privilege level, the operating system kernel may return the target processor core from the target callback function to a specified function, which is a function that is executed 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 may 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 may 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.

[0065] In this implementation, when the callback function executes within the context of the SDEI, the callback function saves the execution status upon completion, notifies the ATF firmware of the execution status, and returns to the designated execution site. This ensures that the callback function processing process does not block the normal interrupt processing path. Immediately returning to the designated execution site after the SDEI callback completes reduces the possibility of triggering another interrupt while processing one, thereby reducing interrupt nesting and the risk of deadlock. Furthermore, this reduces the risk of multiple pending interrupts (i.e., pending interrupts), reducing the risk of certain important interrupts being indefinitely postponed, which could lead to deadlock or other unstable conditions.

[0066] It is worth noting that in some other optional embodiments of the embodiments of the present application, when a target fault event occurs in the first processor core of the 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 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. The first processor core can send an event notification signal to the target processor core according to the call instruction through the target firmware, 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.

[0067] In this embodiment, the target firmware may encapsulate processing logic related to context preservation. After the target processor core enters the interrupt corresponding to the event notification signal, the target firmware may execute a target callback function corresponding to the target fault event to preserve 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 at the target privilege level or call other modules at the kernel privilege level to execute the target callback function corresponding to the target fault event to preserve the execution context data of the target processor core before entering the interrupt corresponding to the event notification signal. This will not be further described.

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

[0069] In addition, in some of the processes described in the above embodiments and the accompanying drawings, multiple operations that appear in a specific order are included, 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 serial numbers of the operations, such as 201, 202, etc., are only used to distinguish between different operations, and the serial 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 of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0070] 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 used 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 must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0071] Figure 3 A schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present application is shown in FIG. Figure 3 As shown, the electronic device includes: a memory 301 and a processor 302. The processor 302 is a multi-core processor.

[0072] The memory 301 is used to store computer programs and can be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device.

[0073] The processor 302 is coupled to the memory 301 and is used to execute a computer program in the memory 301, so as to: when a target fault event occurs in the first processor core of 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, 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 when in 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.

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

[0075] Optionally, the processor 302 is also used to: for any processor core in the multi-core processor system, initiate a registration request to the target firmware using the target interface through the operating system kernel, wherein the registration request is used to register the target fault event as a specific event of the processor core; when the processor 302 sends an event notification signal to the target processor core through the target firmware according to the call instruction, it is specifically used to: obtain the identification information of the target processor core and the event information of the target fault event through the target firmware according to the call instruction; when it is determined that the target fault event is a specific event registered by the target processor core according to the event information, send 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.

[0076] Optionally, the processor 302 is also used to: register a target callback function for handling the target fault event to the target firmware using the target interface through the operating system kernel; when the processor 302 executes the target callback function corresponding to the target fault event, it is specifically used to: query the target callback function corresponding to the target fault event from the registered program through the target firmware; call the operating system kernel through the target interface so that the operating system kernel executes the target callback function on the target processor core.

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

[0078] Optionally, the processor 302 is also used to: after the target processor core saves the execution context data before entering the interrupt corresponding to the event notification signal, 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.

[0079] Optionally, when the processor 302 calls the target firmware to control the target processor core to enter a specified privilege level based on 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 used 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 yes, control the target processor core to enter the kernel privilege level to enter a suspended operation state in 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.

[0080] Figure 3 The electronic device shown can also be used to execute the following fault handling method, where the electronic device is a multi-core processor system, and the processor 302 is specifically used 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, 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.

[0081] Further, if Figure 3As shown, the electronic device also includes other components such as a communication component 303, a power component 304, a display component 305 and an audio component 306. Figure 3 Only some components are shown schematically, which does not mean that the electronic device only includes Figure 3 Components shown. Figure 3 Components in the dotted box are optional components, not mandatory components, and may depend on the product form of the electronic device. The electronic device of 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 a server device such as a conventional server, a cloud server or a server array. If the electronic device of this embodiment is implemented as a terminal device such as a desktop computer, a laptop computer, a smart phone, etc., it may include Figure 3 If the electronic device of this embodiment is implemented as a conventional server, cloud server or server array and other server-side devices, it may not include Figure 3 Components within the dotted box.

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

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

[0084] The power supply component 304 is used to provide power to 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 to the device where the power supply component is located.

[0085] The display assembly includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, it may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can detect not only the boundaries of a touch or slide action, but also the duration and pressure associated with the touch or slide action.

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

[0087] In this embodiment, when a target fault event occurs in a processor core in a multi-core processor system, the operating system kernel may 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 kernel mode, the target callback function corresponding to the target fault event may be executed on the target processor core to save the execution context data of the target processor core before entering the interrupt. In this embodiment, 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. The event notification signal issued by the target firmware will not be masked by the interrupt managed by the operating system kernel, so that the event notification signal issued by the target firmware has a certain mandatory characteristic. The process of saving the execution context data before entering the interrupt will not be interfered with by the interrupt signal managed by the operating system kernel. In addition, the saved fault scene data can be made more complete and reliable.

[0088] Accordingly, embodiments of the present application further provide a computer-readable storage medium storing a computer program. When executed, the computer program can implement the steps that can be performed by the electronic device in the above-mentioned method embodiments. The computer-readable storage medium may be volatile or non-volatile, or a combination thereof, and may 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 technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, tape, disk storage or other magnetic storage devices, or any other non-transmission medium.

[0089] Accordingly, an embodiment of the present application further provides a computer program product, which includes a computer program or instructions, and when the computer program or instructions are executed by a processor, the processor is enabled to implement the steps in the above-mentioned method embodiment. It should be understood that each process or a combination of multiple processes in the above-mentioned method flow can be implemented by a computer program or instruction. In addition, these computer programs or instructions can be applied to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device, so that the processor of the general-purpose computer, the special-purpose computer, the embedded processor or other programmable data processing device can be implemented as a device for implementing the corresponding functions in the above-mentioned method embodiment.

[0090] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0091] The above are merely embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all 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; By means of the target firmware, an event notification signal is sent 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, the target firmware is run to switch from the target privilege level to the kernel privilege level, 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.

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 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.

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