Apparatus, method, medium, and electronic device supporting interrupt handling

Abstract

Embodiments of the present disclosure relate to an apparatus, a method, a medium and an electronic device supporting interrupt processing. The apparatus supporting interrupt processing comprises a memory; and a first processor core electrically connected with the memory, the first processor core being configured to: acquire a target exception event for the first processor core by using a software delegated exception interface (SDEI) event processing module; write a target event identifier of the target exception event into a first storage area corresponding to the first processor core in the memory by using the SDEI event processing module; determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling an interrupt request simulator; and in response to the target event identifier not belonging to the predetermined identifier, determine a first target interrupt identifier corresponding to the target event identifier based on the target event identifier and a preset mapping relationship by using the interrupt request simulator. In this way, different types of interrupts corresponding to different event identifiers can be processed, and the interrupt processing capability is improved.

Description

Technical Field

[0001] This disclosure relates to the field of chip technology, and more particularly to apparatus, methods, media, and electronic devices that support interrupt handling. Background Technology

[0002] Interrupt handling is a crucial mechanism in chip processing. When the processor in a chip is executing the currently running program, if it receives an urgent exception event (such as a power failure or data transmission completion) that triggers an interrupt, the processor will pause the execution of the current software program to handle the exception event. After the exception event is handled, the paused software program will resume execution. This interrupt handling mechanism allows the processor to execute the main program when there are no urgent events and to quickly respond to and handle the corresponding exception events when interrupts occur. However, as chips implement more and more functions, the types of interrupt sources also increase. Existing interrupt handling mechanisms struggle to handle different types of interrupts while maintaining interrupt handling efficiency. Summary of the Invention

[0003] Embodiments of this disclosure provide apparatus, methods, media, and electronic devices for supporting interrupt handling.

[0004] According to a first aspect of this disclosure, an apparatus supporting interrupt handling is provided. The apparatus includes a memory; and a first processor core electrically connected to the memory, the first processor core being configured to: acquire a target exception event for the first processor core using a Software Delegated Exception Interface (SDEI) event handling module; wherein the target exception event is generated via SDEI; write a target event identifier of the target exception event into a first storage area in the memory corresponding to the first processor core using the SDEI event handling module; determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier by invoking an interrupt request simulator; in response to the target event identifier not belonging to the predetermined identifier, determine a first target interrupt identifier corresponding to the target event identifier based on the target event identifier and a preset mapping relationship using the interrupt request simulator, wherein the preset mapping relationship represents a mapping relationship between event identifiers and interrupt identifiers; and invoke an interrupt handling function corresponding to the first target interrupt identifier using the interrupt request simulator to process a first interrupt corresponding to the first target interrupt identifier.

[0005] According to a second aspect of this disclosure, an interrupt handling method is provided. The method includes: acquiring a target exception event for a first processor core using a Software Delegated Exception Interface (SDEI) event handling module; wherein the target exception event is generated via SDEI; writing a target event identifier of the target exception event into a first storage area in memory corresponding to the first processor core using the SDEI event handling module; determining whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling an interrupt request simulator; in response to the target event identifier not belonging to the predetermined identifier, determining a first target interrupt identifier corresponding to the target event identifier based on the target event identifier and a preset mapping relationship using the interrupt request simulator, wherein the preset mapping relationship represents a mapping relationship between event identifiers and interrupt identifiers; and calling an interrupt handling function corresponding to the first target interrupt identifier through the interrupt request simulator to process a first interrupt corresponding to the first target interrupt identifier.

[0006] According to a third aspect of this disclosure, an apparatus supporting interrupt handling is provided. The apparatus includes a target exception event acquisition unit configured to acquire a target exception event for a first processor core using a Software Delegated Exception Interface (SDEI) event handling module; wherein the target exception event is generated via SDEI; a target event identifier writing unit configured to write a target event identifier of the target exception event into a first storage area in memory corresponding to the first processor core using the SDEI event handling module; an identifier determination unit configured to determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling an interrupt request simulator; an interrupt identifier determination unit configured to, in response to the target event identifier not belonging to the predetermined identifier, determine a first target interrupt identifier corresponding to the target event identifier based on the target event identifier and a preset mapping relationship using the interrupt request simulator, wherein the preset mapping relationship represents a mapping relationship between event identifiers and interrupt identifiers; and a processing function invocation unit configured to call an interrupt handling function corresponding to the first target interrupt identifier through the interrupt request simulator to process a first interrupt corresponding to the first target interrupt identifier.

[0007] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program that, when executed by a processor, implements the processing interrupt method according to a second aspect of this disclosure.

[0008] According to a fifth aspect of this disclosure, an electronic device is provided. The electronic device includes: a processor; a memory for storing computer-executable instructions; the processor being configured to read the computer-executable instructions from the memory and execute the computer-executable instructions to implement the processing interrupt method according to a second aspect of this disclosure.

[0009] According to a sixth aspect of this disclosure, a machine program product is provided. The machine program product includes computer-executable instructions, wherein the computer-executable instructions are executed by a processor to implement the steps of the processing interrupt method in a second aspect of this disclosure.

[0010] In this embodiment, a software delegated exception interface (SDEI) event handling module is used to obtain a target exception event for the first processor core. The SDEI event handling module writes a target event identifier of the target exception event into a first storage area in memory corresponding to the first processor core. An interrupt request simulator determines whether the target event identifier belongs to a predetermined identifier. If the target event identifier does not belong to a predetermined identifier, a first interrupt identifier is determined according to a pre-established mapping relationship between event identifiers and interrupt identifiers. Then, an interrupt handling function corresponding to the first interrupt identifier is obtained, and the interrupt request simulator uses the obtained interrupt handling function to process the first interrupt corresponding to the first interrupt identifier. This disclosure enables the first processor core to handle multiple types of interrupts corresponding to event identifiers, increasing the number and types of interrupts that can be handled, while also improving interrupt handling efficiency. Attached Figure Description

[0011] Figure 1 A schematic diagram of the first interrupt handling architecture in the relevant scheme is shown;

[0012] Figure 2 A schematic diagram of the second interrupt handling architecture in the relevant scheme is shown;

[0013] Figure 3 A schematic diagram of the structure of an apparatus supporting interrupt handling provided in this disclosure is shown;

[0014] Figure 4 A schematic diagram of an interrupt handling architecture provided in this disclosure is shown;

[0015] Figure 5 A flowchart of a method for supporting interrupt handling provided in this disclosure is shown;

[0016] Figure 6 A flowchart of a method for writing a target event identifier provided in this disclosure is shown;

[0017] Figure 7A flowchart illustrating an exemplary method for performing an operation corresponding to a first task, as provided in this disclosure, is shown.

[0018] Figure 8 A flowchart illustrating an exemplary method for processing target event identifiers using an interrupt request simulator provided in this disclosure is shown.

[0019] Figure 9 A flowchart of an exemplary interrupt handling method provided in this disclosure is shown;

[0020] Figure 10 A flowchart illustrating an exemplary method for switching exception levels provided in this disclosure is shown.

[0021] Figure 11 A flowchart illustrating an exemplary SDEI event handling module provided in this disclosure is shown;

[0022] Figure 12 A flowchart illustrating an exemplary SDEI interrupt request simulator provided in this disclosure is shown;

[0023] Figure 13 A flowchart of an exemplary task switching method provided in this disclosure is shown;

[0024] Figure 14 A schematic diagram of an exemplary apparatus for interrupt handling provided in this disclosure is shown;

[0025] Figure 15 A schematic diagram of the structure of an exemplary device provided in this disclosure is shown.

[0026] In the various figures, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0027] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0028] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0029] Application Overview

[0030] In Reduced Instruction Set Computing (RISC) machine architectures, there exists the concept of privilege levels. These levels primarily employ hardware-enforced hierarchical access control to isolate access permissions between different software modules, thereby achieving system security, stability, and virtualization support. These privilege levels are called exception levels (EL), and they represent the logical division of privilege levels at which a program runs. Exception levels are classified into four types, with higher level numbers indicating higher privileges.

[0031] EL0: Typically used for running user programs, with the lowest privilege level. Programs running in EL0 cannot directly access restricted resources; if they need system services, they must use system calls to enter a higher privilege level.

[0032] EL1: Primarily used to run the operating system kernel, responsible for memory management, process scheduling, device drivers, etc.; in non-virtualized systems, EL1 is the highest privilege level resident in the operating system kernel.

[0033] EL2: Primarily used to run the hypervisor, responsible for managing virtual machines (Guest OS). When the system needs to support virtualization, EL2 allows multiple operating systems to run on a single physical machine. For certain real-time embedded systems, EL2 is often optional.

[0034] EL3: Primarily used to run secure firmware, trusted execution environments (TEEs), or security monitoring programs, including Secure Monitor and BL3 (such as the BL3 stage in ARM Trusted Firmware), providing the highest privilege level; and can also be used to handle the switching between the Secure World and the Normal World (via TrustZone technology).

[0035] In Advanced Reduced Instruction Set Computing (ELS) machine architectures, Stage 1 and Stage 2 are two-level address translation mechanisms that work in tandem under virtualization. When virtualization is disabled, the system only uses Stage 1 to complete the translation from virtual address (VA) to physical address (PA). When exception level EL2 virtualization is enabled, the system completes the full address translation through the two-level linkage. Stage 1 is managed by the guest operating system running at exception level EL1. Relying on dedicated page tables and control registers, it is responsible for translating the virtual address (VA) used by the program into an intermediate physical address (IPA). Its main functions are to achieve process address space isolation, distinguish between user-mode and kernel-mode memory, and configure basic memory access permissions and cache attributes. It is the core of virtual memory management in the operating system. The operating system inside the virtual machine treats the intermediate physical address (IPA) as its own physical address, completely shielding the underlying hardware layout. Stage 2 is managed by the hypervisor at exception level EL2. It uses an independent two-level page table system and is responsible for translating the intermediate physical address (IPA) from the guest operating system into the actual physical address (PA) corresponding to the hardware.

[0036] Furthermore, in RISC-based machine architectures, Interrupt Requests (IRQs) and Fast Interrupt Requests (FIQs) are two different types of asynchronous interrupts used to respond to external events. FIQ interrupts have a higher priority than IRQs and respond faster. Additionally, RISC-based machine architectures also include a Software Delegated Exception Interface (SDEI), a specification that allows operating system software in the non-secure world to register handlers to receive system event notifications from the underlying firmware (e.g., BL31).

