Method and apparatus for interrupt processing based on virtual machine monitor, terminal device and chip

Abstract

The application discloses a virtual machine monitor-based interrupt processing method and device, a terminal device and a chip. The method comprises the following steps: an arbitrator arranged in a privileged virtual machine (VM) configures an interrupt use right for a non-privileged VM; and a virtual machine monitor establishes a pass-through between the non-privileged VM and a physical peripheral according to the interrupt use right of the non-privileged VM. The application can improve the efficiency of interrupt response based on the virtual machine monitor, and improve the flexibility of the pass-through function between the VM and the physical peripheral.

Description

Technical Field

[0001] This application relates to the field of virtual machine technology, specifically to an interrupt handling method and apparatus based on a virtual machine monitor. Background Technology

[0002] A hypervisor, also known as a virtual machine monitor (VMM), is software, firmware, or hardware used to create and run virtual machines. Through a hypervisor, available system resources can be utilized more fully, and the mobility of internet technologies can be improved. A hypervisor can directly manage physical devices and support virtual machines (VMs) running on top of it, providing services to VMs through interfaces provided by the hypervisor. A VM, also known as a guest operating system, is an operating system that runs within the hypervisor. This contrasts with the host operating system, which is the system installed on the hardware device.

[0003] In existing technologies, when a hypervisor receives a hardware interrupt, the common approach is to determine which VM is causing the interrupt by checking relevant registers, and then distribute the virtual interrupt to the corresponding VM. This method essentially involves the hypervisor taking over the hardware interrupt and then supplying it to the upper-layer VM virtualization interrupt.

[0004] In hypervisors, passthrough refers to directly assigning a device to a virtual machine (VM), allowing the VM to access the physical device directly without going through the hypervisor or being intercepted by it. Current hypervisor implementations of passthrough configure the VM during creation using a specific configuration file, specifically configuring the virtual interrupt number for each VM. Once configured, this cannot be changed later. While there are interfaces for dynamically assigning virtual interrupts, these require the physical interrupt number and the virtual interrupt number to be the same.

[0005] Existing interrupt response handling methods based on Hypervisor not only require context switching, which is inefficient, but also cannot be adjusted once the virtual interrupt number corresponding to each VM is configured, resulting in poor flexibility. Summary of the Invention

[0006] This application provides an interrupt handling method and apparatus based on a virtual machine monitor to improve the efficiency of interrupt response and enhance the flexibility of the pass-through function between the VM and physical peripherals.

[0007] To address the aforementioned technical problems, the embodiments of this application provide the following technical solutions:

[0008] On one hand, embodiments of this application provide an interrupt handling method based on a virtual machine monitor, the method comprising:

[0009] Configure the arbitrator in the privileged virtual machine (VM) to grant interrupt usage rights to the non-privileged VM;

[0010] The virtual machine monitor establishes a passthrough between the non-privileged VM and the physical peripheral based on the interrupt usage rights of the non-privileged VM.

[0011] Optionally, the method further includes:

[0012] Create VMs, and arbitrarily select one VM from the created VMs as the privileged VM, and designate the other VMs as non-privileged VMs.

[0013] Optionally, the arbitrator configures interrupt usage rights for non-privileged VMs, including:

[0014] The arbitrator receives a first VM's request to use the first interrupt, where the first VM is any one of the non-privileged VMs;

[0015] If the first interrupt is not currently being used by other VMs, then configure the first VM with permission to use the first interrupt.

[0016] Optionally, the method further includes: after the arbitrator configures the usage permission of the first interrupt for the first VM, it marks the first interrupt as used, and after receiving a notification from the first VM that the use of the first interrupt has been completed, it marks the first interrupt as unused.

[0017] Optionally, the method further includes: the arbitrator pre-extracts the interrupt configuration information corresponding to each non-privileged VM from the configuration file, and migrates the interrupt configuration information to the dynamically executable API of the non-privileged VM;

[0018] The arbiter configures the first VM's access rights for the first interrupt, including:

[0019] The arbitrator obtains the interrupt configuration information of the first VM by making a super call to the dynamically executable application programming interface (API) of the first VM;

[0020] If the first interrupt is not present in the interrupt configuration information of the first VM, then the first interrupt is added to the interrupt configuration information.

