1. Field of Invention
The present invention relates to the computer field, more particularly, to an interrupt processing method and an interrupt processing system.
2. Description of Prior Art
Currently, front-end and back-end drivers of virtual machines are common architectures for virtual machine shared devices. Taking a network card as an example, in most applications, a plurality of virtual machines need to share a network. Different from a case of a graphic card, the virtual machines, even in the background, use the network. Thus, a general way is to share the network card by way of the front-end and back-end drivers.
In comparison to a Native system (a local system running on a local machine) driver, a front-end or back-end (FE/BE) of a virtual machine mainly differs in that a process of calling a VMCall to exchange data through a shared data region of a virtual machine manager (VMM) is increased. However, the VMCall highly consumes running time of a CPU (one VMCall needs to consume more than two thousand clock cycles, whereas a common instruction only needs one or several clock cycles), since it involves a CPU running level and context switching, switching of registers and memory and the like, and thereby it has a great influence on the performance of the whole system.
Therefore, in addition to traditional means for optimizing device drivers (such as, changing an interrupt into a polling, changing a linked list into an array/space for time, code logical optimization, etc.), the main means to optimize the front-end and back-end of the virtual machine is to decrease the calling of VMCall.
As shown in FIG. 1, a present solution 1 is illustrated. According to this solution, in a current virtual machine system, a Native device generates an interrupt after receiving data. Then, the virtual machine intercepts the interrupt and sets a flag bit in a virtual CPU, and subsequently waits for a GOS (Guest OS, referring to a client system running on the virtual machine) to get into the virtual machine to check the status of the interrupt flag bit, so as to write a corresponding value into an interrupt-related register of the virtual CPU. The virtual CPU generates a simulated hardware interrupt, and after receiving the interrupt, the GOS will call the interrupt processing function according to a query of an IDT table.
A flowchart of a communication between the front-end driver and the back-end driver is shown in FIG. 2, which comprises:
step S202, wherein the virtual machine receives data from applications, and at the same time probably carries out necessary data check or extraction (optional);
step S204, wherein a VMCall instruction is called, the VMM is switched to, and the data are copied into a shared region;
step S206, wherein the VMM instructs the back-end to read data from the shared region by way of interrupt injecting or interface calling; and
step S208, wherein the back-end driver obtains data from the shared region, and sends the data through a real device driver.
A disadvantage of this solution lies in that: this process has to be experienced once an interrupt arrives, and the GOS performance will significantly decrease when a great deal of interrupts have been generated.
According to a present solution 2, there are few devices with a function to close their interrupts, and drivers thereof may continuously read data by closing the interrupts, and then open the interrupts when there is no available data.
A disadvantage of this solution lies in that: devices require a function to close their interrupts, but currently there are few devices with such function.