[0037] As mentioned earlier, interrupt handling is a critical processing mechanism in a chip. The first interrupt from outside the processor core (also known as an external interrupt, which may include a physical interrupt) is typically managed by a generic interrupt controller (GIC). In virtualization scenarios that include virtual machines, the GIC can implement interrupt virtualization, thereby providing interrupts to virtual machines. However, due to the limitations of the virtualization extensions provided by the GIC, the interrupt injection process requires the participation of a hypervisor in the implementation of interrupt virtualization. For example, in a processor architecture that includes a GIC, the hypervisor is needed to handle interrupts. The hypervisor is a software, firmware, or hardware that allows multiple virtual machines (VMs) to run on the same chip. The hypervisor can receive interrupts and, in conjunction with the GIC, inject them into the virtual machines.

[0038] See Figure 1 The diagram illustrates the first interrupt handling architecture. A general-purpose interrupt controller 106 receives a first interrupt from outside the processor core. Due to virtualization limitations of the general-purpose interrupt controller 106, the first interrupt for virtual machine 102 cannot be directly configured and injected into the virtual machine. Instead, the general-purpose interrupt controller 106 sends the first interrupt to the virtual interrupt management module in the virtual machine manager 104, providing the first interrupt for that virtual machine to the virtual central processing unit (VCPU) interface (not shown) for further provision to virtual machine 102. Additionally, the virtual machine manager also needs to handle a second interrupt besides the first interrupt (e.g., an inter-processor interrupt (IPI)). For example, processor core CPUm can send a second interrupt to processor core CPUn based on the context information of processor core CPUm. The general-purpose interrupt controller 106 can then send the second interrupt to processor core CPUn to utilize the context information of processor core CPUn for interrupt handling. The second interrupt can also be called a Software Generated Interrupt (SGI) or SGI interrupt, and may further include inter-processor interrupts (i.e., IPI interrupts).

[0039] See also Figure 1The reason why the first interrupt for a virtual machine needs to be sent to the virtual machine manager is that the first interrupt needs to be routed to exception level EL2. The virtual machine (VM) runs at exception level EL0 or EL1, while the virtual machine manager runs at exception level EL2. This causes the first interrupt to switch between different exception levels during transmission. Furthermore, the interrupt routing policy supports two configuration modes: one is to set the interrupt to be handled at exception level EL1, and the other is to set the interrupt to be handled at exception level EL2. It is important to note that the interrupt routing policy is a global setting for all interrupts and cannot be differentiated for specific interrupts. For example, it is not possible to make interrupt 1 handled at exception level EL1 and interrupt 2 handled at exception level EL2. Therefore, if the following is adopted... Figure 1 The method of handling interrupts in the traditional way can lead to a significant increase in interrupt latency, which in turn affects the efficiency of interrupt handling, because the virtual machine manager needs to participate in the interrupt injection process.

[0040] To address the high interrupt latency issue, the relevant technical solutions employ the following optimization measures: Firstly, the interrupt routing configuration is optimized, allocating interrupt requests (IRQs) to exception level EL1 for processing and fast interrupt requests (FIQs) to exception level EL3 for processing. Secondly, the virtual machine interrupt handling logic is adjusted; exception level EL1 no longer handles virtual interrupts but directly handles the aforementioned first interrupt. In this configuration mode, the VCPU interface corresponding to the Generic Interrupt Controller (GIC) cannot generate interrupts; instead, it needs to configure a software delegated exception interface (SDEI) and use the default event flag EVENT_0 to simulate the interrupts required by the virtual machine manager. Furthermore, the registration of the processing function corresponding to EVENT_0 must be completed. Once all first interrupts are routed to virtual machines running at exception level EL1, the interrupts required by the corresponding virtual machine manager will be simulated through the SDEI.

[0041] Further integration Figure 2The exemplary second interrupt (which may include an IPI interrupt) handling architecture shown in example architecture 200 involves the first interrupt being input to a general interrupt controller 206. The general interrupt controller 206 provides the first interrupt to the virtual machine 202 via the CPU interface, where the virtual machine performs the corresponding interrupt handling. Furthermore, for the aforementioned second interrupt, the virtual machine manager 204 sends an exception event (i.e., an SDEI event) to the SDEI in the boot loader stage (BL31) 208. The SDEI provides the exception event to the SDEI event handling module for preprocessing. Upon receiving the exception event, the SDEI event handling module performs a trap operation on the virtual machine, causing it to stop running. After the SDEI event handling module completes its preprocessing, it resumes the virtual machine's operation and then further calls the SDEI interrupt request simulator to handle the corresponding interrupt function. In this process, the SDEI configuration management module is responsible for the initialization of SDEI, that is, registering the EVENT_0 processing function with SDEI using EVENT_0, so that the virtual machine manager and SDEI can subsequently simulate a second interrupt through EVENT_0.

[0042] In the aforementioned technical solutions, the virtual machine manager has no tasks and does not support scheduling. Therefore, the virtual machine manager does not need to handle the first interrupt from the outside. The interrupts that the virtual machine manager needs to handle generally only involve the second interrupt. Therefore, this technical solution has the following problem: it only simulates one second interrupt and does not simulate other interrupts. For example, in some cases, it is impossible to schedule the first interrupt generated by the timer through the virtual machine manager; in other cases, it is impossible to manage the first interrupt generated by the peripheral driver through the virtual machine manager. Therefore, this method cannot meet the virtual machine manager's requirement for handling the first interrupt from the outside.

[0043] To address the aforementioned technical problems, embodiments of this disclosure provide an apparatus for supporting interrupt handling. The apparatus includes: a memory; and a first processor core electrically connected to the memory. The first processor core can utilize an SDEI event processing module to obtain a target exception event for the first processor core; wherein the target exception event is generated via SDEI. The first processor core further utilizes the SDEI event processing module to write a target event identifier of the target exception event into a first storage area in the memory corresponding to the first processor core. Additionally, the first processor core can determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling an interrupt request simulator. If the target event identifier does not belong to a predetermined identifier, the first processor core, through the interrupt request simulator, determines a first target interrupt identifier corresponding to the target event identifier based on a preset mapping relationship between the target event identifier and the interrupt identifier, wherein the preset mapping relationship represents the mapping relationship between event identifiers and interrupt identifiers. Finally, the first processor core, through the interrupt request simulator, calls an interrupt handling function corresponding to the first target interrupt identifier to process the first interrupt corresponding to the first target interrupt identifier. In the above manner, the SDEI event handling module can be used to obtain the target abnormal event and store the corresponding event identifier. Then, the interrupt request simulator can be used to find the corresponding interrupt handling function based on the event identifier. This allows the first processor core to handle multiple types of interrupts corresponding to the event identifier in the virtual machine manager, increasing the number and types of interrupts that can be handled, while also improving interrupt handling efficiency.

[0044] Exemplary device

[0045] The embodiments of this disclosure will now be described in further detail with reference to the accompanying drawings, wherein... Figure 3 A schematic diagram of a device supporting interrupt handling provided in this disclosure is shown. The device provided in this embodiment is applied to, for example but not limited to, a processor, an electronic device, or a System on Chip (SoC). The processor may include, for example, a central processing unit; the electronic device may include, for example, an in-vehicle computing platform or a general-purpose computing platform; and the SoC may include, for example, an intelligent driving SoC, an intelligent cockpit SoC, or a multimedia SoC.

[0046] like Figure 3As shown, the interrupt handling device 300 includes a memory 302. The memory 302 can be a shared memory among multiple processor cores in the device 300, storing information specific to each processor core. In one example, the memory can be internal memory within the device 300, such as random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (DRAM), etc. In some examples, multiple storage regions can be allocated within the memory for each processor core to store information required by each processor core when handling interrupts. In one example, the memory 302 within the device 300 includes a single memory, and the storage regions for multiple processor cores can be allocated within that single memory. In another example, the memory 302 within the device 300 includes multiple memories, and the storage regions for multiple processor cores can be allocated across multiple memories. In yet another example, a first storage region can be allocated for each processor core to store the target event identifier of the target exception event to be processed by that processor core. Additionally, separate storage areas can be allocated to each processor core to store information specific to that processor core during anomaly level switching. The above examples are merely illustrative of this disclosure and not intended to limit its scope. Those skilled in the art can configure storage areas in memory for multiple processor cores as needed.

[0047] like Figure 3 As shown, the device 300 includes a first processor core 304. The first processor core 304 can be used to handle various interrupts for the processor core. Figure 3 The illustration of a single processor core 304 is merely illustrative and not intended to limit the scope of this disclosure. The processor in device 300 may include multiple processor cores, with the first processor core 304 being one of these cores. The device 300 provided in this disclosure includes a hypervisor that can run on an on-chip system or processor. For each processor core, the hypervisor can allocate an SDEI event handling module (also known as a software delegated exception interface event handling module) and an interrupt request simulator to each processor core, thereby enabling the corresponding processor core to perform corresponding interrupt handling operations.

[0048] The first processor core is configured to: acquire a target exception event for the first processor core using an SDEI event processing module; wherein the target exception event is generated by SDEI; write a target event identifier of the target exception event into a first storage area in memory corresponding to the first processor core using the SDEI event processing module; determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling an interrupt request simulator; in response that the target event identifier does not belong to a predetermined identifier, determine a first target interrupt identifier corresponding to the target event identifier based on the target event identifier and a preset mapping relationship using an interrupt request simulator, wherein the preset mapping relationship represents the mapping relationship between event identifiers and interrupt identifiers; and call the interrupt handling function corresponding to the first target interrupt identifier using an interrupt request simulator to process the first interrupt corresponding to the first target interrupt identifier.

[0049] In some embodiments, the first interrupt processed by the first processor core may also be referred to as an external interrupt, indicating an interrupt from outside the first processor core. The first interrupt may include physical interrupts, specifically including interrupts generated by timers or interrupts generated by drivers corresponding to external devices.

[0050] The target exception event processed by the first processor core 304 can be generated by a first interrupt or a second interrupt targeting the first processor core. In some embodiments, the first interrupt targeting the first processor core can be received by a general interrupt controller within the processor or on-chip system, which can receive the first interrupt corresponding to each of the multiple processor cores. Further, in the interrupt routing configuration, a routing strategy can be configured based on the type of the first interrupt and / or the second interrupt, such as interrupt request (IRQ) and fast interrupt request (FIQ). For the first interrupt and / or the second interrupt belonging to the fast interrupt request type, a target exception event can be formed targeting the first processor core. For example, a software delegated exception interface can be used to convert the received first interrupt and / or the second interrupt into a corresponding target exception event. The target exception event is, for example, but not limited to, an SDEI event. After generating the target exception event based on the first interrupt and / or the second interrupt, the software delegated exception interface provides the target exception event to the first processor core, where the SDEI event processing module and the interrupt request simulator are used to process the target exception event. First, the SDEI event processing module performs preprocessing on the target abnormal event. Specifically, it can obtain the target abnormal event for the first processor core and identify that the first processor core has a target abnormal event to be processed. For example, it sets corresponding information bits in memory to indicate that the first processor core has a target abnormal event to be processed. Second, the SDEI event processing module also needs to determine a first storage area in memory for the first processor core. This first storage area is pre-allocated to the first processor core, for example, it has been allocated to the first processor core during device startup to store the target event identifier corresponding to the target abnormal event for that first processor core. The SDEI event processing module then writes the target event identifier corresponding to the target abnormal event into the first storage area in memory corresponding to the first processor core.