[0021] Optionally, configuring interrupt usage rights for VMs by the arbitrator further includes: when the arbitrator simultaneously receives usage requests for the first interrupt from the first VM and the second VM, and the first interrupt is not currently being used by other VMs, configuring usage rights for the first interrupt for the VM with the higher priority among the first VM and the second VM, wherein the second VM is any of the non-privileged VMs.

[0022] On the other hand, embodiments of this application also provide an interrupt handling device based on a virtual machine monitor, the device comprising: a virtual machine monitor, a privileged VM, and one or more non-privileged VMs; the privileged VM is provided with an arbitrator;

[0023] The arbitrator is used to configure interrupt usage permissions for the non-privileged VM;

[0024] The virtual machine monitor is used to establish pass-through between the non-privileged VM and the physical peripherals based on the interrupt usage rights of the non-privileged VM.

[0025] Optionally, the apparatus further includes: a VM creation module, configured to create VMs, and arbitrarily select one VM from the created VMs as a privileged VM, and designate other VMs besides the privileged VM as non-privileged VMs.

[0026] Optionally, the arbitrator is configured to receive a request from the first VM to use the first interrupt, and, if the first interrupt is not currently being used by other VMs, configure the first VM to have permission to use the first interrupt; the first VM is any of the non-privileged VMs.

[0027] Optionally, an interrupt configuration processor is provided in the privileged VM, and an interrupt configuration requester is provided in the non-privileged VM;

[0028] The first VM sends the request to use the first interrupt to the arbitrator through the interrupt configuration requester in the first VM;

[0029] The arbitrator configures the first VM's access rights to the first interrupt through the interrupt configuration processor.

[0030] Optionally, the arbitrator is further configured to, after configuring the usage permission of the first interrupt for the first VM, mark the first interrupt as used, and after receiving a notification from the first VM that the use of the first interrupt has been completed, mark the first interrupt as unused.

[0031] Optionally, the arbitrator is further configured to extract interrupt configuration information corresponding to each non-privileged VM from the configuration file in advance, and to transfer the interrupt configuration information to the dynamically executable application programming interface (API) of the non-privileged VM through the interrupt configuration requester in the non-privileged VM.

[0032] The arbitrator obtains the interrupt configuration information of the first VM by making a super call to the dynamically executable API of the first VM, and adds the first interrupt to the interrupt configuration information if the first interrupt is not present in the interrupt configuration information of the first VM.

[0033] Optionally, the arbitrator is further configured to, when simultaneously receiving requests from the first VM and the second VM to use the first interrupt, and the first interrupt is not currently being used by other VMs, configure the VM with the higher priority among the first VM and the second VM to use the first interrupt, wherein the second VM is any of the non-privileged VMs.

[0034] On the other hand, embodiments of this application also provide a terminal device, which includes the interrupt handling device based on the virtual machine monitor described above.

[0035] On the other hand, embodiments of this application also provide a chip, which includes the aforementioned interrupt handling device based on a virtual machine monitor.

[0036] On the other hand, embodiments of this application also provide a computer-readable storage medium, which is a non-volatile storage medium or a non-transient storage medium, on which a computer program is stored, and the computer program, when run by a processor, causes the aforementioned method to be executed.

[0037] On the other hand, embodiments of this application also provide an interrupt handling apparatus based on a virtual machine monitor, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and when the processor runs the computer program, the aforementioned method is executed.

[0038] The interrupt handling method and apparatus based on a virtual machine monitor provided in this application establishes a privileged virtual machine (VM) and an arbitrator within it. The arbitrator then configures interrupt usage permissions for a non-privileged VM. The virtual machine monitor establishes pass-through between the non-privileged VM and the physical peripheral based on these permissions. This technical solution eliminates the need for virtualization of interrupts and layer-by-layer transmission through the GIC, achieving pass-through between the VM and physical peripherals, effectively saving processor time and improving interrupt response efficiency.

[0039] Furthermore, the interrupt configuration information is ported to the dynamically executable application programming interface (API) of each VM, enabling dynamic changes to the VM interrupt configuration information and effectively improving the flexibility of interrupt response. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the existing Hypervisor-based interrupt response process;

[0041] Figure 2 This is a schematic diagram of the existing Hypervisor-based interrupt virtualization process;

