CN116521324A

CN116521324A - Interrupt virtualization processing method and device and electronic equipment

Info

Publication number: CN116521324A
Application number: CN202310788570.0A
Authority: CN
Inventors: 贾艳磊
Original assignee: Shenzhen Zhongan Chenhong Technology Co ltd
Current assignee: Shenzhen Zhongan Chenhong Technology Co ltd
Priority date: 2023-06-30
Filing date: 2023-06-30
Publication date: 2023-08-01
Anticipated expiration: 2043-06-30
Also published as: CN116521324B

Abstract

The application belongs to the technical field of virtualization of ARM hardware architecture, and discloses an interrupt virtualization processing method, an interrupt virtualization processing device and electronic equipment. The method comprises the steps of obtaining an interrupt request signal generated when a vTimer counter reaches a preset threshold value; converting the interrupt request signal into a Message, and sending the Message to an SOC interconnection bus; monitoring Message information on the SOC interconnection bus to detect triggering of vTimer interrupt, receiving the triggered vTimer interrupt through a preset interrupt software and hardware interface, identifying an interrupt number corresponding to the vTimer interrupt, and obtaining a mapping relation between the interrupt number and a vCPU; and injecting the vTimer interrupt into the corresponding vCPU according to the mapping relation between the interrupt number and the vCPU so as to enable the vCPU to perform interrupt processing. According to the method and the device, the vTimer interrupt can be directly injected into the running virtual machine through the cooperation of software and hardware, a middle VMM layer is not needed, time delay in interrupt processing is shortened, and system performance of the electronic equipment is improved.

Description

Interrupt virtualization processing method and device and electronic equipment

Technical Field

The application belongs to the technical field of virtualization of ARM hardware architecture, and particularly relates to an interrupt virtualization processing method, an interrupt virtualization processing device and electronic equipment.

Background

The interrupt processing flow in the ARM hardware architecture is as follows: interrupts generated by the device and soft interrupts generated by the operating system kernel are notified to the CPU after the unified arbitration schedule is assembled by the interrupt controller (General Interrupt Controller, GIC); the CPU saves the running context of the current program and then invokes an interrupt service routine to process the interrupt; the interrupt service routine identifies the interrupt type by reading the relevant register, and then executes corresponding processing; after the interrupt request is executed, clearing the interrupt through a read-write related interrupt control register; and finally, restoring the execution context of the interrupted program, and continuing to execute the interrupted program.

In an ARM platform system supporting virtualization, a Hypervisor can provide hardware simulated by software such as Virtual PE (Virtual Process Element ) for Guest OS (Guest operating system), virtual GIC (Virtual Generic Interrupt Controller, interrupt controller in a virtualized environment) and the like as system software, and maintain mapping relation between actual physical equipment and Virtual PE when distributing physical peripherals to the Guest OS, and isolate execution environments of a plurality of Guest OSs. In the interaction process of the Guest OS and the hardware device Timer, whether the Guest OS is accessed to a device space or the device interrupt is reported to the Guest OS, the Guest OS is required to be provided with access and interrupt service by the Hypervisor (virtual machine monitor) layer according to the maintained mapping relationship, so that frequent switching of the CPU between the Guest OS and the Hypervisor layer is introduced, and frequent actions of saving and restoring the execution context exist.

In the process of implementing the embodiments of the present application, the inventors found that the above related art has at least the following problems: wasting CPU clock cycles and increasing CPU consumption; especially, the vTimer interrupt of the Guest OS is not sporadic but periodic, and the delay caused by the switching mode may have a larger influence on the service with higher time precision requirement corresponding to the vTimer interrupt.

Disclosure of Invention

The embodiment of the application mainly solves the technical problem that the prior art has larger time delay when processing the vTimer interrupt.

In a first aspect, an embodiment of the present application provides an interrupt virtualization processing method, which is applied to an electronic device, where the electronic device includes a hardware layer, and the hardware layer is provided with a conversion device and an interrupt controller, and the method includes: acquiring an interrupt request signal generated when the vTimer counter reaches a preset threshold value; converting the interrupt request signal into a Message through the conversion equipment, and sending the Message to an SOC interconnection bus; the interrupt controller detects triggering of vTimer interrupt by monitoring Message information on the SOC interconnection bus, receives the triggered vTimer interrupt through a preset interrupt software and hardware interface, identifies an interrupt number corresponding to the vTimer interrupt, and acquires a mapping relation between the interrupt number and a vCPU; and injecting the vTimer interrupt into the corresponding vCPU according to the mapping relation between the interrupt number and the vCPU so as to enable the vCPU to perform interrupt processing.

Optionally, the interrupt controller detects triggering of a vtmer interrupt by monitoring a Message on the SOC interconnection bus, receives the triggered vtmer interrupt through a preset interrupt software and hardware interface, identifies an interrupt number corresponding to the vtmer interrupt, and obtains a mapping relationship between the interrupt number and a vCPU, including: the interrupt controller monitors Message information on the SOC interconnection bus and acquires the interrupt request signal according to the Message information; the interrupt controller matches the interrupt request signal with a pre-stored mapping relation, and obtains an interrupt number corresponding to the interrupt request signal and a binding relation between the interrupt number and a corresponding vCPU according to the mapping relation.

Optionally, the converting, by the converting device, the interrupt request signal into a Message includes: when the interrupt request signal is determined to belong to a level triggering type, managing and maintaining the state of an interrupt request bit corresponding to the interrupt request signal according to a preset control mechanism; when the state of the interrupt request bit is a pending state, filtering the interrupt corresponding to the interrupt request signal; transmitting the filtered interrupt to a message finite state machine, and maintaining the life cycle of the interrupt request signal according to the message finite state machine, wherein maintaining the life cycle of the interrupt request signal comprises: and performing state conversion on the current state of the interrupt request signal and the attribute of the interrupt request, and setting a corresponding Message according to the converted state.

Optionally, the filtering the interrupt corresponding to the interrupt request signal includes: pre-configuring an address and data corresponding to an interrupt request signal in a register of the conversion equipment, wherein the data comprises an interrupt number of a vTimer interrupt corresponding to the interrupt request signal and a vCPU identification number to which the vTimer interrupt belongs; and filtering out interrupts which are not matched with the interrupt numbers stored in the register according to the interrupt numbers stored in the register.