[0051] After completing the above preprocessing, the interrupt handling task is executed through the interrupt request simulator. For example, the interrupt request simulator can obtain the target event identifier corresponding to the target exception event stored in the first storage area. For example, it can obtain EVENT_0, EVENT_1, or other event identifiers EVENT_k stored in the first storage area, where k can be a non-zero positive integer. The interrupt request simulator further determines whether the target event identifier stored in the first storage area is a predetermined identifier, in order to determine whether the interrupt corresponding to the target event belongs to a predetermined interrupt. For example, if the predetermined identifier is EVENT_0, then EVENT_0 indicates that the corresponding interrupt belongs to a predetermined interrupt (such as the second interrupt); or, if EVENT_1 or EVENT_k belongs to other types of event identifiers, then it indicates that the corresponding interrupt does not belong to a predetermined interrupt, and this non-predetermined interrupt may be the first interrupt. If it is determined that the target event identifier does not belong to a predetermined identifier, it indicates that the interrupt corresponding to the target event identifier is the first interrupt, and the interrupt identifier corresponding to the target event identifier can be found from the pre-stored preset mapping relationship. The preset mapping relationship represents the mapping relationship between event identifiers and interrupt identifiers. To increase the types of first interrupts that can be handled, a pre-defined mapping between interrupt identifiers and event identifiers for different types of first interrupts can be established. For example, the first type of first interrupt corresponds to EVENT_1, the second type of first interrupt corresponds to EVENT_2, and so on. Therefore, the interrupt request simulator can determine the first interrupt identifier corresponding to the target event identifier based on the pre-defined mapping. After finding the first interrupt identifier, the interrupt handling function corresponding to the first interrupt identifier is obtained, and the interrupt request simulator uses the obtained interrupt handling function to process the first interrupt corresponding to the first interrupt identifier.

[0052] In this embodiment, a software delegated exception interface (SDEI) event handling module is used to obtain a target exception event for a first processor core. The SDEI event handling module writes the target event identifier of the target exception event into a first storage area in memory corresponding to the first processor core. By associating interrupt identifiers corresponding to different types of interrupts with event identifiers corresponding to different exception events, the interrupt request simulator can determine whether the target event identifier belongs to a predetermined identifier. If the target event identifier does not belong to a predetermined identifier, a first interrupt identifier is determined based on a pre-established mapping relationship between event identifiers and interrupt identifiers. Then, the interrupt handling function corresponding to the first interrupt identifier is obtained. The interrupt request simulator uses the obtained interrupt handling function to process the first interrupt corresponding to the first interrupt identifier, thereby achieving the processing of multiple types of first interrupts. This scheme not only improves the efficiency of interrupt processing but also enriches the types of interrupt processing.

[0053] In some embodiments, the above-described method of using the SDEI event processing module to write the target event identifier of the target abnormal event into the first storage area corresponding to the first processor core in the memory specifically includes: using the SDEI event processing module to obtain the target event identifier included in the target abnormal event; and using the SDEI event processing module to store the target event identifier in the first storage area corresponding to the first processor core.

[0054] For example, after obtaining the target exception event, the SDEI event handling module can obtain the target event identifier from the information included in the target exception event. For example, the target event identifier may be represented as EVENT_0, EVENT_1, or any other suitable event identifier, as well as information such as the processor core that can handle the target exception event.

[0055] Additionally, the SDEI configuration management module can pre-allocate a first storage area in memory for each processor core to store event identifiers. Therefore, the SDEI event processing module can determine the first storage area in memory for storing event identifiers for the first processor core, and store the target event identifier in this first storage area. For example, if the SDEI event processing module receives an SDEI event corresponding to a second interrupt, it can store the event identifier EVENT_0 corresponding to the second interrupt in the first storage area; if the SDEI event processing module receives an SDEI event corresponding to a first interrupt, it can store the event identifier EVENT_1 or EVENT_k corresponding to the first interrupt in the first storage area. Therefore, the first storage area corresponding to the first processor core can store event identifiers corresponding to various types of pending exception events related to the first processor core. Similarly, for other processor cores within the device 300, there are also corresponding other storage areas to store the event identifiers corresponding to pending exception events for each of the other processor cores, which will not be elaborated upon in this disclosure.

[0056] The SDEI event processing module stores the target event identifier from the target abnormal event in the first storage area, enabling rapid saving of the target abnormal event identifier and providing information support for subsequent identification of the target abnormal event. Furthermore, it can provide an abnormal event information source for subsequent interrupt handling, allowing for quick determination of the corresponding interrupt type using the event identifier, thus improving interrupt handling efficiency.

[0057] In some embodiments, before writing the target event identifier of the target abnormal event into the first storage area corresponding to the first processor core in the memory using the SDEI event processing module, the first processor core is further configured to: store an indication identifier indicating the existence of an abnormal event in the storage unit corresponding to the first processor core using the SDEI event processing module; determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator, specifically including: determining whether an indication identifier exists in the storage unit using the interrupt request simulator; in response to the existence of an indication identifier in the storage unit, reading the target event identifier corresponding to the target abnormal event from the first storage area; and determining whether the target event identifier belongs to a predetermined identifier.

[0058] For example, after the SDEI event processing module obtains the target exception event, it marks the first processor core to set an indicator. This indicator indicates whether the first processor core has a target exception event to be processed. For instance, an indicator of 0 indicates that the first processor core does not have a target exception event to be processed, and an indicator of 1 indicates that the first processor core has a target exception event to be processed. In an optional approach, an indicator table can be set in the memory for multiple processor cores, with each processor core corresponding to an entry in the indicator table. By setting the indicator in the corresponding entry, it is indicated whether each processor core has a corresponding event to be processed. After setting the indicator for the first processor core, the SDEI event processing module can write the target event identifier of the target exception event into the first storage area in the memory corresponding to the first processor core.

[0059] When the interrupt request simulator is called to process the first processor core, the indicator can be read from the corresponding storage unit first. If it is determined that the indicator in the storage unit indicates that the first processor core stores the target abnormal event to be processed, the interrupt request simulator can read the target event identifier corresponding to the target abnormal event from the first storage area. Then, the interrupt request simulator can continue to determine whether the target event identifier belongs to the predetermined identifier.

[0060] By storing corresponding indicator flags in the memory unit corresponding to the first processing core to indicate whether there is an abnormal event to be processed in the first processor core, it is possible to identify in advance whether there is a target abnormal event for the first processor core. This allows the interrupt request simulator to promptly determine whether the target event flag corresponding to the target abnormal event belongs to the predetermined flag, further improving the efficiency of interrupt handling.

[0061] In related technical solutions, the virtual machine manager can use the SDEI event handling module to handle abnormal events. During this process, the virtual machine manager modifies the Stage2 page table configuration to cause the virtual machine to generate an abnormal event when it resumes runtime, thus causing it to re-enter the virtual machine manager to call the interrupt request simulator for interrupt handling. However, this technical solution is not suitable for microkernel-based interrupt handling mechanisms because microkernels have idle tasks (also known as IDLE tasks). When the processor is idle, the IDLE task will run. The memory address space of the IDLE task is not simulated based on Stage2. Therefore, if the SDEI processing module handles the IDLE task, it will not trigger an abnormal event, causing subsequent processes to fail and resulting in the loss of the corresponding interrupt.

[0062] In order to avoid the above problems in a microkernel environment, during the execution of the pre-defined operation corresponding to the task, the SDEI event handling module can first determine the type of the task, and then perform the corresponding operation using the SDEI event handling module according to the type of the task.

[0063] In some embodiments, before determining whether a target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator, the first processor core is further configured to: determine the type of a first task running on the first processor core using the SDEI event processing module; and, based on the type of the first task running on the first processor core, perform an operation corresponding to the first task using the SDEI event processing module.

[0064] For example, after the SDEI event handling module stores the event identifier in the first storage area for the first processor core, it also needs to further determine what type of task is running on the first processor core when it receives the target exception event. For example, in a microkernel scenario, the first processor core can run a virtual machine (VM) or an idle task. The subsequent process of the first processor core calling the interrupt request simulator differs depending on the type of task. Therefore, the SDEI event handling module needs to determine the type of the first task running on the first processor core and then perform different processing operations based on the different task types.

[0065] For example, if it is determined that the type of the first task running on the first processor core is a virtual machine task, the corresponding operation can be to call the interrupt request simulator by modifying the Stage2 page table configuration information; if it is determined that the type of the first task running on the first processor core is an idle task, since it does not use the Stage2 page table configuration information, it cannot use the Stage2 page table configuration information to call the interrupt request simulator, so the corresponding operation can be to directly use the idle task to call the interrupt request simulator.

[0066] This disclosure performs corresponding operations by distinguishing task types, which can accurately execute corresponding interrupt handling operations based on task types, improving the comprehensiveness and accuracy of interrupt handling, and also improving the specific operation methods of different types of tasks in microkernel scenarios.

[0067] In some embodiments, the SDEI event handling module and the interrupt request simulator operate at a second exception level. Based on the type of the first task running on the first processor core, the SDEI event handling module performs an operation corresponding to the first task, specifically including: in response to the first task not being an idle task, modifying the first page table configuration information in the first register using the SDEI event handling module to obtain the modified second page table configuration information; executing a first exception return instruction using the SDEI event handling module to switch from the second exception level to running the virtual machine in the first exception level; in response to detecting an error in the second page table configuration information of the first task during the operation of the virtual machine, switching from the first exception level to the second exception level; the aforementioned determination of whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator further includes: calling the interrupt request simulator using the first exception handler in the second exception level; and determining whether the target event identifier stored in the first storage area belongs to a predetermined identifier using the interrupt request simulator.