[0042] Figure 3 This is a flowchart of an interrupt handling method based on a virtual machine monitor according to an embodiment of this application;

[0043] Figure 4 This is a flowchart illustrating how the arbitrator configures interrupt usage permissions for a non-privileged VM in an embodiment of this application.

[0044] Figure 5 This is a schematic diagram of an interrupt handling device based on a virtual machine monitor according to an embodiment of this application;

[0045] Figure 6 This is a schematic diagram of a specific application structure of the interrupt handling device based on the virtual machine monitor in this application embodiment. Detailed Implementation

[0046] To make the above-mentioned objectives, features and beneficial effects of this application more apparent and understandable, the specific embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0047] The following is a brief description of the existing Hypervisor interrupt response process.

[0048] In existing technologies, passthrough in the hypervisor involves reading a .cfg configuration file, finding the VM corresponding to the interrupt number, and then the VM calling the hypervisor's hypercall to configure the GIC and start the corresponding VM. The interrupt numbers for each VM in the configuration file are static and cannot be dynamically adjusted. If an interrupt corresponding to a particular VM is to be used by other VMs, virtualization must be performed.

[0049] like Figure 1The diagram illustrates an existing Hypervisor-based interrupt response process. When a physical peripheral generates an interrupt signal, the signal is sent to the Generic Interrupt Controller (GIC). The GIC's internal Distributor sends an Interrupt Request (IRQ) to the CPU interface. At this point, the CPU exits the Guest OS and returns to the Host OS, jumping to Hypervisor mode. The Host OS then responds to the interrupt signal, performs IRQ allocation, writes a virtual interrupt request (vIRQ) to the ListRegister, and sends the virtual IRQ to the vCPU for processing via the virtual CPU (vCPU) interface. The vCPU is the CPU within the virtual machine; in other words, the vIRQ is injected into the corresponding VM.

[0050] The following is combined with Figure 2 Explain the traditional interrupt virtualization process. For example... Figure 2 As shown, taking an eight-core CPU as an example, after the GIC receives an interrupt signal, the allocator inside the GIC distributes the interrupt to the corresponding CPU interface. The CPU interface corresponds one-to-one with the CPU core. Different VMs run on different CPU cores. The number of VMs running on each CPU core is different. The Hypervisor determines which specific CPU core a VM runs on.

[0051] Suppose interrupt number 56 is configured for Core 1 and used by VM2. If VM3 also wants to use this interrupt, because VM2 and VM3 are running on different CPU cores, the Hypervisor determines from its configuration file that it cannot send this interrupt to VM3. Therefore, it forwards this interrupt to the GIC for reconfiguration. The allocator in the GIC assigns a virtual interrupt number to this interrupt and then forwards the corresponding vIRQ to the vCPU3 corresponding to VM3. vCPU3 then sends the vIRQ to VM3.

[0052] It is evident that the existing interrupt response method not only requires context switching, consuming a significant amount of processor time, but also lacks flexibility because the passthrough object cannot be dynamically modified after the VM is created.

[0053] Therefore, this application provides an interrupt handling method and apparatus based on a virtual machine monitor. By setting up a privileged VM and an arbitrator in the privileged VM, the arbitrator is used to configure interrupt usage permissions for a non-privileged VM. The virtual machine monitor establishes a pass-through between the non-privileged VM and the physical peripheral based on the interrupt usage permissions of the non-privileged VM.

[0054] like Figure 3As shown, Figure 3 This is a flowchart of an interrupt handling method based on a virtual machine monitor according to an embodiment of this application.

[0055] The interrupt handling method based on the virtual machine monitor provided in this embodiment includes the following steps:

[0056] In step 301, the arbitrator in the privileged VM is configured to grant interrupt usage rights to the non-privileged VM.

[0057] The privileged and non-privileged VMs can be defined when the VMs are created. For example, one VM can be arbitrarily selected from the created VMs as the privileged VM, and the other VMs can be designated as non-privileged VMs. It should be noted that in practical applications, there can be one or more non-privileged VMs.

[0058] The VM can be created using existing technologies, and this application does not limit the specific methods used in the embodiments.

[0059] It should be noted that in the following description, unless otherwise specified, a VM refers to a non-privileged VM.