Optionally, before executing the step of receiving the triggered vtime interrupt through a preset interrupt software and hardware interface, the method further includes: configuring the preset interrupt software and hardware interface; the configuring the preset interrupt software and hardware interface comprises the following steps: setting a part of reserved bits of the gits_vsgi interface of the device ITS to be used as new sync, clr, vtimer content; modifying the vSGI Command of the device ITS; and defining a memory use space corresponding to the state management table of the vTimer interrupt.

Optionally, the method further comprises: when the interrupt controller receives the vTimer interrupt through a preset interrupt software and hardware interface, judging whether identification information corresponding to the vTimer interrupt contains identification information of the conversion equipment, and if the identification information of the conversion equipment is not contained, not processing the vTimer interrupt.

In a second aspect, an embodiment of the present application provides an interrupt virtualization processing apparatus, which is applied to an electronic device, where the electronic device includes a hardware layer, and the hardware layer is provided with a conversion device and an interrupt controller, and the apparatus includes: the interrupt message acquisition module is used for acquiring an interrupt request signal generated when the vTimer counter reaches a preset threshold value; the interrupt Message type conversion module is used for converting the interrupt request signal into a Message through the conversion equipment and sending the Message to the SOC interconnection bus; the interrupt identification module is used for controlling the interrupt controller to detect triggering of the vTimer interrupt by monitoring Message information on the SOC interconnection bus, receiving the triggered vTimer interrupt through a preset interrupt software and hardware interface, identifying an interrupt number corresponding to the vTimer interrupt, and obtaining a mapping relation between the interrupt number and a vCPU; and the interrupt processing module is used for injecting the vTimer interrupt into the corresponding vCPU according to the mapping relation between the interrupt number and the vCPU so as to enable the vCPU to perform interrupt processing.

Optionally, the interrupt identification module is specifically configured to: controlling the interrupt controller to monitor Message information on the SOC interconnection bus, and acquiring the interrupt request signal according to the Message information; and controlling the interrupt controller to match the interrupt request signal with a pre-stored mapping relation, and acquiring an interrupt number corresponding to the interrupt request signal and a binding relation between the interrupt number and a corresponding vCPU according to the mapping relation.

Optionally, the interrupt message type conversion module is specifically configured to: when the interrupt request signal is determined to belong to a level triggering type, managing and maintaining the state of an interrupt request bit corresponding to the interrupt request signal according to a preset control mechanism; when the state of the interrupt request bit is a pending state, filtering the interrupt corresponding to the interrupt request signal; transmitting the filtered interrupt to a message finite state machine, and maintaining the life cycle of the interrupt request signal according to the message finite state machine, wherein maintaining the life cycle of the interrupt request signal comprises: and performing state conversion on the current state of the interrupt request signal and the attribute of the interrupt request, and setting a corresponding Message according to the converted state.

In a third aspect, embodiments of the present application provide an electronic device comprising at least one processor and a memory coupled to the processor, the memory for storing instructions or programs that, when executed by the at least one processor, cause the at least one processor to perform the interrupt virtualization processing method as described above.

In the embodiment of the application, the peripheral wired interrupt is converted into the hardware device of the interconnection bus Message, and the hardware device defines the states owned by the lifecycle of the wired interrupt, the conversion relation of the states and the corresponding trigger events. The hardware device can be used for meeting the requirement that all peripheral devices on a chip system are interrupted by a wired type to access an interconnection bus, can effectively reduce system interrupt wiring, and is beneficial to back-end layout wiring. The level interrupt access of the wired type is then virtualized into a design scheme of the hardware system, wherein the scheme comprises a mode of connecting the wired interrupt access chip to a bus, a message type (such as set/clr/sync message) sent on the bus, a processing behavior of the message in the hardware ITS of the interrupt controller, and a format and software configuration command of the configuration and the state of the interrupt in a memory. The configuration flow needing to be added when the virtual machine is created and the configuration flow needing to be added when the virtual machine is switched and exited are provided, and the vTimer interrupt can be directly injected into the running virtual machine through the cooperation of software and hardware without passing through an intermediate VMM layer, so that the time delay in interrupt processing is shortened, and the system performance of the computing equipment is improved.

Drawings

One or more embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which the figures of the drawings are not to scale, unless expressly stated otherwise.

Fig. 1 is a schematic diagram of an application scenario provided in an embodiment of the present application;

FIG. 2 is a flow chart of an interrupt virtualization process provided by an embodiment of the present application;

FIG. 3 is a block diagram of an implementation of the improvement of the hardware layer provided by the embodiment of the present application;

fig. 4 is a schematic diagram of a type conversion process based on a conversion device MessageGenerator according to an embodiment of the present application;

fig. 5 is a schematic diagram of a gits_vsgi interface of a modification device ITS provided in an embodiment of the present application;

FIG. 6 is a schematic diagram of a vSGI Command for modifying an ITS of a device according to an embodiment of the present application;

FIG. 7 is a flow chart of a method of interrupt virtualization processing provided by an embodiment of the present application;

FIG. 8 is a schematic structural diagram of an interrupt virtualization processing device according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present application more clear, the technical solutions of the embodiments of the present application will be clearly and specifically described below with reference to the accompanying drawings in the embodiments of the present application. It will be apparent that the embodiments described are some, but not all, of the embodiments of the present application. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.

Features described below in the various embodiments of the present application that are not in conflict with each other may be combined.

Although functional block diagrams are depicted in the device diagrams, logical sequences are shown in the flowchart, in some cases, the steps may be performed in a different order than the blocks in the device or may be performed in a different order than shown in the flowchart.

In a virtualized environment, communications and control are performed between hypervisors and virtual machines by trapping and trapping. Trapping refers to an external event or instruction in the virtual machine triggering a Hypervisor's response, causing the Hypervisor to pause the current virtual machine's operation and, in turn, execute its own code. When the Hypervisor completes the operation, it returns control to the virtual machine, which continues to execute. Trapping refers to the process by which the Hypervisor transfers control from itself back to the virtual machine. When the Hypervisor completes the operation, a trap instruction is sent to the virtual machine, so that the virtual machine restarts executing the own instruction. Communication and control between the virtual machine and the Hypervisor can be realized through trapping and out, so that isolation and allocation of resources in the virtualized environment are realized. In the related art, when an interrupt is processed, for example, a Guest OS Timer interrupt report must go through trapping and trapping of a Hypervisor, specifically, the virtual machine receives the interrupt, and transfers the interrupt to the Hypervisor, where the Hypervisor saves the state of the interrupt in the context of the virtual machine, and decides whether the interrupt needs to be transferred to the Guest OS. If the Hypervisor decides to pass the interrupt to the Guest OS, it will transfer control to the Guest OS and process the interrupt in the context of the Guest OS. In this process, two context switches are required, control is switched from the Hypervisor to the Guest OS and then back from the Guest OS to the Hypervisor. In addition, if the Hypervisor decides to handle the interrupt itself, it also needs to handle the interrupt in its own context and notify the Guest OS if necessary, which also causes a context switch. These context switches can introduce additional latency, affecting the performance of the system.