[0068] For example, in the apparatus disclosed herein, there are different exception levels. During the handling of exception events, it is necessary to switch between different exception levels. Therefore, when handling different types of tasks, the corresponding exception level switching methods will also be different. If the type of the first task running in the first processor core is not a non-idle task, it can be determined that the first processor core received a corresponding interrupt when running a virtual machine (VM). The SDEI event handling module can first obtain the first page table configuration information corresponding to the virtual machine (VM) stored in the register, and modify the first page table configuration information to generate the modified second page table configuration information. For example, the first page table configuration information can be the initial Stage2 page table configuration information, and the second page table configuration information can be the modified Stage2 page table configuration information. Furthermore, in the method of handling interrupts using the Stage2 page table configuration information, it is usually necessary to modify the initial Stage2 page table configuration information when an abnormal event is received. The modification method may include changing some predetermined information in the initial Stage2 page table configuration information to error information, such as modifying the access permission bits, memory attribute fields, etc. in the predetermined information. After completing the above modification of the initial Stage2 page table configuration information, the first processor core can re-enter the virtual machine manager according to the modified Stage2 page table configuration information during the virtual machine operation recovery process, and then perform subsequent interrupt handling.

[0069] After completing the above operations, the SDEI event handling module executes the first exception return instruction. Through the first exception return instruction, it switches from the second exception level EL2 back to the first exception level EL1 where the virtual machine is running. The virtual machine continues to run in the first exception level EL1. Since the second page table configuration information has been modified, the accessed memory address may encounter situations such as Stage2 translation errors, triggering a Stage2 memory page fault or a permission failure. This will passively trigger the virtual machine to exit, causing the first processor core to switch from the first exception level EL1 back to the second exception level EL2 to run the exception handler and call the interrupt request simulator for further exception handling.

[0070] In the subsequent process of determining whether the target event identifier stored in the first storage area belongs to the predetermined identifier by calling the interrupt request simulator, the first processor core can use the first exception handler to call the interrupt request simulator in the second exception level environment, and use the interrupt request simulator to determine whether the target event identifier stored in the first storage area belongs to the predetermined identifier.

[0071] By modifying the page table configuration information, the first processor core can be restored to virtual machine runtime. The error can be corrected according to the corresponding configuration information to switch between different exception levels. Thus, interrupt processing can continue in the second exception level after the switch, thereby improving the speed and efficiency of interrupt processing.

[0072] In some embodiments, before modifying the first page table configuration information in the register using the SDEI event handling module as described above, the first processor core is further configured to: read the first page table configuration information from the register; write the read first page table configuration information into memory; after calling the interrupt handling function corresponding to the first target interrupt identifier through the interrupt request simulator as described above to process the first interrupt corresponding to the first target interrupt identifier, the first processor core is further configured to: read the first page table configuration information from memory; update the second page table configuration information in the register using the read first page table configuration information.

[0073] For example, when the SDEI event handling module is invoked, to ensure the correct recovery of the virtual machine's operation later, before modifying the first page table configuration information in the register through the SDEI event handling module, the first page table configuration information is stored in a memory area designated for the first processor core. This facilitates the subsequent recovery of the virtual machine. For instance, the unmodified first page table configuration information is first read from the register and written into memory. This memory has a pre-allocated memory area for the first processor core to store the first page table configuration information. After subsequent interrupt handling is completed, the interrupt request simulator running in the first processor reads the first page table configuration information from memory and overwrites it into the register, thereby completing the recovery of the virtual machine.

[0074] By saving the correct first page table configuration information before modifying it, and then using this correct first page table configuration information to restore the virtual machine's operation after the interrupt handling is completed, the normal recovery of the virtual machine can be guaranteed, and the efficiency of interrupt handling can also be improved.

[0075] In some embodiments, the above-mentioned operation corresponding to the first task based on the type of the first task running in the first processor core, performed by the SDEI event processing module, further includes: determining whether the first processor core meets a predetermined power consumption condition in response to the first task being an idle task; and directly running the first task in response to the first processor core not meeting the predetermined power consumption condition; the above-mentioned determination of whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator further includes: calling the interrupt request simulator using the first task to determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier through the interrupt request simulator.

[0076] For example, the idle task running in the first processor core does not process the first page table configuration information (i.e., the Stage 2 page table configuration information). Therefore, it is impossible to call the interrupt request simulator by modifying the Stage 2 page table configuration information when the idle task is running. In order to enable the interrupt request simulator to be called when an interrupt occurs while the idle task is running, the idle task has been improved in this disclosure to enable the interrupt request simulator to be called. For example, the code of the idle task has been modified to have the function of calling the interrupt request simulator. However, the running mode of the idle task is different under different power consumption states. For example, when the first processor core is in a predetermined power consumption state, such as a low power consumption state, it will run a wait instruction, which may be a WFI / WFE instruction. When the idle task is resumed, the first processor core is in the wait state corresponding to the wait instruction, and therefore will not directly run the instruction after the wait instruction to call the interrupt request simulator. As another example, when the first processor core is not in a predetermined power consumption state, such as not in a low power consumption state, the idle task does not run the above-mentioned wait instruction. When the idle task is resumed, the first processor core can run the corresponding instruction to call the interrupt request simulator. Therefore, after determining that the first task is an idle task through the SDEI event processing module, it is also necessary to further determine whether the first processor core is in a predetermined power consumption state.

[0077] When the first task is an idle task and the first processor core is not in a predetermined power consumption state, the first processor core can use the first task to call the interrupt request simulator to determine whether the target event identifier stored in the first storage area belongs to the predetermined identifier.

[0078] Once it's determined that the running task is an idle task, it can be directly invoked when not in a low-power state. Since the idle task can invoke the interrupt request simulator, subsequent interrupt handling and other operations can be performed. This approach enables rapid interrupt handling even when running an idle task based on a microkernel architecture, further improving interrupt handling capabilities and efficiency.

[0079] In some embodiments, the above-described method of executing an operation corresponding to the first task based on the type of the first task running in the first processor core, using the SDEI event processing module, further includes: in response to the first processor core meeting a predetermined power consumption condition, modifying a first instruction in the instruction sequence currently corresponding to the first task to a second instruction in the instruction sequence, wherein the second instruction is an instruction following the first instruction; wherein, when the first task runs according to the second instruction, the first processor core does not meet the predetermined power consumption condition; and the first task runs according to the second instruction. The above-described method of determining whether a target event identifier stored in the first storage area belongs to a predetermined identifier by calling an interrupt request simulator further includes: using the first task to call an interrupt request simulator to determine whether a target event identifier stored in the first storage area belongs to a predetermined identifier through the interrupt request simulator.

[0080] For example, it can be determined that the first processor core is in a predetermined power consumption state when running the first task. The first task can be an idle task, and the predetermined power consumption state can be a low-power state. If the first processor core is executing a first instruction, such as a wait instruction (e.g., a WFI / WFE instruction), and if the idle task in the low-power state is directly restored, the first processor core will continue running the WFI / WFE instruction and will be unable to enter the subsequent operation of calling the interrupt request simulator. To avoid this, the first instruction in the instruction sequence currently to be executed by the first task can be modified to the second instruction in the instruction sequence. Specifically, the return address corresponding to the idle task (i.e., the address corresponding to the first instruction) can be modified to the address corresponding to the next instruction after the wait instruction (i.e., the address corresponding to the second instruction). The address corresponding to the second instruction is the address after the address corresponding to the first instruction in the instruction sequence. After restoring the idle task, the second instruction in the idle task can be executed, causing the first processor core to stop running the wait instruction, exiting the low-power state, and thus enabling the first processor core to continue executing the first task to call the interrupt request simulator to perform interrupt handling.

[0081] After determining that the running task is the primary task, and further determining that it is currently in a predetermined power consumption state, the idle task can continue to run by adjusting the instructions to be run during recovery. Since the primary processor core can call the interrupt request simulator through the idle task, it can effectively ensure that subsequent interrupt handling and other operations can be executed normally, thereby improving the task processing capability and efficiency for the idle task in different power consumption states. For example, if the first processor core is not in a predetermined power consumption state while running the first task, such as not being in a low-power state, then the first task will not execute the aforementioned wait instruction. Therefore, when resuming the first task, the first processor core can directly run the first task to call the interrupt request simulator using the corresponding instructions in the first task. The above method can directly call the interrupt request simulator through the idle task, improving the task processing capability and efficiency for the idle task.

[0082] Because a processor or on-chip system contains multiple processor cores, and these cores need to communicate and interact, there is a need for handling second interrupts. These second interrupts can also be called Software-Generated Interrupts (SGI) or SGI interrupts, including inter-core interrupts (IPI interrupts). Based on this, a second storage area can be set up in memory for each processor core to store the interrupt identifier for the second interrupt corresponding to each core. For any second interrupt, the exception handler at exception level EL3 can be started by calling the SDEI event signal function. This function carries the event identifier EVENT_0, and then the corresponding exception event (i.e., the SDEI event) is generated using the software delegated exception interface. For example, when other processor cores need to send a second interrupt to the first processor core, the identifier of the second interrupt to be handled can be recorded in the second storage area for the first processor core, and the SDEI event signal function can be called for the first processor core to enter exception level EL3 and generate the corresponding exception event.

[0083] In some embodiments, the first processor core is further configured to: read a second target interrupt identifier from a second storage area in memory via an interrupt request simulator in response to the target event identifier belonging to a predetermined identifier; wherein the interrupt corresponding to the predetermined identifier belongs to the second interrupt, and the second target interrupt identifier is an identifier corresponding to the second interrupt; and call the interrupt handling function corresponding to the second target interrupt identifier via the interrupt request simulator to process the second interrupt corresponding to the second target interrupt identifier.

[0084] For example, the first processor core can obtain the target event identifier of the target exception event stored in the first storage area for the first processor core through the interrupt request simulator, and determine whether the target event identifier is a predetermined identifier. For example, the predetermined identifier can be the event identifier for the second interrupt, represented as EVENT_0. Other types of event identifiers are represented differently from the event identifier for the second interrupt. These other types of event identifiers can be event identifiers assigned to multiple external fast interrupt requests, represented as EVENT_1, EVENT_2, ..., EVENT_N, where N is a positive integer. Furthermore, after the interrupt request simulator obtains the target event identifier, the target event identifier stored in the first storage area can be deleted to ensure that the first storage area stores the event identifiers corresponding to interrupt requests that have not yet been processed.

[0085] In one scenario, the first processor core determines, through the interrupt request simulator, that the target event identifier belongs to a predetermined identifier, i.e., the target event identifier is EVENT_0. Then, it can read the second interrupt identifier corresponding to the target event identifier (e.g., an identifier indicating an inter-core interrupt IPI) from the second storage area allocated for the first processor core in memory. Then, the interrupt request simulator calls the interrupt handling function corresponding to the second interrupt identifier to handle the second interrupt corresponding to the second interrupt identifier.