[0060] The arbitrator is also established in the privileged VM after the VM is created, and its functions are as follows:

[0061] 1) Determine whether an interrupt can be used by the VM based on the VM's interrupt configuration information;

[0062] 2) Determine whether an interrupt can be used by a VM based on the current status of the interrupt.

[0063] A virtual machine (VM) needs to request access to interrupts from the arbitrator. Upon receiving a VM's request for an interrupt, the arbitrator determines whether the VM can use the interrupt based on its current status and the VM's interrupt configuration information, and then configures the interrupt accordingly. The specific process of the arbitrator configuring interrupts will be explained in detail later.

[0064] In step 302, the virtual machine monitor establishes a passthrough between the non-privileged VM and the physical peripheral based on the interrupt access permissions of the non-privileged VM.

[0065] Specifically, when a physical peripheral generates an interrupt signal, the interrupt signal is sent to the interrupt controller. The interrupt controller then sends an interrupt allocation request to the virtual machine monitor, which includes the corresponding interrupt number. Upon receiving the interrupt allocation request, the virtual machine monitor determines the VM corresponding to the interrupt number based on the interrupt configuration information of each VM, and establishes a passthrough between that VM and the physical peripheral through a hypercall.

[0066] This application embodiment is based on an interrupt handling method of a virtual machine monitor. By setting up a privileged VM and an arbitrator in the privileged VM, the arbitrator is used to configure interrupt usage permissions for a non-privileged VM. The virtual machine monitor establishes a direct connection between the non-privileged VM and the physical peripheral based on the interrupt usage permissions of the non-privileged VM. This achieves direct connection between the VM and the physical peripheral without the need for virtualization processing of interrupts and layer-by-layer propagation by the GIC, effectively saving processor time and improving interrupt response efficiency.

[0067] Furthermore, in another embodiment of the interrupt handling method based on the virtual machine monitor in this application, the interrupt configuration information can be ported to the dynamically executable API of each VM, enabling dynamic modification of the VM interrupt configuration information and thus improving the flexibility of interrupt response. Specifically, privileged VMs can pre-extract the interrupt configuration information corresponding to each non-privileged VM from the configuration file and port the corresponding interrupt configuration information to the dynamically executable API of the non-privileged VM. In this way, after the arbitrator receives a VM's request to use an interrupt, it can obtain the interrupt configuration information of the VM by super-calling the VM's dynamically executable API, and then modify the interrupt configuration information to enable the VM to obtain the right to use the interrupt, thereby dynamically establishing pass-through between the VM and physical peripherals.

[0068] The following section uses any non-privileged VM as an example to explain in detail the process by which the arbitrator configures interrupt access rights for that VM. For ease of description, the VM requesting interrupt access rights will be referred to as the first VM.

[0069] like Figure 4 The diagram shown is a flowchart illustrating how the arbitrator configures interrupt usage permissions for a non-privileged VM in an embodiment of this application.

[0070] In step 401, the arbitrator receives the first VM's request to use the first interrupt.

[0071] In step 402, determine whether the first interrupt is currently being used by another VM. If so, proceed to step 403; otherwise, proceed to step 404.

[0072] For example, the arbiter can maintain a hash table to record which interrupts have been configured to be passed through to a specific VM. Each time the arbiter receives a VM's request to use an interrupt, it only needs to access this hash table to determine if the interrupt is already being used by another VM. For instance, after configuring the first VM's access to the first interrupt, the arbiter marks the first interrupt as used. Furthermore, after the first VM has finished using the first interrupt, it sends a notification to the arbiter indicating completion of its use of the first interrupt. Upon receiving this notification, the arbiter marks the first interrupt as unused, so that if other VMs subsequently require the first interrupt, the arbiter can configure it to be used by those VMs.

[0073] In step 403, the first VM is disabled from using the first interrupt.

[0074] Specifically, for example, corresponding feedback information can be returned to the first VM to indicate that the first VM is prohibited from using the first interrupt. Of course, there are other processing methods, which are not limited in this embodiment.

[0075] In step 404, the arbitrator obtains the interrupt configuration information of the first VM by super-calling the dynamically executable API of the first VM, and adds the first interrupt to the interrupt configuration information if the first interrupt is not present in the interrupt configuration information of the first VM.