In view of this, the embodiments of the present application provide an interrupt virtualization processing method, apparatus, and computing device, which mainly solve the problem of delay caused by the fact that the related art Guest OS Timer interrupt report must go through the trap and trap. In order to solve the problem, the scheme of the embodiment of the application provides a method that virtual Timer interrupt (i.e. vtime interrupt) is directly injected into running Guest OS through combination of software and hardware, and does not need to cause toggling between the Guest OS and the Hypervisor, i.e. no trap and trap of the Hypervisor is generated.

It should be noted that the description of the embodiment of the present application focuses on the direct injection of virtual Timer interrupts into the running virtual machine. When the virtual machine is not running, the virtual timer interrupt request signal is saved in memory by the interrupt controller and is not immediately processed. The interrupt controller triggers a doorbell interrupt according to a specific configuration scene to inform the VMM that there is an interrupt request waiting to be processed. The VMM will schedule the vCPU to handle the interrupt request and resume operation of the virtual machine when appropriate, so that the virtual machine can handle and manage its internal interrupts under the management of the VMM. Among other things, a doorbell interrupt is a mechanism for quickly informing the processor and operating system of events or interrupt requests that are pending.

Specifically, referring to fig. 1, fig. 1 is a schematic diagram of an application scenario provided in an embodiment of the present application, where the interrupt virtualization processing method and apparatus may be applied to the application scenario. The application scene comprises a hardware layer, a host machine layer and a virtualization layer, wherein the virtualization layer comprises a virtual machine, and the hardware layer comprises hardware such as a processor, a memory, an interrupt controller (GIC) and the like. In other embodiments, the number of processors and the number of virtual machines may be greater, and are not limited to those shown in FIG. 1. The interrupt virtualization processing method provided by the embodiment of the application can be specifically applied to the hardware layer.

A virtual machine is one or more virtual computers that are emulated by software on a physical computer. Each virtual computer may run a separate operating system and application program as if they were running on separate physical computers, and are isolated from each other. The software, i.e., hypervisor, may divide the resources (e.g., CPU, memory, storage, etc.) of a physical computer into multiple virtual machines and provide each virtual machine with a virtual computing environment, including virtual CPU, virtual memory, virtual storage, etc. A Guest operating system (Guest Operating System, guest OS) may be installed on the virtual machine, on which one or more applications may run. The virtual machine may also access network resources. The virtual machine also includes a virtual processor (virtual Central Processing Unit, vCPU), which is a representation of a physical processing unit provided for use by the virtual machine in a shared or sliced manner. It provides a virtual CPU environment that allows virtual machines to run independent operating systems and applications as if they were running on separate physical computers. A virtual machine may include one or more vcpus, and when multiple vcpus are included, typically one of the vcpus acts as a master and the other vcpus act as slaves.

The host machine layer is used as a management layer for completing the allocation and management of hardware resources, presenting a virtual hardware platform for the virtual machine, realizing the scheduling and isolation of the virtual machine and the like. The host layer includes a host operating system and a virtual monitoring device (e.g., a virtual machine monitor (Virtual Machine Monitor, VMM) or Hypervisor), which may be deployed within the host operating system or outside the host operating system. The host layer will also be referred to herein simply as the host. It should be understood that the host shown in fig. 1 is only an example, and the host may further include other modules such as a back-end driver.

The VMM acts as a virtual monitoring device and is responsible for scheduling vcpus for each virtual machine. For example, a Kernel-based virtual machine (Kernel-based Virtual Machine, KVM) is a typical VMM. The virtual interrupt management unit is deployed in the host layer, and when the VMM is deployed on the host operating system, the virtual interrupt management unit may be deployed in the host operating system, or may be deployed in the VMM, or may be deployed in part in the host operating system, or in part in the VMM. In the embodiment of the present application, the following interrupt virtualization processing method does not involve the virtual interrupt management unit, but directly bypasses the VMM. The Host OS refers to an operating system running on a Host machine, and is responsible for managing the Host machine and providing resources for the virtual machine. Depending on the virtualization technology, virtualization systems can be divided into two types: type 1 virtualization and Type 2 virtualization. Type 1 virtualization refers to running virtual machine managers (hypervisors) directly on physical computers, with their operating systems and applications running directly on the VMM. Type 2 virtualization refers to running a VMM on a conventional operating system, with their operating systems and applications running on virtual machines in the VMM. In Type 2 virtualization, the operating system running on the Host is the Host OS shown in fig. 1, which is responsible for managing the virtualized environment and providing resources for the virtual machine. It should be noted that fig. 1 is only an example, and may be presented in other virtualization system types.

The hardware layer is the platform on which the virtualized environment operates. The hardware layer may include various hardware, for example, a hardware layer of a physical computer may include a processor and a memory, and may also include an interrupt controller (GIC), a network card, an input/output device, and the like. A processor, which may be referred to as a physical processor, includes cores, which are the smallest processing units in the processor, and registers, and 1 core is shown in fig. 1, and may have a plurality of cores, and a processor having a plurality of cores is referred to as a multi-core processor. The vCPU may be in a binding relationship with the cores, i.e., a virtual processor is fixed to run on a certain core and cannot be scheduled to run on other cores. A vCPU may also be scheduled to run on different cores as needed.

In the embodiment of the present application, the interrupt refers to a virtual interrupt triggered by vtmer. vtime is a technique that simulates a timer in a virtual machine environment, and can provide a virtual timer for a virtual machine to periodically send an interrupt signal to the virtual machine. The virtual interrupt triggered by the vtmer refers to that when the vtmer reaches a preset time point, an interrupt signal is sent to the virtual machine to inform the virtual machine to perform corresponding processing. The virtual interrupt triggered by the vtime can be used in many different scenarios, such as implementing a timer of a virtual machine, implementing task scheduling of the virtual machine, implementing network communication of the virtual machine, and the like. The virtual machine may perform some necessary operations, such as updating the state of the virtual machine, switching the context of the virtual machine, performing some background tasks, etc., with a virtual interrupt triggered by the vtime.