[0086] After determining that the target event identifier belongs to a predetermined identifier, it can be quickly identified that the interrupt to be processed is a second interrupt. The second target interrupt identifier can then be retrieved from the second storage area. The corresponding processing function can be called using this second target interrupt identifier to handle the second interrupt, thus improving the handling capability of second interrupts. Furthermore, since a storage area for storing second interrupt identifiers is set up for the processor core, it can store multiple second interrupts. This not only provides hardware support for handling second interrupts but also improves the ability to handle a large number of second interrupts.

[0087] In some embodiments, the apparatus further includes a second processor core configured to: generate a second interrupt for the first processor core; and, based on the second interrupt, invoke an SDEI event signaling function to send a target exception event corresponding to the second interrupt to a software delegated exception interface SDEI.

[0088] For example, the second interrupt described above is generated by a second processor core among multiple processor cores. For instance, when the second processor core needs to interact with the first processor core, it can initiate a corresponding second interrupt (such as an inter-core interrupt) to the first processor core. The second processor core can generate a target exception event corresponding to the second interrupt by calling the SDEI event semaphore function to utilize the Software Delegated Exception Interface (SDEI). During this process, the second processor core calls the SDEI event semaphore function to cause the first processor core to enter exception level EL3. The first processor core runs an exception handler at exception level EL3 to generate the target exception event (such as generating an SDEI event) using the Software Delegated Exception Interface (SDEI).

[0089] By calling the SDEI event signal function when a second interrupt is generated, the second interrupt can be quickly transferred from the second processor core to the first processor core, thus improving the transmission efficiency of the second interrupt.

[0090] In some embodiments, the second processor core is further configured to: store the second target interrupt identifier corresponding to the second interrupt in a second storage area in memory corresponding to the first processor core; wherein the second processor core has write permissions for the second storage area.

[0091] For example, when calling the SDEI event signal function to provide the target exception event corresponding to the second interrupt using the Software Delegated Exception Interface (SDEI), the second processor core can further write the second target interrupt identifier, such as an inter-core interrupt identifier, into the second memory area corresponding to the first processor core. As mentioned earlier, this second memory area is allocated to each processor core by the SDEI configuration management module. Other processor cores in the on-chip system besides the first processor core have write permissions to this second memory area and can write the second target interrupt identifier corresponding to the second interrupt that needs to be sent to the first processor core into the second memory area.

[0092] By writing the second target interrupt identifier corresponding to the second interrupt into the second storage area, information support can be provided for the first processor core to process the second interrupt subsequently, which helps to improve the first processor core's ability to process the second interrupt.

[0093] The virtual machine manager receives tasks from user space, which run at exception level EL0. Although user-mode tasks use Stage 2 to manage memory space, if an interrupt occurs during their execution, they will fall into exception level EL2, where the virtual machine manager will handle the interrupt. While the virtual machine manager can inject the interrupt corresponding to the user-mode task into the GIC's VCPU interface, due to the current configuration, the VCPU interface cannot trigger interrupts and provide them to exception level EL1, resulting in exception level EL1 not receiving the interrupt.

[0094] In some embodiments, to avoid the aforementioned problems, the first processor core is further configured to: in response to a first task running in the first processor core switching to a second task in user mode, mask a third interrupt for the first processor core by at least one of the following: adjusting the interrupt level information in the second register of the general interrupt controller for the first processor core to a target level information; wherein, when the second register is set to the target level information, the first processor core masks the third interrupt; or; setting the interrupt mask bit in the third register corresponding to the first processor core to a target value; wherein, when the third register is set to the target value, the first processor core masks the third interrupt.

[0095] For example, the first processor core can also run user-mode tasks or other types of tasks. To ensure that user-mode tasks can run normally on the first processor core, the third interrupt targeting the first processor core needs to be masked when running user-mode tasks. Specifically, the first processor core can determine whether the first task running on the first processor core has been switched to a second task (such as a user-mode task). If it is determined that the first task running on the first processor core has been switched to another type of task (i.e., not a second task, for example, a virtual machine task), the first processor core can receive the interrupt corresponding to that other type of task via the general interrupt controller and perform subsequent interrupt processing. If it is determined that the first task running on the first processor core has been switched to a second task belonging to user mode, the first processor core needs to mask the third interrupt targeting the first processor core. When masking the third interrupt, the interrupt masking can be performed in at least one of the following optional methods.

[0096] In one alternative approach, the general-purpose interrupt controller can configure a register for each processor core to store interrupt level information. This interrupt level information is used for interrupt filtering. Accordingly, the general-purpose interrupt controller includes a second register corresponding to the first processor core for storing interrupt level information. An interrupt can only be sent to a virtual machine task or user-mode task if the interrupt level information for that first processor core is higher than a certain threshold. Based on this, the interrupt level information in the second register corresponding to the first processor core in the general-purpose interrupt controller can be adjusted to a target level. For example, this target level can be set to a priority greater than that of IRQ interrupts but lower than that of FIQ interrupts. Therefore, with the second register set to the target level, the general-purpose interrupt controller masks third interrupts with priorities lower than the target level for the first processor core. For instance, the interrupt level information in the register within the CPU interface of each CPU in the GIC, which manages interrupts sent to the virtual machine, can be adjusted to the value of the target level, thereby filtering out interrupts with priorities lower than the target level.

[0097] In another alternative approach, a third register can be configured for the first processor core to control interrupts for that core. This third register can control whether interrupts for the first processor core are masked. For example, the mask bit for interrupts in the third register can be set to a target value to make the first processor core mask third interrupts. Furthermore, the mask bit in the third register for interrupt requests for the first processor core can be set to 1 to indicate that the first processor core masks interrupt requests, or the mask bit in the third register can be set to 0 to indicate that the first processor core does not mask interrupt requests.

[0098] When running user-mode tasks, by disabling interrupts for the first processor core, the inability to handle interrupts for user-mode tasks can be prevented, ensuring that interrupts for user-mode tasks can be handled normally.

[0099] In some embodiments, the first processor core is configured to: in response to receiving a first interrupt via a general interrupt controller, switch from a first exception level to a third exception level; run a second exception handler at the third exception level to call the Software Delegated Exception Interface (SDEI) to obtain a target exception event; store the target exception event in a third memory region for the first processor core; execute a second exception return instruction in the second exception handler to switch from the third exception level to the second exception level; the aforementioned use of the Software Delegated Exception Interface (SDEI) event handling module to obtain the target exception event for the first processor core specifically includes: running the SDEI event handling module at the second exception level to obtain the target exception event for the first processor core from the third memory region.

[0100] For example, when a first processor core receives a first interrupt (e.g., a FIQ) through a general interrupt controller, it switches from exception level EL1 (running a virtual machine task or idle task) to exception level EL3. In exception level EL3, a second exception handler runs. This second exception handler can call the Software Delegated Exception Interface (SDEI) to obtain a target exception event. To further pass the target exception event from exception level EL3 to the SDEI event handling module in exception level EL2, the first processor core can store the target exception event in a third memory area allocated for it. The target exception event includes, for example, an event identifier and a processor core marker (indicating which processor core the target exception event is for). When the second exception handler finishes execution, a second exception return instruction is executed. The corresponding hardware instruction switches the first processor core from exception level EL3 to exception level EL2. Then, the SDEI event handling module runs in exception level EL2 and retrieves the target exception event from the third memory area. In addition, SDEI can be implemented in the boot loader 31 (BL31 for short), where BL31 runs at exception level EL3.

[0101] After the first processor core receives the first interrupt, it can quickly switch to the exception level EL3 and store the generated target exception event (such as SDEI event information) in the third storage area so that the target exception event (such as SDEI event information) can be obtained from the third storage area after entering the exception level EL2. In this way, the interrupt request (such as FIQ) can be processed quickly.

[0102] In some embodiments, the first processor core is further configured to register an interrupt handler function corresponding to the first interrupt with the Software Delegated Exception Interface (SDEI).

[0103] For example, during device operation, interrupt handlers corresponding to different interrupts can be registered in the SDEI. For instance, the interrupt handler corresponding to the first interrupt can be registered in the SDEI for subsequent use during the handling of the first interrupt. By registering the interrupt handler corresponding to the first interrupt in the SDEI, the interrupt handler in the SDEI can be quickly retrieved during the handling of subsequent interrupts, improving interrupt handling efficiency.

[0104] Additionally, after generating the target exception event based on the first interrupt and / or the second interrupt, the first processor core will switch from exception level EL3 to exception level EL2, utilizing the SDEI event handling module and the interrupt request simulator to process the target exception event (such as an SDEI event). While at exception level EL2, the SDEI event handling module can perform preprocessing operations on the target exception event.

[0105] Figure 4 A schematic diagram of an architecture supporting interrupt handling, as provided in this disclosure, is shown. Figure 4 In Example 400, the general interrupt controller 430 can receive a first interrupt for a first processor core. The general interrupt controller 430 can further distinguish what type of interrupt the received first interrupt is. If the first interrupt is an IRQ type interrupt, it can be determined that it is an interrupt to be processed by the virtual machine 402 running in the first processor core, and the first interrupt can be sent to the virtual machine 402 for processing through the CPU interface 432. If the general interrupt controller 430 determines that the first interrupt is an FIQ type interrupt, it also needs to determine which processor core among the multiple processor cores initiated the first interrupt. If the first interrupt is initiated by the first processor core among the multiple processor cores, when the first processor core receives the first interrupt, it will switch to the exception handler in exception level EL3, and generate a target exception event (such as an SDEI event) for the first interrupt by calling the Software Delegated Exception Interface (SDEI) 428 located in BL31 426. For different types of interrupts, target exception events with different exception event identifiers can be generated. After the first processor core switches from exception level EL3 to exception level EL2, the SDEI event handling module 410 in the virtual machine manager 404 processes the target exception event.

[0106] When the virtual machine manager starts, the SDEI configuration management module 422 allocates a corresponding storage area in memory for each processor core. For any given processor core, the storage area may include at least a first storage area 412 for storing event identifiers of pending exception events for that processor core, and a second storage area 414 for storing the identifier of the second target interrupt corresponding to the second interrupt. To enable the virtual machine manager 404 to process the first interrupt, the SDEI configuration management module 422 also configures a dedicated fourth storage area 408 in memory to store a preset mapping relationship between event identifiers and interrupt identifiers. This preset mapping relationship represents the correspondence between exception events and the first interrupt. For example, the preset mapping relationship includes the association between event identifiers and corresponding interrupt identifiers, thereby allowing the determination of the type of exception event corresponding to the first interrupt based on this preset mapping relationship. When processing the first interrupt received from the general interrupt controller 430 using the Software Delegated Exception Interface (SDEI) 428, the event identifier corresponding to the first interrupt is searched based on the received first interrupt.