[0076] It should be noted that the interrupt configuration information for each VM can include the interrupt numbers of all interrupts that VM can use. Each VM can correspond to one or more interrupt numbers, meaning it can have access to multiple different interrupts.

[0077] Furthermore, considering that multiple different VMs may need to use the same interrupt in practical applications, to avoid conflicts, the interrupt usage permission can be allocated according to the VM's priority. Specifically, when the arbitrator simultaneously receives usage requests for the first interrupt from the first VM and the second VM, and the first interrupt is not currently being used by other VMs, it configures the VM with the higher priority to use the first interrupt. The second VM can be any of the non-privileged VMs. Of course, usage requests from lower-priority VMs can be placed in a queue and waited for the higher-priority VM to finish using the interrupt before configuring it for the lower-priority VM.

[0078] In addition, if the arbitrator receives requests from different VMs of the same priority to use the same interrupt at the same time, it can allocate the interrupt to any of the VMs, or select according to other discrimination conditions. This application embodiment does not limit this.

[0079] Accordingly, embodiments of this application also provide an interrupt handling device based on a virtual machine monitor, such as... Figure 5 The diagram shown is a structural schematic of the device.

[0080] The device includes: a virtual machine monitor 50, a privileged virtual machine (VM), and one or more non-privileged VMs. The privileged VMs include, for example: Figure 5 VM0 in the system contains an arbitrator. Figure 5 The example shows two non-privileged VMs, namely VM1 and VM2. Of course, the number of non-privileged VMs can be set according to the actual application needs, and this embodiment does not limit this.

[0081] In this embodiment, the arbitrator is used to configure interrupt access permissions for the non-privileged VM; the virtual machine monitor 50 is used to establish pass-through between the non-privileged VM and the physical peripherals based on the interrupt access permissions of the non-privileged VM.

[0082] Furthermore, the apparatus may also include: a VM creation module (not shown), used to create VMs, and arbitrarily select one VM from the created VMs as a privileged VM, and treat other VMs besides the privileged VM as non-privileged VMs.

[0083] In a non-limiting embodiment of the interrupt handling apparatus based on the virtual machine monitor in this application, the arbitrator 50 receives a request from a first VM to use a first interrupt, and configures the first VM to have permission to use the first interrupt if the first interrupt is not currently being used by other VMs; the first VM is any of the non-privileged VMs.

[0084] Furthermore, in specific applications, such as Figure 6 As shown, the privileged VM may also be configured with an interrupt configuration processor (Allocator-BE), while the non-privileged VM may be configured with an interrupt configuration requester (Allocator-FE).

[0085] In this embodiment, assuming VM1 needs to use the first interrupt, VM1 sends the request to use the first interrupt to the arbitrator in VM0 through the interrupt configuration requester in VM1. Accordingly, the arbitrator configures the usage rights of the first interrupt for VM1 through the interrupt configuration processor in VM0.

[0086] This application embodiment is based on an interrupt handling device of a virtual machine monitor. By setting up a privileged VM and an arbitrator in the privileged VM, the arbitrator is used to configure interrupt usage permissions for non-privileged VMs. The virtual machine monitor establishes a direct connection between the non-privileged VM and the physical peripheral based on the interrupt usage permissions of the non-privileged VM. This achieves direct connection between the VM and the physical peripheral without the need for virtualization processing of interrupts and layer-by-layer transmission through the GIC, effectively saving processor time and improving interrupt response efficiency.