vTimer triggered virtual interrupts are typically implemented by a virtualization layer or Hypervisor. Hypervisor may emulate a virtual timer and periodically send interrupt signals to the virtual machine in its virtualized environment. The virtual machine may respond to these interrupt signals by interrupt handlers and perform corresponding operations. However, handling the interrupt through the virtualization layer or Hypervisor may cause a toggle between the Guest OS and Hypervisor, creating latency issues. Therefore, the embodiment of the application bypasses the interrupt to the VMM, namely bypasses the middle host layer, and can be transmitted to the corresponding vCPU only through the hardware layer, so as to solve the problem of delay.

Based on the application scenario shown in fig. 1, the hardware layer is changed mainly, so that the hardware of the hardware layer can identify the ID of the interrupt and know the binding relationship between the ID and the vCPU, and the interrupt can be transmitted to the corresponding vCPU only through the hardware layer.

Referring to fig. 2, fig. 2 is a flowchart of an interrupt virtualization process according to an embodiment of the present application. As shown in fig. 2, the bottom layer corresponds to the hardware layer in fig. 1 described above, and includes vtime (Virtual Timer), GIC (i.e., interrupt controller), and CPU. The middle layer corresponds to the host layer in fig. 1 described above, which includes a v its (Virtual Interrupt Translation Service ) and a v gic (virtual Generic Interrupt Controller, virtual general interrupt controller), both of which are interrupt controllers used in a virtualized environment. The interrupt virtualization processing method skips the VMM layer corresponding to the host layer. The uppermost layer of fig. 2 corresponds to the virtual machine in fig. 1 described above.

As shown in fig. 2, the process flow of interrupt virtualization is: the virtual interrupt of the vTimer is identified by the GIC, the GIC stores the state information of the virtual interrupt into the interrupt state register of the corresponding CPU after identifying the interrupt request, the CPU of the hardware layer can check the interrupt state register regularly, if finding the interrupt request, the control right of the interrupt request is given to the Guest OS, the GIC notifies the vCPU, and then the vCPU processes the virtual interrupt corresponding to the interrupt request.

vTimer is a Virtual Timer (Virtual Timer), and in this embodiment, vTimer is implemented as a hardware device of a hardware layer, and its implementation manner may vary according to different hardware platforms and architectures. The embodiment of the application provides an ARM architecture-oriented vTimer interrupt virtualization processing method, wherein in a Linux kernel, an interrupt number of an ARM architecture vTimer interrupt is 27. Wherein the interrupt number is used to identify the interrupt source, and when the interrupt source triggers an interrupt, the interrupt controller determines execution of the interrupt handler based on the interrupt number. When the interrupt is used, a corresponding interrupt processing program is required to be written according to a specific interrupt number so as to complete response and processing of an interrupt source.

In the ARM architecture, the following interrupt types are common:

LPI (Low Peripheral Interrupt): and the low power consumption interrupt is used for waking up the system to recover from the low power consumption state. For example, when the interrupt ID is 16 bits, interrupt numbers are allocated from 8192 to 65535, and a total of 57344 interrupt numbers are available.

SGI (Software Generated Interrupt): software-generated interrupts, generated by an operating system or application program, may be used for inter-process communication, system scheduling, and other functions. The interrupt number is distributed from 0 to 15, and total 16 interrupt numbers are distributed. An SGI interrupt is an edge-triggered interrupt, i.e., an interrupt request signal is pulsed.

PPI (Private Peripheral Interrupt): the private peripheral interrupt is generated by the peripheral device and can only be processed by a specific CPU core. Interrupt number assignments range from 16 to 31, with some interrupt numbers being used to handle specific peripheral interrupts, such as the vtmer interrupt of the present application. The PPI interrupt is a level triggered interrupt, i.e., triggered when the interrupt request signal remains high or low.

SPI (Shared Peripheral Interrupt): the shared peripheral interrupt, generated by the peripheral device, may be processed by multiple CPU cores. The interrupt number for an SPI interrupt typically starts at 32 up to the maximum interrupt number supported by the interrupt controller. In GIC, the allocation of SPI interrupt numbers is typically dynamic, i.e. allocated and managed according to the requirements and priorities of peripheral interrupts.

In a virtualized environment, a virtual machine needs to use interrupts to complete access and management of physical resources, and thus the type of interrupt in the physical machine needs to be virtualized. In the embodiment of the application, the LPI, SGI and PPI in the physical machine are virtualized by adopting the vLPI, the vSGI and the vPPI, and the use modes of the virtual machine and the virtual machine are similar to the interrupt types in the physical machine. vLPI is a low power interrupt type in a virtualized environment, corresponding to LPI. The vSGI is the type of software-generated interrupt in the virtualized environment, corresponding to the SGI. The vLPI and the vSGI are interrupt types generated by software in the current virtualized environment, and in view of the fact that vTimer interrupt belongs to PPI interrupt, based on the thought of the current interrupt protocol, the embodiment of the application provides vPPI interrupt, wherein the vPPI is a private peripheral interrupt type in the virtualized environment and corresponds to PPI.

The vTimer interrupt of the present application belongs to the PPI type, the interrupt number of the vPPI is mapped to the interrupt number 30 of the host machine (it should be noted that the interrupt number 30 is an example, and other interrupt numbers are also possible), and then the vTimer interrupt is forwarded to the interrupt number corresponding to the virtual machine by the host machine. Therefore, the embodiment of the present application configures the vtmer interrupt (interrupt number 27) to the host (interrupt number 30). When the vTimer interrupt is triggered, the message generator device and the interrupt controller detect an interrupt request corresponding to the interrupt number according to the configuration, and forward the interrupt request to the interrupt number corresponding to the virtual machine. When the virtual machine receives the interrupt request, the interrupt is transferred to the Guest OS running in the virtual machine for processing. In the Guest OS, the vtmer interrupt may be handled by registering an interrupt handler, and the time management and scheduling functions of the virtual machine may be implemented. Therefore, the virtual Timer interrupt can be directly injected into the running Guest OS, and context switching between the Guest OS and the Hypervisor is not required to be caused.