[0107] The following is a detailed description of how the SDEI event processing module 410 handles abnormal events. Running on the first processor core, the SDEI event processing module 410 can perform preprocessing for abnormal events. After receiving or detecting an abnormal event, the SDEI event processing module 410 first marks the first processor core as an abnormal event to be processed. Furthermore, it can store the event identifier of the abnormal event to be processed in the first storage area of ​​the memory. Subsequently, the SDEI event handling module 410 determines whether the task running on the first processor core is an idle task. If the task is not idle but belongs to another task, such as running a virtual machine (VM), the first page table configuration information (which could be Stage 2 page table configuration) for the virtual machine 402 is modified to the incorrect second page table configuration information during preprocessing. After preprocessing is complete, the system can switch from exception level EL2 to exception level EL1 to resume the operation of the virtual machine 402 on the first processor core. During virtual machine operation, if the detection of the second page table configuration information causes an error in the running virtual machine 402, the first processor core will stop running the virtual machine 402 and fall back into exception level EL2, calling the SDEI interrupt request simulator 418 in the virtual machine manager 404 to perform corresponding operations. If the task on the first processor core is an idle task, the SDEI interrupt request simulator 418 can be called through the idle task 420 to perform corresponding operations.

[0108] Specifically, the SDEI interrupt request simulator 418 performs the corresponding operation by retrieving the target event identifier of the corresponding exception event from the first storage area 412, which stores event identifiers of SDEI events to be processed, and then determining whether the target event identifier is a predetermined identifier. If the target event identifier is not a predetermined identifier, for example, not EVENT_0, but another event identifier, it indicates that the interrupt to be processed is the first interrupt. In this case, the SDEI interrupt request simulator 418 needs to retrieve the preset mapping relationship between event identifiers and interrupt identifiers from the fourth storage area 408, and find the first target interrupt identifier corresponding to the target event identifier through the preset mapping relationship. After determining the corresponding first target interrupt identifier, the interrupt handling function corresponding to the first target interrupt identifier can be called to process the first interrupt. After processing the first interrupt, if a virtual machine (VM) was previously running on the first processor core, the virtual machine (VM) is resumed. In this way, the virtual machine manager can be used to process multiple different types of first interrupts.

[0109] The virtual machine manager 404 can also handle second interrupts. For example, if the second processor core needs to send a second interrupt (which could be an inter-core interrupt) to the first processor core, it can call the SDEI event signal function through the inter-process communication IPI (inter-process communication) sending module 416 to cause the first processor core to enter exception level EL3 and execute the exception handler. The software delegated exception interface (SDEI) 428 is then used to convert the second interrupt into a target exception event. Furthermore, when the second processor core initiates a second interrupt, for example, if the second processor core needs to send a second interrupt to the first processor core (the second target interrupt identifier of the second interrupt is stored in the second storage area 414 for the first processor core), the exception event obtained by the SDEI 428 will be provided to the SDEI event handling module 410 running at exception level EL2. During the interrupt processing by the SDEI interrupt request simulator 418, the SDEI interrupt request simulator 418 will determine whether the target event identifier stored in the first storage area is a predetermined identifier, such as whether it is EVENT_0. If it is determined that the target event identifier is a predetermined identifier, the SDEI interrupt request simulator 418 can directly read the second target interrupt identifier of the second interrupt to be processed from the second storage area and select the corresponding interrupt handling function to process the second interrupt.

[0110] In addition, in carrying out such Figure 4 During task switching as shown in 406, if the first task in the first processor core switches to the second task in user mode, for example, if the second task is a non-VCPU task, then the first interrupt for the second task should be disabled.

[0111] Exemplary methods

[0112] Figure 5 A flowchart illustrating a method for supporting interrupt handling provided in this disclosure is shown. Figure 5 As shown, the process 500 can be executed on the first processor core of the interrupt-handling device 300. The interrupt-handling method provided in this disclosure includes:

[0113] In step 502, the target exception event for the first processor core is obtained by using the Software Delegated Exception Interface (SDEI) event handling module; wherein the target exception event is generated by SDEI.

[0114] At step 504, the SDEI event processing module is used to write the target event identifier of the target abnormal event into the first storage area in the memory corresponding to the first processor core.

[0115] In step 506, the interrupt request simulator is invoked to determine whether the target event identifier stored in the first storage area belongs to the predetermined identifier.

[0116] In step 508, in response to the fact that the target event identifier does not belong to the predetermined identifier, the interrupt request simulator determines the first target interrupt identifier corresponding to the target event identifier based on the target event identifier and the preset mapping relationship, wherein the preset mapping relationship represents the mapping relationship between the event identifier and the interrupt identifier.

[0117] In step 510, the interrupt handling function corresponding to the first target interrupt identifier is called by the interrupt request simulator to process the first interrupt corresponding to the first target interrupt identifier.

[0118] Figure 6 A flowchart of a method for writing a target event identifier according to this disclosure is shown. This flowchart 600 is a specific example of the operation corresponding to step 504. Specifically, the operation in step 504 involves writing the target event identifier of the target exception event into the first storage area corresponding to the first processor core in the memory using the SDEI event processing module, including:

[0119] At step 602, the target event identifier included in the target abnormal event is obtained using the SDEI event handling module.

[0120] At step 604, the target event identifier is stored in the first storage area corresponding to the first processor core using the SDEI event processing module.

[0121] Figure 7 A flowchart of an operation method corresponding to a first task, provided in this disclosure, is shown. This process 700 is an example of the operation performed prior to step 506.

[0122] At step 702, the type of the first task running on the first processor core is determined using the SDEI event handling module;

[0123] At step 704, based on the type of the first task running on the first processor core, the operation corresponding to the first task is executed using the SDEI event handling module.

[0124] Figure 8 A flowchart of a method for processing target event identifiers using an interrupt request simulator provided in this disclosure is shown. Prior to the operation in step 504, the first processor core is further configured to: store an indicator indicating the presence of an abnormal event in the memory unit corresponding to the first processor core using the SDEI event processing module.

[0125] Process 800 is a specific example of the operation corresponding to step 506. The operation in step 506 is: determining whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator, specifically including:

[0126] At step 802, the interrupt request simulator is used to determine whether an indicator exists in the memory cell.

[0127] At step 804, in response to the presence of an indicator in the storage unit, the target event identifier corresponding to the target abnormal event is read from the first storage area.

[0128] In step 806, it is determined whether the target event identifier belongs to the predetermined identifier.

[0129] Figure 9 A flowchart of an interrupt handling method provided in this disclosure is shown. This process 900 can be executed on a first processor core of an interrupt handling device 300.

[0130] At step 902, in response to the target event identifier belonging to a predetermined identifier, the second target interrupt identifier is read from the second storage area in the memory through the interrupt request simulator; wherein, the interrupt corresponding to the predetermined identifier belongs to the second interrupt, and the second target interrupt identifier is the identifier corresponding to the second interrupt.

[0131] At step 904, the interrupt handling function corresponding to the second target interrupt identifier is called by the interrupt request simulator to process the second interrupt corresponding to the second target interrupt identifier.

[0132] Figure 10 A flowchart of a method for switching exception levels provided in this disclosure is shown. This process 1000 can be executed on a first processor core of a device 300 that supports interrupt handling.

[0133] At step 1002, in response to receiving a first interrupt through the general interrupt controller, the first processor core switches from the first exception level to the third exception level.

[0134] At step 1004, the second exception handler is run at the third exception level to call SDEI to obtain the target exception event.

[0135] At step 1006, the target exception event is stored in the memory in a third memory area for the first processor core.

[0136] At step 1008, the second exception return instruction in the second exception handler is executed to switch from the third exception level to the second exception level.

[0137] Additionally, step 502 involves using the Software Delegated Exception Interface (SDEI) event handling module to retrieve the target exception event for the first processor core. An example of the operation corresponding to step 502 specifically includes running the SDEI event handling module at a second exception level to retrieve the target exception event for the first processor core from a third storage area.