[0087] Furthermore, in Figure 6 In the illustrated embodiment, the arbitrator is further configured to extract interrupt configuration information corresponding to each non-privileged VM from the configuration file in advance, and then process the interrupt configuration information through the non-privileged VM (i.e., ... Figure 6 The interrupt configuration requester in VM1 and VM2 migrates the interrupt configuration information to the dynamically executable API of the non-privileged VM.

[0088] Accordingly, the arbitrator can obtain the interrupt configuration information of VM1 by super-calling the dynamically executable API of VM1, and add the first interrupt to the interrupt configuration information if the first interrupt is not present in the interrupt configuration information of VM1.

[0089] Furthermore, the arbitrator is also used to mark the interrupt as used after configuring the corresponding interrupt usage rights for the VM, and to mark the interrupt as unused after receiving a notification from the VM that the use of the interrupt has been completed.

[0090] The following will continue to combine Figure 6 Explain the interrupt response process.

[0091] When a physical peripheral device generates an interrupt signal, the interrupt controller sends the interrupt signal to the Hypervisor through the interrupt controller driver. The Hypervisor calls the interrupt configuration processor in VM0 via a super call. The interrupt configuration processor calls the dynamically executable API of each VM to obtain the interrupt configuration information of each VM. Based on the interrupt configuration information of each VM, it determines the VM corresponding to the interrupt signal and then sends the interrupt signal to the corresponding VM, thereby establishing a pass-through between the VM and the physical peripheral device.

[0092] It should be noted that, considering that in practical applications, multiple different VMs may need to use the same interrupt, in order to avoid conflicts, in a non-limiting embodiment of the interrupt handling device based on the virtual machine monitor in this application, the arbitrator can also be used to configure the usage permission of the first interrupt for the VM with higher priority among VM1 and VM2 when both VM1 and VM2 simultaneously receive requests to use the first interrupt and the first interrupt is not currently being used by other VMs.

[0093] The priority of different VMs can be set when the VM is created. The priority level can be determined according to the functions of different VMs, etc., and this application does not limit this.

[0094] In addition, if the arbitrator receives requests from different VMs of the same priority to use the same interrupt at the same time, it can allocate the interrupt to any of the VMs, or select according to other discrimination conditions. This application embodiment does not limit this.

[0095] The interrupt handling method and apparatus based on the virtual machine monitor provided in this application can realize dynamic changes of the pass-through object without virtualizing the interrupt or passing it through layers of GIC, which greatly saves processor time and improves interrupt response efficiency and flexibility.

[0096] It should be noted that existing hypervisors can be divided into two main categories: Type 1 and Type 2. Type 1 hypervisors run directly on the physical hardware, while Type 2 hypervisors run within another operating system (also running on the physical hardware). The interrupt handling method and apparatus based on the virtual machine monitor provided in this application are applicable to both types of hypervisors.

[0097] In specific implementations, the aforementioned interrupt handling device based on the virtual machine monitor can correspond to a chip with a corresponding function in network devices and / or terminal devices, such as a SOC (System-On-a-Chip), a baseband chip, a chip module, etc.

[0098] In specific implementation, the modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both.

[0099] For example, for various devices and products applied to or integrated into a chip, each module / unit can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, each module / unit can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0100] This application also provides a computer-readable storage medium, which is a non-volatile or non-transient storage medium, storing a computer program thereon. When the computer program is run by a processor, it executes the steps in the above-described method embodiments.

[0101] This application also provides an interrupt handling device based on a virtual machine monitor, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor runs the computer program, it executes the steps in the above-described method embodiments.

[0102] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article indicates that the preceding and following related objects have an "or" relationship.

[0103] In the embodiments of this application, "multiple" refers to two or more.

[0104] The descriptions of "first," "second," etc., appearing in the embodiments of this application are for illustrative purposes and to distinguish the objects being described. They have no order and do not indicate any special limitation on the number of devices in the embodiments of this application, nor do they constitute any limitation on the embodiments of this application.

[0105] The embodiments provided in this application can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0106] In the several embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, and systems can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for example, the division of units is merely a logical functional division, and other division methods may exist in actual implementation; for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0107] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0108] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can be physically arranged separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0109] While this application discloses the above information, it is not limited thereto. Any person skilled in the art can make various modifications and alterations without departing from the spirit and scope of this application; therefore, the scope of protection of this application shall be determined by the scope defined in the claims.

Claims

1. An interrupt handling method based on a virtual machine monitor, characterized in that, The method includes: An arbitrator set in a privileged virtual machine (VM) configures interrupt usage permissions for a non-privileged VM, including: the arbitrator receiving a request from a first VM to use a first interrupt, where the first VM is any of the non-privileged VMs; if the first interrupt is not currently being used by other VMs, then configuring usage permissions for the first interrupt for the first VM; after configuring usage permissions for the first interrupt for the first VM, the arbitrator marks the first interrupt as used, and after receiving a notification that the first VM has completed using the first interrupt, marks the first interrupt as unused; The virtual machine monitor establishes a passthrough between the non-privileged VM and the physical peripherals based on the interrupt usage rights of the non-privileged VM.