It should be noted that, the virtual Timer interrupt is directly injected into the running Guest OS, and the kernel code of the Guest OS is not modified, which is a necessary condition of the commercial virtualization technology, because the commercial virtualization technology needs to ensure stability and security of the Guest OS, and reduce interference to the Guest OS as much as possible.

In order to achieve the above objective, in the embodiment of the present application, when a virtual machine is just created, a Hypervisor calls ITS (Interrupt Translate Service) driver interfaces to notify hardware devices ITS of the mapping relationship to perform management and maintenance. In a virtualized environment, hypervisors typically need to communicate with the ITS of a hardware device through ITS driver interface to establish and maintain interrupt mappings between virtual machines and physical devices. The ITS driver interface is typically a set of APIs or SDKs provided by the hardware device vendor for enabling interaction and communication with the hardware device ITS. Hardware device ITS is a device for implementing interrupt delivery and management between virtual machines and physical devices in a virtualized environment. An ITS is typically a hardware interrupt controller, which can map an interrupt request in a virtual machine to an interrupt number corresponding to a physical device, and transfer the interrupt request to the physical device for processing. Specifically, referring to fig. 3, fig. 3 is a block diagram illustrating an implementation of the improvement of the hardware layer according to the embodiment of the present application, and the core idea is to change the maintenance position of the mapping relationship between the vtmer interrupt and the vCPU. Improvements in the hardware layer are mainly related to two aspects.

Firstly, it can be known that the vtime interrupt of the hardware device is of a type triggered by a wired level, and cannot directly access to a hardware system virtualized by the ARM platform interrupt, and the hardware system needs to be forwarded to a chip (physical CPU) of an ARM architecture for processing after being processed by the Hypervisor, however, the application needs to bypass the Hypervisor, so that a Message generator (i.e. msg_gen shown in fig. 3) of a conversion device is added in the embodiment of the application, and the behavior of the vtime level interrupt is simulated by using a Message on an SOC interconnection bus. The conversion device MessageGenerator realizes the conversion of the type corresponding to the vTimer interrupt, so that the vTimer interrupt can be ensured to be directly accessed into a hardware system of ARM platform interrupt virtualization.

The conversion device MessageGenerator is a device for simulating the vTimer level interrupt, and can generate an interrupt request signal on the SOC interconnection bus and transmit the interrupt request signal to other devices. Specifically, it may perform the following operations: when the vTimer counter reaches a preset threshold value, generating an interrupt request signal, and monitoring the state of the interrupt request signal; converting the level interrupt corresponding to the interrupt request signal into Message information, and sending the Message information to the SOC interconnection bus; the interrupt controller can detect triggering of the vTimer interrupt by monitoring Message information on the SOC interconnection bus, receives the triggered vTimer interrupt through a preset interrupt software and hardware interface, identifies an interrupt number corresponding to the vTimer interrupt, and acquires a mapping relation between the interrupt number and the vCPU; and the interrupt controller informs the vCPU according to the mapping relation, and the vCPU processes the vTimer interrupt.

In an implementation, the conversion device message generator may be a separate hardware device. It may communicate with other devices (such as an interrupt controller) through the interface of the SOC bus and use the SOC bus protocol to communicate the interrupt request signal so that the interrupt controller may capture the interrupt request signal by listening for messages on the SOC bus and execute the corresponding interrupt handler. The interrupt request signal is converted into a Message by the converting device Message generator, and the interrupt controller specifically captures the Message to obtain a vtime interrupt.

Specifically, as shown in fig. 4, fig. 4 is a schematic diagram of a process of type conversion based on a conversion device message generator according to an embodiment of the present application. The Message Configuration registers module configures a register set for a Message of the conversion device, and is used for storing a mask and an interrupt trigger type of a wire interrupt, and storing a bus address and bus data when a Message is sent, wherein the bus address and the bus data comprise a Message address, message data, mask, trigger type, command synchronization and the like. In the state maintenance process of the interrupt source in the system interrupt controller (i.e. GIC and ITS shown in fig. 3), the internal register of the interrupt controller may be used to maintain the interrupt state and configuration, or the memory (referring to the memory used to store the information related to the interrupt) may be used to make the interrupt state and configuration storage carrier. For the scenario of using memory as interrupt state maintenance, the Sync register is used to indicate whether the request to interrupt Clear completes the clearing of the pending state in the memory. Specifically, when the interrupt controller receives the interrupt request and records the interrupt request in the memory, the corresponding interrupt flag bit is set to the pending state. If the interrupt controller receives the Clear request at this time, the corresponding interrupt flag bit is cleared to cancel the triggering of the interrupt. However, because memory access is relatively slow, it may take some time to complete a request to interrupt Clear, and thus a Sync register may be used to indicate completion of Clear operations. The Sync register is a special register for recording the status of interrupt Clear operations.

Set/clear pending bit control (i.e., interrupt configuration/purge control registers) is used for the translation device to handle asynchronous wire-type lines. The processed signals are mask filtered and then enter a Message FSM (Finite State Machine) for life cycle maintenance. Wherein the life cycle maintenance specifically maintains the life cycle of the interrupt request signal, and includes: and performing state conversion on the current state of the interrupt request signal and the attribute of the interrupt request, and setting a corresponding Message according to the converted state.

Where Message FSM refers to a Message finite state machine. In a communication system, a message typically requires multiple states to complete transmission and processing, such as sending, receiving, parsing, and responding to the message. To manage these states, embodiments of the present application use a message finite state machine to describe and control the state transition process of messages. In a message finite state machine, each state has corresponding state transition conditions and actions.

For example, SET is a message SET state, ACTIVE is an ACTIVE state, deactive is a message inactive state, and IDLE is an IDLE state. When the interrupt controller receives an interrupt request, the interrupt controller enters a SET state, in the SET state, the switching device SETs a corresponding interrupt flag bit to be in a pending state, and sends a Message to the interrupt controller on the interconnection bus to enter an ACTIVE state. In the ACTIVE state, the switching device detects whether the interrupt request is invalid, and if so, the switching device sends a Message to the interrupt controller again and then enters the inactive state. In the inactive state, the IDLE state is entered after waiting for a bus response.

By using a message finite state machine, state transitions and processing of messages can be efficiently managed, thereby improving reliability and performance of the communication system.

In the embodiment of the application, the Message FSM mainly completes the task of line interrupt life cycle maintenance. The state transitions are as follows:

1. triggering an interrupt source, and transferring the state from IDLE to SET;