[0138] Figure 11 This disclosure illustrates an example of an SDEI event handling module (e.g., Figure 4 The flowchart below shows the SDEI event handling module. In process 1100, at step 1102, the SDEI event handling module atomically marks a target exception event to be processed by the first processor core, such as an SDEI event. At step 1104, the SDEI event handling module obtains the target event identifier of the target exception event, such as the SDEI event number, which can be obtained from the obtained SDEI events. At step 1106, the SDEI event handling module atomically records the target event identifier of the target exception event that the first processor core is ready. At step 1108, the SDEI event handling module determines whether the type of the first task is an idle task, such as the first task being a currently executing task. If the type of the first task is not an idle task, then at step 1112, the first page table configuration information is saved. For example, the SDEI event handling module saves the first page table configuration information in the registers of the first processor core to memory for later restoration from memory. In step 1114, the SDEI event handling module modifies the first page table configuration information, adjusting it to an incorrect configuration, and obtains the modified second page table configuration information. In step 1118, it returns to SDEI so that after the virtual machine is restored, due to the incorrect configuration of the second page table information, it will enter an SDEI interrupt request simulator for interrupt handling.

[0139] If it is determined in step 1108 that the type of the first task is an idle task, then it is necessary to further determine in step 1110 whether the first processor core meets the predetermined power consumption conditions. For example, it can be determined whether the current processor core is in a low-power state by checking whether the instruction that interrupted the IDLE task is a WFI / WFE instruction.

[0140] If the predetermined power consumption condition is not met, the process returns to SDEI at step 1118 to utilize the first task to call the SDEI interrupt request simulator. If it is determined at step 1110 that the first processor core meets the predetermined power consumption condition, at step 1116, the first instruction in the instruction sequence corresponding to the first task is modified to the second instruction in the instruction sequence. For example, the recovery address of the first task can be modified to prevent the first processor core from entering the predetermined power consumption state. If the first task is an IDLE task and was in a low-power state before being interrupted, the first task will start execution from the instruction following the WFI / WFE instruction when restoring the context; otherwise, the first task will enter a low-power state again when restoring, causing the interrupt to fail. Proceed to step 1118 to utilize the first task to call the SDEI interrupt request simulator.

[0141] Therefore, if the first task is an idle task, after the SDEI event handling module finishes processing and returns to SDEI, SDEI will resume the first task's execution. After the first task resumes execution, SDEI interrupt simulation processing is performed. The first task now includes a procedure for calling the SDEI interrupt request simulator.

[0142] Figure 12 This disclosure illustrates an SDEI interrupt request simulator (e.g., Figure 4The flowchart of the SDEI interrupt request simulator is as follows. In process 1200, at step 1202, the SDEI interrupt request simulator first determines whether there is a target exception event to be processed, such as an SDEI event. If there is no target exception event to be processed, it indicates that the entry into this processing process is caused by other VM Stage2 (the first page table configuration information corresponding to the virtual machine) exceptions, and VM Stage2 exception processing is performed at step 1220. Among them, other VM Stage2 exceptions refer to the exceptions captured by the hardware when the virtual machine accesses physical memory through "Stage-2 address translation", and these exceptions are not caused by SDEI events. If there is a target exception event to be processed, at step 1204, the target event identifier of the first processor core is atomically acquired and cleared. Next, at step 1206, it is further determined whether the target event identifier belongs to a predetermined identifier, such as whether the predetermined identifier is EVENT_0. If the target event identifier belongs to a predetermined identifier, then at step 1208, the second target interrupt identifier of the ready second interrupt in the second storage area is atomically acquired and cleared, and at step 1212, the interrupt handling function corresponding to the second target interrupt identifier is called to process the second interrupt.

[0143] Furthermore, if it is determined in step 1206 that the ready target event identifier does not belong to the predetermined identifier, then in step 1210, according to the preset mapping relationship between event identifiers and interrupt identifiers, the first target interrupt identifier corresponding to the target event identifier is obtained. In step 1212, the interrupt handling function corresponding to the first target interrupt identifier is called to handle the first interrupt.

[0144] After interrupt handling is complete, the first page table configuration information can be restored in step 1214. For example, the first page table configuration information stored in memory can be reread into the registers for the processor core. At step 1216, the interrupt flag for the target exception event is atomically cleared, and at step 1218, virtual machine recovery is performed.

[0145] The SDEI interrupt request simulator described above can handle not only multiple IPIs but also non-IPI interrupts. Since the virtual machine manager does not receive interrupts when user-mode tasks are running in a microkernel scenario, the following processing flow needs to be added during task switching, where the user-mode task is a non-VCPU task.

[0146] Figure 13The flowchart of a task switching method provided in this disclosure is illustrated. In example flow 1300, at step 1302, a task switch is performed, for example, switching a first task running on a first processor core to a second task. At step 1304, it is determined whether the second task is a user-mode task. If the second task is not a user-mode task, such as a VCPU task, then at step 1308, interrupt masking is removed, and the first processor core receives interrupts. If the second task is a user-mode task, then at step 1306, a third interrupt for the first processor core is masked, and the first processor core no longer receives interrupts. At step 1310, other steps of the task switching process are executed.

[0147] Exemplary device

[0148] Figure 14 A schematic diagram of an interrupt handling apparatus 1400 provided in this disclosure is shown. The apparatus may include multiple modules for performing tasks such as... Figure 5 The corresponding steps in process 500 discussed herein. For example... Figure 14 As shown, the device 1400 includes a target abnormal event acquisition unit 1402, configured to acquire a target abnormal event for a first processor core using a Software Delegated Exception Interface (SDEI) event processing module; wherein the target abnormal event is generated by SDEI; a target event identifier writing unit 1404, configured to write the target event identifier of the target abnormal event into a first storage area in memory corresponding to the first processor core using the SDEI event processing module; an identifier determination unit 1406, configured to determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling an interrupt request simulator; an interrupt identifier determination unit 1408, configured to determine a first target interrupt identifier corresponding to the target event identifier based on the target event identifier and a preset mapping relationship by an interrupt request simulator in response to the target event identifier not belonging to the predetermined identifier, wherein the preset mapping relationship represents the mapping relationship between the event identifier and the interrupt identifier; and a processing function call unit 1410, configured to call the interrupt processing function corresponding to the first target interrupt identifier through an interrupt request simulator to process the first interrupt corresponding to the first target interrupt identifier.

[0149] In some embodiments, the target event identifier writing unit 1404 specifically includes: a target event identifier acquisition unit, configured to acquire the target event identifier included in the target abnormal event using the SDEI event processing module; and a first storage unit, configured to store the target event identifier in a first storage area corresponding to the first processor core using the SDEI event processing module.

[0150] In some embodiments, before determining whether a target event identifier stored in the first storage area belongs to a predetermined identifier by calling an interrupt request simulator, the apparatus further includes: a task type determination unit configured to determine the type of a first task running on the first processor core using an SDEI event processing module; and an operation execution unit configured to perform an operation corresponding to the first task using an SDEI event processing module based on the type of the first task running on the first processor core.

[0151] In some embodiments, the SDEI event handling module and the interrupt request simulator operate at a second exception level. The operation execution unit includes: a configuration information modification unit configured to modify the first page table configuration information in the first register using the SDEI event handling module in response to the first task's type not being an idle task, to obtain the modified second page table configuration information; an instruction execution unit configured to execute a first exception return instruction using the SDEI event handling module to switch from the second exception level to running the virtual machine at the first exception level; and an exception level switching unit configured to switch from the first exception level to the second exception level in response to detecting an error in the second page table configuration information of the first task during the virtual machine's operation. The identification determination unit 1406 specifically includes: a first calling unit configured to call the interrupt request simulator using the first exception handler at the second exception level; and a first identification determination unit configured to determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier using the interrupt request simulator.

[0152] In some embodiments, the operation execution unit specifically includes: a power consumption condition determination unit, configured to determine whether the first processor core meets a predetermined power consumption condition in response to the first task being an idle task; and a first task execution unit, configured to directly run the first task in response to the first processor core not meeting the predetermined power consumption condition; wherein the identification determination unit 1406 specifically includes: a second invocation unit, configured to invoke an interrupt request simulator using the first task to determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier through the interrupt request simulator.

[0153] In some embodiments, the operation execution unit further includes: an instruction modification unit configured to modify a first instruction in the instruction sequence currently corresponding to the first task to a second instruction in the instruction sequence in response to the first processor core meeting a predetermined power consumption condition; wherein the second instruction is an instruction following the first instruction; wherein the first processor core does not meet the predetermined power consumption condition when the first task runs according to the second instruction; a first task execution unit configured to run the first task according to the second instruction; and an identification determination unit 1406 specifically includes: a third invocation unit configured to invoke an interrupt request simulator using the first task to determine whether a target event identifier stored in the first storage area belongs to a predetermined identifier.

[0154] In some embodiments, before modifying the first page table configuration information in the register using the SDEI event processing module, the device 1400 further includes: a configuration information reading unit configured to read the first page table configuration information from the register; a configuration information writing unit configured to write the read first page table configuration information into memory; after calling the interrupt handling function corresponding to the first target interrupt identifier through the interrupt request simulator to process the first interrupt corresponding to the first target interrupt identifier, the device 1400 further includes: a second configuration information reading unit configured to read the first page table configuration information from memory; and a configuration information updating unit configured to update the second page table configuration information in the register using the read first page table configuration information.

[0155] In some embodiments, before writing the target event identifier of the target abnormal event into the first storage area corresponding to the first processor core in the memory using the SDEI event processing module, the apparatus 1400 further includes: an indicator identifier storage unit, configured to store an indicator identifier indicating the existence of an abnormal event in the storage unit corresponding to the first processor core using the SDEI event processing module; the identifier determination unit 1406 includes: a first determination unit, configured to determine whether an indicator identifier exists in the storage unit using an interrupt request simulator; a target event identifier reading unit, configured to read the target event identifier corresponding to the target abnormal event from the first storage area in response to the existence of an indicator identifier in the storage unit; and a first identifier determination unit, configured to determine whether the target event identifier belongs to a predetermined identifier.

[0156] In some embodiments, the apparatus 1400 further includes: an interrupt identifier reading unit, configured to read a second target interrupt identifier from a second storage area in the memory via an interrupt request simulator in response to the target event identifier belonging to a predetermined identifier; wherein the interrupt corresponding to the predetermined identifier belongs to the second interrupt, and the second target interrupt identifier is an identifier corresponding to the second interrupt; and an interrupt handling function calling unit, configured to call an interrupt handling function corresponding to the second target interrupt identifier via an interrupt request simulator to process the second interrupt corresponding to the second target interrupt identifier.

[0157] In some embodiments, the apparatus 1400 further includes: a second interrupt generation unit configured to generate a second interrupt for the first processor core by the second processor core; and an event signal function call unit configured to, based on the second interrupt, call the SDEI event signal function to send a target exception event corresponding to the second interrupt to the software delegated exception interface SDEI.

[0158] In some embodiments, the apparatus 1400 further includes: a second interrupt identifier storage unit, configured to store a second target interrupt identifier corresponding to a second interrupt in a second storage area in memory corresponding to the first processor core; wherein the second processor core has write permissions for the second storage area.

[0159] In some embodiments, the apparatus 1400 further includes: an interrupt masking unit configured to, in response to a first task running in the first processor core switching to a second task in user mode, mask a third interrupt for the first processor core by at least one of the following: adjusting interrupt level information in a second register of the general interrupt controller for the first processor core to target level information; wherein, when the second register is set to the target level information, the first processor core masks the third interrupt; or; setting the interrupt mask bit in the third register corresponding to the first processor core to a target value; wherein, when the third register is set to the target value, the first processor core masks the third interrupt.

[0160] In some embodiments, the apparatus 1400 includes: a first exception level switching unit configured to switch a first processor core from a first exception level to a third exception level in response to a first interrupt being received via a general interrupt controller; a target exception event acquisition unit configured to run a second exception handler at the third exception level to call an SDEI to obtain a target exception event; a target exception event storage unit configured to store the target exception event in a third storage area in memory for the first processor core; and an exception return instruction execution unit configured to execute a second exception return instruction in the second exception handler to switch from the third exception level to the second exception level; the target exception event acquisition unit 1402 includes: an event processing module running unit configured to run an SDEI event processing module at the second exception level to obtain the target exception event for the first processor core from the third storage area.

[0161] In some embodiments, the apparatus 1400 further includes a registration module configured to register an interrupt handling function corresponding to the first interrupt in the software delegated exception interface SDEI.

[0162] In some embodiments, the first interrupt includes at least one of the following: an interrupt generated by a timer; an interrupt generated by a driver corresponding to an external device.

[0163] Exemplary electronic devices

[0164] Figure 15 A schematic diagram of the structure of an exemplary electronic device 1500 (hereinafter referred to as device 1500) provided in this disclosure is shown. Figure 5 Process 500 can be implemented using device 1500. As shown, device 1500 includes a central processing unit 1501 (also referred to as a central processing unit or CPU), which can execute the methods provided in any of the above embodiments of this disclosure according to computer program instructions stored in read-only memory (ROM) 1502 or loaded from storage unit 1508 into random access memory (RAM) 1503. Various programs and data required for the operation of device 1500 may also be stored in RAM 1503. CPU 1501, ROM 1502, and RAM 1503 are interconnected via bus 1504. Input / output (I / O) interface 1505 is also connected to bus 1504.

[0165] Multiple components in device 1500 are connected to I / O interface 1505, including: input unit 1506, such as keyboard, mouse, etc.; output unit 1507, such as various types of monitors, speakers, etc.; storage unit 1508, such as disk, optical disk, etc.; and communication unit 1509, such as network card, modem, wireless transceiver, etc. Communication unit 1509 allows device 1500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0166] The various processes and handling described above, such as process 500, can be executed by processing unit 1501. For example, in some embodiments, process 500 can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1508. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1500 via ROM 1502 and / or communication unit 1509. When the computer program is loaded into RAM 1503 and executed by CPU 1501, one or more actions of process 500 described above can be performed to implement the processing interruption methods and / or other desired functions of the various embodiments of this disclosure above.

[0167] Exemplary computer program products and computer-readable storage media

[0168] In addition to the methods and apparatus described above, embodiments of this disclosure may also provide a computer program product, including computer program instructions that, when executed by a processor, cause the processor to perform the steps of the processing interrupt methods of the various embodiments of this disclosure described in the "Exemplary Methods" section above.

[0169] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of embodiments of this disclosure. These programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0170] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform steps in the methods for handling interrupts described in the various embodiments of this disclosure in the "Exemplary Methods" section above.