2. The method according to claim 1, characterized in that, The method further includes: Create VMs, and arbitrarily select one VM from the created VMs as the privileged VM, and designate the other VMs as non-privileged VMs.

3. The method according to claim 1, characterized in that, The method further includes: the arbitrator pre-extracts the interrupt configuration information corresponding to each non-privileged VM from the configuration file, and migrates the interrupt configuration information to the dynamically executable API of the non-privileged VM; The arbitrator configures the first VM's access rights for the first interrupt, including: The arbitrator obtains the interrupt configuration information of the first VM by making a super call to the dynamically executable application programming interface (API) of the first VM; If the first interrupt is not present in the interrupt configuration information of the first VM, then the first interrupt is added to the interrupt configuration information.

4. The method according to any one of claims 1 to 3, characterized in that, The arbiter's configuration of interrupt usage rights for the VM also includes: When the arbitrator receives requests from both the first VM and the second VM to use the first interrupt, and the first interrupt is not currently being used by other VMs, it configures the VM with the higher priority among the first VM and the second VM to have permission to use the first interrupt. The second VM is any one of the non-privileged VMs.

5. An interrupt handling device based on a virtual machine monitor, characterized in that, The apparatus includes: a virtual machine monitor, a privileged VM, and one or more non-privileged VMs; the privileged VM is equipped with an arbitrator; The arbitrator is configured to configure interrupt usage permissions for the non-privileged VM, including: receiving a request from a first VM to use a first interrupt, and configuring usage permissions for the first VM for the first interrupt if the first interrupt is not currently being used by other VMs; the first VM is any of the non-privileged VMs; and is further configured to, after configuring usage permissions for the first VM for the first interrupt, mark the first interrupt as used, and after receiving a notification that the first VM has completed using the first interrupt, mark the first interrupt as unused; The virtual machine monitor is used to establish pass-through between the non-privileged VM and the physical peripherals based on the interrupt usage rights of the non-privileged VM.

6. The apparatus according to claim 5, characterized in that, The device further includes: The VM creation module is used to create VMs and arbitrarily select one VM from the created VMs as a privileged VM, and treat the other VMs as non-privileged VMs.

7. The apparatus according to claim 5, characterized in that, An interrupt configuration processor is also provided in the privileged VM, and an interrupt configuration requester is provided in the non-privileged VM; The first VM sends the request to use the first interrupt to the arbitrator through the interrupt configuration requester in the first VM; The arbitrator configures the first VM's access rights to the first interrupt through the interrupt configuration processor.

8. The apparatus according to claim 7, characterized in that, The arbitrator is also used to extract the interrupt configuration information corresponding to each non-privileged VM from the configuration file in advance, and to transfer the interrupt configuration information to the dynamically executable application programming interface (API) of the non-privileged VM through the interrupt configuration requester in the non-privileged VM. The arbitrator obtains the interrupt configuration information of the first VM by making a super-call to the dynamically executable API of the first VM, and adds the first interrupt to the interrupt configuration information if the first interrupt is not present in the interrupt configuration information of the first VM.

9. The apparatus according to any one of claims 7 to 8, characterized in that, The arbitrator is further configured to, when simultaneously receiving requests from the first VM and the second VM to use the first interrupt, and the first interrupt is not currently being used by other VMs, configure the VM with the higher priority among the first VM and the second VM to use the first interrupt, wherein the second VM is any of the non-privileged VMs.

10. A terminal device, characterized in that, The terminal device includes the interrupt handling apparatus based on a virtual machine monitor as described in any one of claims 5 to 9.

11. A chip, characterized in that, The chip includes an interrupt handling device based on a virtual machine monitor as described in any one of claims 5 to 9.

12. A computer-readable storage medium, said computer-readable storage medium being a non-volatile storage medium or a non-transient storage medium, having stored thereon a computer program, characterized in that, When the computer program is run by the processor, the method described in any one of claims 1 to 4 is performed.

13. An interrupt handling apparatus based on a virtual machine monitor, comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor runs the computer program, the method of any one of claims 1 to 4 is performed.

Images