2. an interrupt in the SET state, application Message Master Interface uses rights, and generates a SET Message request in cooperation with data in a register ms_address (physical address of the register in memory) and ms_data (data of the register), and when the request is sent to the system interconnection bus, the state is changed from the SET to the active state;

3. at this time, if the interrupt is of the edge trigger type, after the system interconnect bus responds, it can be changed from the active state to IDLE, ending the life management cycle of the module; if the interrupt is of a level triggered type, the state remains unchanged after the system interconnect bus responds;

4. after the line level interrupt (deassert), it means that the level of the interrupt signal changes from high level to low level, that is, the interrupt signal ends, the interrupt in the active state sends a Clear Message to the interconnection bus by using ms_address and ms_data in the register again, and the state is changed into inactive;

5. After the system bus responds, the inactive state transitions to IDLE, ending the module's lifecycle.

In the embodiment of the application, the life cycle of the interrupt request is managed and controlled through the Message FSM so as to ensure the correct triggering and processing of the interrupt, thereby improving the reliability and maintainability of the interrupt and reducing the complexity and failure rate of the system.

The problem that the hardware device vTimer interrupt cannot be directly accessed to the ARM platform interrupt virtualization hardware system due to the type of wired level triggering is solved. In addition, since the current ARM latest GIC specification (the interrupt controller specification) does not support the hardware device ITS to receive the MSI interrupt (the interrupt number is 27) of the vTimer, the vSGI interrupt software and hardware interface supported by the current specification can be utilized, and the vSGI interrupt software and hardware interface is the preset interrupt software and hardware interface in the embodiment of the present application, so that the content related to the vSGI is expanded, specifically, the content is realized by modifying the gits_vsgi interface and the vSGI Command of the device ITS.

Fig. 5 is a schematic diagram of a gits_vsgi interface of a modification device ITS according to an embodiment of the present application, as shown in fig. 5. Referring to the drawings in detail, starting with 31 bits, the settings of the corresponding reserved bits in the registers are modified and a portion of the reserved bits are used as new sync, clr, vtimer content. The sync refers to whether the message sent by the message generator needs to complete the synchronous operation, so as to ensure that the hardware operation corresponding to the message is completely completed. clr refers to whether to clear the previously received vtmer interrupt request. It is not necessarily required to start with 31 bits, and other bits in RES0 may be used.

In the GITS VSGI interface, the contents of sync, clr and Vtimer are used to describe the attributes and parameters of the virtual software generated interrupt. Specifically, sync is used to describe whether the hardware operations of the interrupt need to be synchronized, to ensure that the operations are completed completely, clr is used to describe the clear operation of the interrupt, and Vtimer is used to describe whether it belongs to an interrupt request that is vtime. By setting the parameters, the precise control of the interrupt generated by the virtual software can be realized, and the correct triggering and processing of the interrupt are ensured. Therefore, the processing of the vtmer interrupt can be achieved by modifying the content of the gits_vsgi interface of the device ITS.

When the ITS processes a Clear request with a sync, it needs to ensure that this Clear request completes the complete clearing of the interrupt state, especially the scene that the interrupt state is saved in memory, when it returns a Message response to the system interconnect bus. To this end, the vSGI Command of the device ITS needs to be modified. When the ITS processes Clear requests with sync, it is important to ensure that the interrupt state is cleared completely, especially in the context of interrupt state save in memory. To achieve this goal, it is contemplated to modify the vSGI Command of the device ITS, adding the corresponding control information and parameters to ensure the correct handling of the Clear request. Specifically, a new parameter (or Command) may be added to the vSGI Command of the device ITS, to indicate that the Command is to configure the mapping relationship between the attribute of the vtmer interrupt request and the vCPU. For example, as shown in fig. 6, the command format of the command sent to the interrupt controller is modified, and the information (interrupt related information) contained in the Vtimer is written into the reserved bit RES0 of the command format, and the details are shown in the drawing, beginning with bit 63. It is not necessarily required to start with 63 bits, and other bits in RES0 may be used.

In some embodiments, a memory usage space of the state management table of the vtmer interrupt needs to be defined at the same time, where the space used by the vSGI is 0x3f0 to 0x3fc, and 0x300 can be defined as the memory usage space of the vtmer interrupt.

In some embodiments, at the system software level, the kernel only needs to support the interrupt ID of the vtmer at the vSGI related call interface, for example, the vtmer interrupt is configured when the virtual machine is created, and only needs to be determined according to the state of the vtmer bit customized in the vSGI command, and does not need to develop a special software call interface for this purpose. Wherein the vtmer bit is a control bit for indicating whether the interrupt request requires a virtual timer to be started. For example, when the vtime bit is set to 1, it indicates that the interrupt request needs to start a virtual timer to control the trigger time of the interrupt. In the initialization flow of the virtual machine, the Hypervisor configures related registers for the message generator:

when the virtual machine is initialized and the virtual machine is scheduled to run, a configuration register in the Message generation is taken as a part of the virtual machine context, and the configuration flow added for the vTimer is as follows:

(1) The ms_addr and ms_data inside the Message generator are configured, wherein ms_addr is an ITS_VSGI register address of the system interrupt controller ITS, ms_data is an interrupt ID, and a value of 30. Level register is configured as Level trigger.

(2) And calling the ITS driver, and configuring the interrupt attribute of the vTimer by using the vSGI command driver according to the defined command format.

Configuration flow of virtual machine to vTimer increase when exiting:

(1) When the virtual machine exits, a sync register of a Message generation needs to be configured to be 1, and then whether the sync is changed to be 0 needs to be queried, so that if a clear Message exists, the completion of the Message operation on the memory is ensured.

As shown in fig. 7, the flow of the interrupt virtualization processing method provided in the embodiment of the present application includes:

s101, when a Virtual Machine is created, the Hypervisor creates a Virtual CPU and other structural bodies for the Guest OS, configures information such as the mapping relation between hardware device interrupt and the vCPU to an interrupt controller for maintenance by calling an ITS (interface technology) driving interface, initializes running context related to the vTimer, and establishes the mapping relation between the vTimer context and the vCPU.

S102, performing vCPU scheduling by the Hypervisor, scheduling the vCPU to a physical CPU for execution, configuring the vTimer context to a clock device vTimer, configuring a register of a message generator to indicate the address and data of a sending message, wherein the data contains a vTimer interrupt ID and a currently-belonged vCPU ID, and enabling the vTimer interrupt ID and the currently-belonged vCPU ID to start running.