[0171] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may include, but is not limited to, systems, apparatuses, or devices that are electrical, magnetic, optical, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0172] The basic principles of this disclosure have been described above with reference to specific embodiments. However, the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0173] Various modifications and variations can be made to this disclosure without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include such modifications and variations.

Claims

1. An apparatus for supporting interrupt handling, comprising: Memory; as well as A first processor core, electrically connected to the memory, is configured to: The target exception event for the first processor core is obtained using the Software Delegated Exception Interface (SDEI) event handling module; wherein, the target exception event is generated through SDEI. The target event identifier of the target abnormal event is written into the first storage area in the memory corresponding to the first processor core using the SDEI event processing module. The interrupt request simulator is invoked to determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier; In response to the fact that the target event identifier does not belong to the predetermined identifier, the interrupt request simulator determines the first target interrupt identifier corresponding to the target event identifier based on the target event identifier and the preset mapping relationship, wherein the preset mapping relationship represents the mapping relationship between the event identifier and the interrupt identifier; The interrupt request simulator calls the interrupt handling function corresponding to the first target interrupt identifier to process the first interrupt corresponding to the first target interrupt identifier.

2. The apparatus according to claim 1, wherein, The step of writing the target event identifier of the target abnormal event into the first storage area corresponding to the first processor core in the memory using the SDEI event processing module specifically includes: The target event identifier included in the target abnormal event is obtained using the SDEI event processing module. The target event identifier is stored in the first storage area corresponding to the first processor core using the SDEI event processing module.

3. The apparatus according to claim 1 or 2, wherein, Before determining whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator, the first processor core is further configured to: The SDEI event processing module is used to determine the type of the first task running on the first processor core; Based on the type of the first task running on the first processor core, the SDEI event processing module is used to perform an operation corresponding to the first task.

4. The apparatus according to claim 3, wherein, The SDEI event handling module and the interrupt request simulator run at the second exception level. The operation corresponding to the first task, based on the type of the first task running in the first processor core, is performed using the SDEI event handling module, specifically including: In response to the fact that the type of the first task is not an idle task, the SDEI event processing module is used to modify the first page table configuration information in the first register to obtain the modified second page table configuration information. The SDEI event handling module is used to execute a first exception return instruction to switch from the second exception level to running the virtual machine in the first exception level; In response to detecting an error in the second page table configuration information of the first task during the operation of the virtual machine, the system switches from the first exception level to the second exception level. The step of determining whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator specifically includes: The interrupt request simulator is invoked using the first exception handler at the second exception level; The interrupt request simulator is used to determine whether the target event identifier stored in the first storage area belongs to the predetermined identifier.

5. The apparatus according to claim 3, wherein, The operation corresponding to the first task, based on the type of the first task running in the first processor core, is executed using the SDEI event processing module, specifically including: In response to the first task being an idle task, determine whether the first processor core meets the predetermined power consumption conditions; In response to the first processor core not meeting the predetermined power consumption condition, the first task is executed directly; The step of determining whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator specifically includes: The first task invokes the interrupt request simulator to determine whether the target event identifier stored in the first storage area belongs to the predetermined identifier.

6. The apparatus according to claim 5, wherein, The step of performing an operation corresponding to the first task based on the type of the first task running in the first processor core, using the SDEI event processing module, specifically further includes: In response to the first processor core meeting the predetermined power consumption condition, the first instruction in the instruction sequence currently corresponding to the first task is modified to the second instruction in the instruction sequence, wherein the second instruction is the instruction following the first instruction; wherein, when the first task is running according to the second instruction, the first processor core does not meet the predetermined power consumption condition; The first task is executed according to the second instruction; The step of determining whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator specifically includes: The first task invokes the interrupt request simulator to determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier.

7. The apparatus according to claim 4, wherein, Before modifying the first page table configuration information in the register using the SDEI event handling module, the first processor core is also configured as follows: Read the first page table configuration information from the register; Write the read first page table configuration information into the memory; After the interrupt request simulator calls the interrupt handling function corresponding to the first target interrupt identifier to process the first interrupt corresponding to the first target interrupt identifier, the first processor core is further configured as follows: Read the first page table configuration information from the memory; The second page table configuration information in the register is updated by reading the first page table configuration information.

8. The apparatus according to claim 1, wherein, Before the target event identifier of the target exception event is written into the first storage area corresponding to the first processor core in the memory using the SDEI event processing module, the first processor core is further configured as follows: The SDEI event handling module stores an indicator indicating the presence of an abnormal event in the memory unit corresponding to the first processor core; The step of determining whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator specifically includes: The interrupt request simulator is used to determine whether the indication identifier exists in the storage unit; In response to the presence of the indication identifier in the storage unit, the target event identifier corresponding to the target abnormal event is read from the first storage area; Determine whether the target event identifier belongs to the predetermined identifier.

9. The apparatus according to claim 1, wherein, The first processor core is also configured as follows: In response to the target event identifier belonging to the predetermined identifier, the second target interrupt identifier is read from the second storage area in the memory through the interrupt request simulator; wherein, the interrupt corresponding to the predetermined identifier belongs to the second interrupt, and the second target interrupt identifier is an identifier corresponding to the second interrupt; The interrupt request simulator calls the interrupt handling function corresponding to the second target interrupt identifier to process the second interrupt corresponding to the second target interrupt identifier.

10. The apparatus according to claim 9, wherein, The device further includes a second processor core, which is configured to: Generate the second interrupt for the first processor core; Based on the second interrupt, the SDEI event signal function is invoked to send the target exception event corresponding to the second interrupt to the software delegated exception interface SDEI.

11. The apparatus according to claim 10, wherein, The second processor core is also configured as follows: The second target interrupt identifier corresponding to the second interrupt is stored in the second storage area in the memory corresponding to the first processor core; wherein the second processor core has write permissions for the second storage area.

12. The apparatus according to claim 3, wherein, The first processor core is also configured as follows: In response to the first task running in the first processor core switching to a second task in user mode, a third interrupt for the first processor core is masked by at least one of the following: Adjust the interrupt level information in the second register of the general interrupt controller for the first processor core to the target level information; wherein, when the second register is set to the target level information, the first processor core masks the third interrupt; or; Set the interrupt mask bit in the third register corresponding to the first processor core to a target value; wherein, when the third register is set to the target value, the first processor core masks the third interrupt.

13. The apparatus according to claim 12, wherein, The first processor core is configured as follows: In response to receiving the first interrupt through the general interrupt controller, the first processor core switches from the first exception level to the third exception level; The second exception handler is run at the third exception level to invoke the SDEI to obtain the target exception event; The target abnormal event is stored in the memory in a third storage area for the first processor core; Execute the second exception return instruction in the second exception handler to switch from the third exception level to the second exception level; Specifically, obtaining the target exception event for the first processor core using the Software Delegated Exception Interface (SDEI) event handling module includes: The SDEI event handling module is run in the second exception level to retrieve the target exception event for the first processor core from the third storage area.

14. The apparatus according to claim 1, wherein the first processor core is further configured to: register an interrupt handling function corresponding to the first interrupt in the software delegated exception interface SDEI.

15. The apparatus according to claim 1, wherein, The first interrupt includes at least one of the following: Interrupts generated by timers; An interrupt generated by the driver corresponding to an external device.

16. A method for handling interruptions, comprising: The software delegated exception interface (SDEI) event handling module is used to obtain the target exception event for the first processor core; wherein, the target exception event is generated through SDEI. The SDEI event processing module is used to write the target event identifier of the target abnormal event into the first storage area in the memory corresponding to the first processor core; The interrupt request simulator is invoked to determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier; In response to the fact that the target event identifier does not belong to the predetermined identifier, the interrupt request simulator determines the first target interrupt identifier corresponding to the target event identifier based on the target event identifier and the preset mapping relationship, wherein the preset mapping relationship represents the mapping relationship between the event identifier and the interrupt identifier; The interrupt request simulator calls the interrupt handling function corresponding to the first target interrupt identifier to process the first interrupt corresponding to the first target interrupt identifier.

17. An apparatus for handling interruptions, comprising: The target exception event acquisition unit is configured to acquire a target exception event for the first processor core using the Software Delegated Exception Interface (SDEI) event processing module; wherein the target exception event is generated through SDEI. The target event identifier writing unit is configured to use the SDEI event processing module to write the target event identifier of the target abnormal event into the first storage area in the memory corresponding to the first processor core; The identifier determination unit is configured to determine whether the target event identifier stored in the first storage area belongs to a predetermined identifier by calling the interrupt request simulator; An interrupt identifier determination unit is configured to, in response to the target event identifier not belonging to the predetermined identifier, determine a first target interrupt identifier corresponding to the target event identifier through the interrupt request simulator based on the target event identifier and a preset mapping relationship, wherein the preset mapping relationship represents the mapping relationship between event identifiers and interrupt identifiers; The function call unit is configured to call the interrupt handling function corresponding to the first target interrupt identifier through the interrupt request simulator to process the first interrupt corresponding to the first target interrupt identifier.

18. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the method for handling interrupts according to claim 16.

19. An electronic device, the electronic device comprising: processor; Memory used to store executable instructions for a computer; The processor is configured to read the computer-executable instructions from the memory and execute the computer-executable instructions to implement the interrupt handling method of claim 16.

Images