S103, the virtual machine operates normally, and at the moment, the virtual clock device vTimer counts fully to generate interrupt.

And S104, converting the interrupt generated by the vTimer into a Message interrupt Message through the Message generator, notifying the GIC after the interrupt Message is received and processed by the interrupt controller ITS, identifying the current interrupt Message and notifying the running vCPU, and sending the interrupt Message to an interrupt processing interface (virtual interrupt interface, VII) of the CPU.

S105, the vCPU receives an interrupt through the interrupt processing interface, and an interrupt service routine of the Guest OS executes the interrupt.

Among other things, virtual Interrupt Interface (VII) is a virtualization technique for providing support for interrupt handling in a virtualized environment. VII provides a unified interrupt handling interface between the CPU and the guest operating system, such that the CPU passes interrupt messages to interrupt handlers in the guest operating system through the interrupt handling interface.

In the embodiment of the application, the peripheral wired type interrupt can be converted into the hardware device of the interconnection bus Message, and the device defines the states owned by the lifecycle of the wired type interrupt, the conversion relation of the states and the corresponding trigger events. The device can be used for meeting the requirement that all peripheral devices on a chip system are interrupted by a wireless type to access an interconnection bus, can effectively reduce system interrupt wiring, and is beneficial to back-end layout wiring. The level interrupt access of the wired type may then be virtualized into a design scheme of the hardware system, which includes the manner in which the wired interrupt access chip interconnects the bus, the type of message (set/clr/sync message) sent on the bus, the handling behavior of the message in the interrupt controller hardware ITS, and the format and software configuration commands of the configuration and status of the interrupt in the memory. The configuration flow needing to be added when the virtual machine is created and the configuration flow needing to be added when the virtual machine is switched and exited are provided, and the vTimer interrupt can be directly injected into the running virtual machine through the cooperation of software and hardware without passing through an intermediate VMM layer, so that the time delay in interrupt processing is shortened, and the system performance of the computing equipment is improved.

It should be noted that, in the above embodiments of the present application, the idea of the above scheme may be extended to any external device similar to vtmer in other embodiments.

In some embodiments, to avoid the interrupt from being injected by malicious software and ensure system security, the interrupt virtualization processing method of the present application further includes: the bus operation issued by the msg_gen module carries unique identification information. When the device ITS receives the bus operation from the gits_vsgi interface and recognizes that the bus operation is a vtmer interrupt, it needs to be determined whether the identification information carried by the bus operation identifies msg_gen (i.e. contains the identification information of the conversion device), and if msg_gen is not identified, the bus operation should be ignored, i.e. the vtmer interrupt is not processed. The identification information of the conversion device is used for identifying an interrupt request signal processed by the conversion device, and if the interrupt request signal is not converted into a Message by the conversion device, the interrupt request signal is not processed and is considered as an interrupt request signal injected by malicious software.

As shown in fig. 8, fig. 8 is a schematic structural diagram of an interrupt virtualization processing device according to an embodiment of the present application. The interrupt virtualization processing apparatus 200 includes:

An interrupt message obtaining module 201, configured to obtain an interrupt request signal generated when the vtmer counter reaches a preset threshold;

an interrupt Message type conversion module 202, configured to convert, by the conversion device, the interrupt request signal into a Message, and send the Message to an SOC interconnection bus;

the interrupt identification module 203 is configured to control the interrupt controller to detect triggering of a vtmer interrupt by monitoring a Message on the SOC interconnection bus, receive the triggered vtmer interrupt through a preset interrupt software and hardware interface, identify an interrupt number corresponding to the vtmer interrupt, and obtain a mapping relationship between the interrupt number and a vCPU;

the interrupt processing module 204 is configured to control the interrupt controller to receive the vtime interrupt through a preset interrupt software and hardware interface, and inject the vtime interrupt into a corresponding vCPU according to a mapping relationship between the interrupt number and the vCPU, so that the vCPU performs interrupt processing.

It should be noted that, the interrupt virtualization processing apparatus 200 provided in the embodiment of the present application has the same inventive concept and beneficial effects as the above embodiment, and reference is made to the above embodiment in detail.

Fig. 9 shows a hardware structure of the electronic device. Referring to fig. 9, the electronic device 100 includes a processor 10, a memory 20, an interrupt controller 30 and a vtmer counter 40, where the processor 10, the memory 20, the interrupt controller 30 and the vtmer counter 40 are connected by lines, and in the embodiment shown in fig. 9, the processor 10, the memory 20, the interrupt controller 30 and the vtmer counter 40 are connected by buses.

The memory 20 is used to store software programs, computer-executable program instructions, and the like. The memory 20 may include a storage program area that may store an operating system, at least one application program required for functions, and a storage data area; the storage data area may store data created according to the use of the electronic device, etc.

The memory 20 may be any other type of static memory device capable of storing static information and instructions, may be any random access memory (random accessmemory, RAM), may be any other type of dynamic memory device capable of storing information and instructions, and may be any electrically erasable programmable read-only memory (EEPROM), which is not limited herein. The aforementioned memory 20 may be, for example, a double rate synchronous dynamic random access memory DDR sdram (DDR for short). The memory 20 may exist separately but be connected to the processor 10. Alternatively, the memory 20 may be integral to the processor 10. For example, integrated within one or more chips.

In some embodiments, memory 20 may optionally include memory located remotely from processor 10, which may be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The processor 10 connects the various parts of the overall electronic device 100 using various interfaces and lines, performs various functions of the electronic device and processes data, such as implementing the methods described in any of the embodiments of the present application, by running or executing software programs stored in the memory 20, and invoking data stored in the memory 20.

The processor 10 may be a Central Processing Unit (CPU) or the like.

Processor 10 may be a single-core processor or a multi-core processor. Furthermore, processor 10 may refer to one or more devices, circuitry, and/or processing cores for processing data (e.g., computer program instructions). The processor 10 may be a single semiconductor chip, or may be integrated with other circuitry into a single semiconductor chip, for example, may form a system-on-a-chip (SoC) with other circuitry (e.g., codec circuitry, hardware accelerator circuitry, or various buses and interface circuitry), or may be integrated into the ASIC as a built-in processor of an application specific integrated circuit (app 1ication specific integrated circuit, ASIC), which may be packaged separately or with other circuitry.

The interrupt controller 30 and the vtmer counter 40 may refer to the above embodiments, which cooperate with the processor 10 and the memory 20 respectively to implement the interrupt virtualization processing method of the embodiments of the present application.

The electronic device provided by the embodiment of the application may be specifically a computer device, a server or other electronic devices with data interaction function.

Embodiments of the present application also provide a computer storage medium storing instructions or a program that are executable by one or more processors, such as the one processor 10 in fig. 9, to enable the one or more processors to perform the interrupt virtualization processing method in any of the method embodiments described above.

Embodiments of the present application also provide a computer program product comprising a computer program stored on a computer storage medium, the computer program comprising a program or instructions which, when executed by an electronic device, cause the electronic device to perform the interrupt virtualization processing method of any one of the embodiments described above.

It should be noted that the above-described apparatus embodiments are merely illustrative, and the units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (such as RAM, magnetic disk, optical disk), including several instructions for causing a terminal (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the method described in the embodiments of the present application.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; the technical features of the above embodiments or in the different embodiments may also be combined within the idea of the invention, the steps may be implemented in any order, and there are many other variations of the different aspects of the invention as described above, which are not provided in detail for the sake of brevity; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the invention.

Claims

1. An interrupt virtualization processing method is applied to electronic equipment, the electronic equipment comprises a hardware layer, and the hardware layer is provided with a conversion device and an interrupt controller, and is characterized in that the method comprises the following steps:

acquiring an interrupt request signal generated when the vTimer counter reaches a preset threshold value;

converting the interrupt request signal into a Message through the conversion equipment, and sending the Message to an SOC interconnection bus;

the interrupt controller detects triggering of vTimer interrupt by monitoring Message information on the SOC interconnection bus, receives the triggered vTimer interrupt through a preset interrupt software and hardware interface, identifies an interrupt number corresponding to the vTimer interrupt, and acquires a mapping relation between the interrupt number and a vCPU;

and injecting the vTimer interrupt into the corresponding vCPU according to the mapping relation between the interrupt number and the vCPU so as to enable the vCPU to perform interrupt processing.

2. The method of claim 1, wherein the interrupt controller detects triggering of a vtmer interrupt by monitoring a Message on the SOC interconnect bus, receives the triggered vtmer interrupt through a preset interrupt software and hardware interface, identifies an interrupt number corresponding to the vtmer interrupt, and obtains a mapping relationship between the interrupt number and vCPU, including:

The interrupt controller monitors Message information on the SOC interconnection bus and acquires the interrupt request signal according to the Message information;

the interrupt controller matches the interrupt request signal with a pre-stored mapping relation, and obtains an interrupt number corresponding to the interrupt request signal and a binding relation between the interrupt number and a corresponding vCPU according to the mapping relation.

3. The method according to claim 1, wherein said converting, by the converting device, the interrupt request signal into a Message, comprises:

when the interrupt request signal is determined to belong to a level triggering type, managing and maintaining the state of an interrupt request bit corresponding to the interrupt request signal according to a preset control mechanism;

when the state of the interrupt request bit is a pending state, filtering the interrupt corresponding to the interrupt request signal;

transmitting the filtered interrupt to a message finite state machine, and maintaining the life cycle of the interrupt request signal according to the message finite state machine, wherein maintaining the life cycle of the interrupt request signal comprises: and performing state conversion on the current state of the interrupt request signal and the attribute of the interrupt request, and setting a corresponding Message according to the converted state.

4. A method according to claim 3, wherein filtering interrupts corresponding to the interrupt request signal comprises:

pre-configuring an address and data corresponding to an interrupt request signal in a register of the conversion equipment, wherein the data comprises an interrupt number of a vTimer interrupt corresponding to the interrupt request signal and a vCPU identification number to which the vTimer interrupt belongs;

and filtering out interrupts which are not matched with the interrupt numbers stored in the register according to the interrupt numbers stored in the register.

5. The method according to any one of claims 1 to 4, wherein prior to performing the step of receiving the triggered vtime interrupt via a preset interrupt hardware and software interface, the method further comprises: configuring the preset interrupt software and hardware interface;

the configuring the preset interrupt software and hardware interface comprises the following steps:

setting a part of reserved bits of the gits_vsgi interface of the device ITS to be used as new sync, clr, vtimer content;

modifying the vSGI Command of the device ITS;

and defining a memory use space corresponding to the state management table of the vTimer interrupt.

6. The method of claim 5, wherein the method further comprises:

When the interrupt controller receives the vTimer interrupt through a preset interrupt software and hardware interface, judging whether identification information corresponding to the vTimer interrupt contains identification information of the conversion equipment, and if the identification information of the conversion equipment is not contained, not processing the vTimer interrupt.

7. An interrupt virtualization processing apparatus applied to an electronic device, the electronic device including a hardware layer, the hardware layer being provided with a conversion device and an interrupt controller, the apparatus comprising:

the interrupt message acquisition module is used for acquiring an interrupt request signal generated when the vTimer counter reaches a preset threshold value;

the interrupt Message type conversion module is used for converting the interrupt request signal into a Message through the conversion equipment and sending the Message to the SOC interconnection bus;

the interrupt identification module is used for controlling the interrupt controller to detect triggering of the vTimer interrupt by monitoring Message information on the SOC interconnection bus, receiving the triggered vTimer interrupt through a preset interrupt software and hardware interface, identifying an interrupt number corresponding to the vTimer interrupt, and obtaining a mapping relation between the interrupt number and a vCPU;

And the interrupt processing module is used for injecting the vTimer interrupt into the corresponding vCPU according to the mapping relation between the interrupt number and the vCPU so as to enable the vCPU to perform interrupt processing.

8. The apparatus of claim 7, wherein the interrupt identification module is specifically configured to:

controlling the interrupt controller to monitor Message information on the SOC interconnection bus, and acquiring the interrupt request signal according to the Message information;

and controlling the interrupt controller to match the interrupt request signal with a pre-stored mapping relation, and acquiring an interrupt number corresponding to the interrupt request signal and a binding relation between the interrupt number and a corresponding vCPU according to the mapping relation.

9. The apparatus of claim 7, wherein the interrupt message type conversion module is specifically configured to:

10. An electronic device, comprising:

at least one processor and memory;

the memory is coupled to the processor, the memory being configured to store instructions or programs that, when executed by the at least one processor, cause the at least one processor to perform the interrupt virtualization processing method of any one of claims 1 to 6.