WO2019001434A1 - 中断请求的处理方法、装置及虚拟化设备 - Google Patents

中断请求的处理方法、装置及虚拟化设备 Download PDF

Info

Publication number
WO2019001434A1
WO2019001434A1 PCT/CN2018/092933 CN2018092933W WO2019001434A1 WO 2019001434 A1 WO2019001434 A1 WO 2019001434A1 CN 2018092933 W CN2018092933 W CN 2018092933W WO 2019001434 A1 WO2019001434 A1 WO 2019001434A1
Authority
WO
WIPO (PCT)
Prior art keywords
processor
virtual
interrupt request
interrupt
virtual processor
Prior art date
Application number
PCT/CN2018/092933
Other languages
English (en)
French (fr)
Inventor
吴启翾
代雷
陈善席
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP23165232.2A priority Critical patent/EP4235420A3/en
Priority to KR1020207000394A priority patent/KR102339095B1/ko
Priority to EP18822992.6A priority patent/EP3627330B1/en
Publication of WO2019001434A1 publication Critical patent/WO2019001434A1/zh
Priority to US16/719,282 priority patent/US11972285B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/24—Handling requests for interconnection or transfer for access to input/output bus using interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • G06F9/4818—Priority circuits therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage

Definitions

  • the embodiments of the present invention relate to computer technologies, and in particular, to a method for processing an interrupt request in a computer, a virtualization device, and the like.
  • Virtualization technology "virtual" and “isolated” the physical computer hardware by adding a specific level of software to a physical computer, including the host and virtual machine layers.
  • Each software hierarchy includes different operational states, such as user mode and kernel mode. The diversification of software hierarchies and operational states increases the number of processing steps within the physical computer for certain requirements, thereby increasing the processing latency of these requirements.
  • Interrupt processing is a key requirement of virtualized devices.
  • the interrupt processing of existing virtualized devices (referred to as physical interrupt processing) is to send interrupt requests generated by hardware (such as network card, keyboard or mouse) to the processor, and then The processor calls the interrupt processing module in the host to distribute the interrupt request.
  • the interrupt processing module redistributes the interrupt request to the virtual computer.
  • the span of the span and the different operational states that may be involved in it increase the processing latency of such interrupt requests.
  • the present invention provides a method, a device, a virtualization device, and the like for interrupt request processing, which are used to reduce the processing delay of an application interrupt request in a virtualized device, thereby improving the service processing speed.
  • the present application provides a virtualization device, where the virtualization device includes a hardware layer, a host running on a hardware layer, and a virtual computer running on a host computer, where the virtual computer includes a service One or more virtual processors of a virtual machine.
  • the virtual machine that the host uses to configure the virtual computer can receive an interrupt request from the hardware layer by modifying the register bits.
  • the host implements the virtual processor to receive all interrupt requests directly from the hardware layer in the client mode by modifying register bits in the register for indicating the interrupt receiving mode of the virtual processor.
  • the interrupt receiving mode of the virtual processor is indicated by one or more register bits, which are physical registers associated with the physical processor running by the virtual processor, so the configuration step ultimately needs to be modified by physical registers.
  • the virtual computer (also referred to as a "current virtual processor") for receiving an interrupt request from the hardware layer; determining a processing body of the received interrupt request based on the interrupt request; When the processing body of the received interrupt request includes the current virtual processor of the virtual computer, the virtual computer determines, according to the interrupt request, an interrupt service program corresponding to the received interrupt request (specifically, an interrupt service program) Address) and invoke the interrupt service routine to process the interrupt request.
  • the received interrupt request may carry an identifier of the interrupt request, such as an IRQ ID, and subsequently determine a processing entity and an interrupt service program according to the identifier.
  • a virtual computer (such as a virtual machine or libOS) performs an action, which can be understood as a virtual processor that performs the action of the virtual computer, so the "virtual computer's current virtual processor” can It is understood to be a virtual processor that is performing the above configuration after the above configuration is run.
  • the "processing body" of the interrupt request in this application may be one or more virtual processors, or may be a host machine.
  • the nature of the two processing bodies is a physical processor, which is a different mode of the physical processor.
  • the virtual computer determines a processing body and an interrupt service program of the interrupt request according to some information and the interrupt request.
  • This information includes the correspondence between the interrupt request (identification), the processing body, and the interrupt service routine (address).
  • This information is stored in a storage area accessible by its virtual processor, such as the client address space, so that the virtual processor can directly access the information without trapping.
  • This correspondence can be updated by the host.
  • the information can be stored in a storage area accessible by all virtual processors of multiple VMs, so that any virtual processor can access. Further, the host can also access this information because the host can update this information.
  • the virtual computer can receive all interrupt requests directly from the hardware layer and distribute the interrupt requests.
  • the processing body of the interrupt request includes the current virtual processor of the virtual computer
  • the interrupt request can be directly processed by the virtual computer.
  • an interrupt request is an application interrupt request
  • the processing body of the interrupt request includes the current virtual processor of the virtual computer
  • the virtual computer can directly process the interrupt request, thereby avoiding the trapping and trapping of the virtual computer and avoiding interruption.
  • the process crosses multiple layers of the virtualization device, reducing the processing latency of application interrupt requests. Of course, the processing delay of the guest operating system interrupt request is also reduced.
  • the virtual computer determines whether the other virtual processor is in place, and if in place, operating the physical interrupt controller to send an IPI interrupt request to one or more virtual processors in the other virtual processors, the IPI interrupt
  • the request carries the identifier of the received interrupt request.
  • the premise of this operation is that the host configures the interrupt controller operating mode of the virtual processor so that the virtual processor can operate the physical interrupt controller and operate without trapping.
  • the in-position virtual processor executes the interrupt service program corresponding to the IPI, and the specific implementation of the interrupt service program invokes the interrupt service program corresponding to the identifier of the interrupt request carried in the IPI.
  • the "other virtual processors" herein may be virtual processors that serve the virtual computers, or virtual processors that serve other virtual computers. Similar to the interrupt receive mode, the interrupt controller operating mode of the virtual processor is indicated by one or more bits of a register associated with the physical processor on which the virtual processor is running.
  • all information about the state of the virtual processor in place or not can be stored in a storage area accessible to all virtual processors for access by any virtual processor. Further, the information can also be accessed by the host because the host can modify the state of the virtual processor when swapping in/out of the virtual processor.
  • a virtual processor sends an IPI interrupt request to another virtual processor it needs to know the physical processor running by the other virtual processor, and the information of the physical processor (for example, the following embodiment CORE ID) run by the virtual processor is also A storage method similar to the foregoing state information can be used. The following schemes that utilize virtual processors in place or not, or schemes that send IPIs, can also utilize this information.
  • the current virtual processor of the virtual computer receives an interrupt request, but is not the processing body of the interrupt request, and the virtual processor that can process the interrupt request is in place.
  • the current virtual processor is If the IPI interrupt is not trapped, the interrupt request that cannot be processed is directly sent to the in-position virtual processor that can process the interrupt request, thereby avoiding the current virtual processor being trapped, and then the host interrupts the interrupt request. Time, so that other virtual processors can receive and process the interrupt request as soon as possible, further reducing the processing delay of the application interrupt request.
  • the virtual computer is further configured to: when the processing entity of the received interrupt request is not including the current virtual machine Determining a target virtual processor from the other virtual processors when the other virtual processors of the virtual processor are determined to determine that the other virtual processors are not in the bit, where both the current virtual processor and the host are The identifier of the received interrupt request is recorded in a storage area that can be accessed. Of course, when the identifier is recorded here, the identifier needs to be associated with the target virtual processor, so as to indicate that this is the interrupt request to be processed by the target virtual processor.
  • the storage areas that can be accessed by both A and B mentioned in this application may be shared memory that can be accessed by both A and B, or other types of storage spaces that can be accessed by A and B.
  • the host is further configured to send an interrupt request to the target virtual processor according to the identifier recorded in the storage area after the target virtual processor is swapped in, so that the target virtual processor is trapped
  • the interrupt request is then processed. Specifically, after any virtual processor in the processing body is swapped in by the host and the virtual processor is trapped, the host checks the storage area and finds that the virtual processor has an unprocessed interrupt request, so sending and receiving The interrupt request to the interrupt request has the same feature to the virtual processor that is swapped in (actually sent to the physical processor to which the virtual processor is scheduled), and the swapped virtual processor is received and processed after being trapped The interrupt request.
  • the so-called interrupt request of the same feature may be an interrupt request identical to the interrupt request identifier originally received, or an IPI interrupt carrying the identifier of the interrupt request originally received.
  • the "target virtual processor" herein can be all processing entities of the interrupt request. Therefore, it can be understood that the determining the target virtual processor and then the record identifier includes a specific implementation: that is, all processing bodies directly requesting the interrupt Record the ID of the interrupt request.
  • the current virtual processor of the virtual computer receives an interrupt request, but is not the processing body of the interrupt request, and the target virtual processor that can process the interrupt request is not in place.
  • the virtual computer passes the current An identifier of the interrupt request is recorded in a storage area accessible by the virtual processor and the host, so that the host can send the same interrupt request to the target virtual by accessing the storage area after switching in the target virtual processor.
  • the processor processes the interrupt request after the target virtual processor is trapped, thereby realizing the sharing of interrupt requests between multiple virtual processors without the current virtual processor being trapped, further shortening the interrupt request. Handling delays.
  • the host is further configured to set a priority of the interrupt request, and record the priority on the host and the virtual computer a storage area that is accessible to each other;
  • the virtual computer is specifically configured to determine a target virtual processor from the other virtual processors: determining a priority according to a priority of the received interrupt request and a priority of the virtual processor A target virtual processor in which the state and priority of all virtual processors are stored in a storage area accessible to all virtual machines.
  • the priority of a virtual processor refers to the priority of the current task on the virtual processor.
  • the current task is not running, and the current task is running when it is in place.
  • the priority of the interrupt request may be stored in the same storage area as the interrupt service program mentioned in the foregoing implementation manner; the priority of the virtual processor may be the virtual processor mentioned in the foregoing implementation manner.
  • the state is stored in the same block of storage area.
  • a suitable target virtual processor is selected by introducing an interrupt priority and then comparing the priority of the interrupt to the priority of the current task on the virtual processor, thereby avoiding a large impact on the current task on the virtual processor.
  • the virtual computer is accessible to the host and the virtual computer according to the identifier of the received interrupt request Intra-area lookup to obtain the priority of the received interrupt request, compare the priority of the received interrupt request with the priority of all virtual processors in place; if all of the in-position virtual processors are If the priority is higher than (or equal to) the priority of the received interrupt request, determining that all virtual processors included in the processing body of the received interrupt request are the target virtual processor; if one or Determining, by a plurality of in-position virtual processors, a priority lower than a priority of the received interrupt request, determining a virtual processor having the highest priority among all virtual processors included in the processing body of the received interrupt request The target virtual processor.
  • the virtual The computer is further configured to: determine that the lowest priority virtual processor among all the virtual processors in the bit is a transit virtual processor, and send an IPI interrupt request to the transit virtual processor, where the IPI interrupt request carries Determining an identifier of the target virtual processor, so that the transit virtual processor is trapped according to the IPI interrupt request; the host is further configured to swap in the target virtual processor after the transit virtual processor is trapped .
  • the sixth aspect and its implementation For more specific implementation methods, reference may be made to the sixth aspect and its implementation.
  • the current virtual processor If the current virtual processor is the lowest priority virtual processor, the current virtual processor sends the identity of the target virtual processor to the host and then sinks. That is to say, there is no need to send an IPI interrupt request, and it is the "transition virtual processor" that is to be swapped out.
  • the priority of the interrupt request is the lowest, then the identifier of the interrupt request can be recorded, and there is no need to actively trigger the swapping of the target virtual processor; if the presence of the in-position virtual processor has priority over the interrupt request If the level is low, the interrupt request can be processed in preference to the current task of the virtual processor, and the virtual processor can be swapped out. Determining the lowest priority as the transit processor from the virtual processors that can be swapped out, determining the highest priority as the target virtual processor in the processing body of the interrupt request, and then changing the target virtual processor In, swap out the transit virtual processor. This minimizes the impact on the current task of the virtual processor.
  • the "lowest" or “highest” herein is also only one implementation of the present application. For example, if the system allows, the corresponding second-ranked virtual processor can also be selected separately.
  • the virtual computer when the processing entity of the received interrupt request is another virtual processor that does not include the current virtual processor of the virtual computer, When the other virtual processors are not in the bit, the virtual computer is further configured to: send the identifier of the target virtual processor to the host and sink, and the target virtual processor is any one of the processing entities a virtual processor or a virtual processor with the highest priority; the host is further configured to: swap in the target virtual processor according to the identifier of the target virtual processor and the current virtual processor of the virtual computer Swap out.
  • the interrupt request itself is very urgent or has a high priority. It needs to be processed immediately, so there is no need to determine the transit virtual processor, and the current virtual processor is directly swapped out, and any processing entity or The processing object with the highest priority is swapped in to process the interrupt request as soon as possible.
  • the identifier of the interrupt request may not be recorded in advance, but the interrupt or the message used to trigger the target virtual processor to be swapped may be carried.
  • the identifier of the request For example, the IPI interrupt request of the foregoing fifth implementation manner carries an identifier of the interrupt request in addition to the identifier of the target virtual processor, and the identifier of the interrupt request is sent to the host when the transit virtual processor is trapped. After the host swaps in the target virtualization processor, it sends an identical interrupt request to the target virtual processor according to the identifier.
  • the virtualization device stores state information of the virtual processor in a bit or not in all virtual processors (ie, all virtual machines). Within the storage area, it can be recorded by one or more tables. For convenience of description, the record is referred to as a "run entity table” in some embodiments of the present application, but the name of the table is not limited in this application. Similarly, the same is true for the "interrupt vector table” or "interrupt mapping table” that will appear in the implementation described below.
  • the scheduling of the virtual processor is performed by the host machine, and specifically may be performed by the virtual machine monitoring device in the host machine, so the update of the running entity table is performed by The host machine executes, which means that the storage area host running the entity table can also access it. Specifically, after the host machine switches into a virtual processor and the virtual processor is trapped, the corresponding state of the virtual processor in the running entity table is updated to be in place, and then the virtual processor is trapped. A virtual processor is trapped but the virtual machine updates the corresponding state of the running entity table to be absent before the host swaps out the virtual processor, and then the host swaps out the virtual processor.
  • the running entity table accessible to all virtual processors and hosts provides timely access to the latest state of the virtual processor. If the processing body of the interrupt request is in place, the current virtual processor can directly send the interrupt request to the in-place virtual processor without trapping; if the processing body of the interrupt request is not in place, the current virtual processor is also The interrupt request can be recorded in the running entity table or further triggered by the target virtual processor without trapping, so that the target virtual processor can be processed and the interrupt request can be processed to prevent the virtual processor from sinking. The resulting delay increases the efficiency of processing interrupt requests.
  • Interrupt affinity is an attribute of the interrupt controller.
  • the interrupt affinity includes a correspondence between an identifier of the interrupt request and an identifier of the physical processor (which may be simply referred to as a processor).
  • the interrupt controller is a piece of hardware that receives interrupt requests generated by other hardware and sends an interrupt request to the corresponding physical processor based on the interrupt affinity.
  • the host is further configured to configure interrupt affinity in the interrupt controller, so that an interrupt request can be sent to a virtual processor included in the processing body of the interrupt request. Since the virtual processor runs on the physical processor, on the virtual processor that guarantees that the interrupt request is sent, it is actually guaranteed that the interrupt request is sent to the physical processor on which the pair of virtual processors are running.
  • the eighth implementation manner after the host machine is swapped into a virtual processor and the virtual processor is trapped, the virtual processing to be swapped in is to be executed.
  • the physical processor of the device and all the interrupt requests of the processing entity including the swapped virtual processor establish a correspondence in the interrupt affinity, and then the virtual processor is put into operation.
  • the interrupt controller can send an interrupt request to the physical processor running by the virtual processor according to the modified interrupt affinity, that is, to the virtual processor, and the processing body of the interrupt request includes the The virtual processor, the virtual processor can directly process the interrupt request, effectively avoiding the distribution of the interrupt request between the virtual processors.
  • the host removes (except for updating the running entity table) the interrupted affinity, the virtual processor to be swapped out, and the processing body including all interrupt requests of the virtual processor. Correspondence between them.
  • the interrupt request is sent to the virtual processor that can process the interrupt request and is currently in place, greatly avoiding the interrupt request distribution between the virtual processors, further improving the interrupt request.
  • the processing efficiency of the interrupt request is very high.
  • the ninth implementation manner even if the interrupt affinity is configured, it is possible for a virtual processor to receive an interrupt request that cannot be processed by itself, at this time, due to configuration If the affinity is interrupted, it can be determined that all the virtual processors included in the processing body of the interrupt request are not in the bit, so it is not necessary to determine whether the processing body of the interrupt request is in place at this time.
  • the priority of the request is reasonable to select the target virtual processor; further, the target virtual processor can be actively triggered to be swapped in, so that the interrupt request is processed as soon as possible.
  • the virtual computer is further configured to: when the processing entity of the received interrupt request is the host, the virtual The computer injects the received interrupt request into the host; the host is further configured to receive and process the interrupt request injected by the virtual computer.
  • the virtual computer is specifically configured to determine, according to the interrupt vector table and the identifier of the received interrupt request, the processing of the interrupt request. a main body and an interrupt service program corresponding to the interrupt request, where the interrupt vector table includes an identifier of an interrupt request, a processing body of the interrupt request, and a correspondence relationship between an interrupt service program of the interrupt request, the interrupt vector
  • the table is stored in a storage area accessible by both the virtual computer and the host; the host is further configured to modify (at the trigger of the virtual computer) the interrupt vector table to increase the identifier of the interrupt request, Correspondence between the processing body of the interrupt request and the interrupt service routine.
  • the processing body of the interrupt request By storing the interrupt request, the processing body of the interrupt request, and the correspondence between the interrupt service routines through the interrupt vector table shared by the layer (that is, the virtual processor and the host can be shared), it is possible for a virtual processor to need such information.
  • the storage area can be directly accessed, and it is not necessary to be trapped, thereby avoiding the interruption delay caused by the trap.
  • This information can be stored in such a way as to save storage space. Further, the information can be modified by the host machine, which makes the design more reasonable and safe.
  • the present application provides a method for processing an interrupt request, which is applied to a virtualization device, where the virtualization device includes a processor and two different modes of operation: a host mode and a client mode.
  • the processor configures a register in a host mode to enable the processor to receive an interrupt request from other hardware of the virtualized device when the virtual processor is running and the virtual processor is running in a guest mode;
  • the processor in the client mode, performing an operation of: the processor receiving an interrupt request from the other hardware, the processor determining a processing body of the received interrupt request according to the interrupt request; when the receiving When the processing body of the interrupt request includes the virtual processor currently running on the processor, the processor determines an interrupt service program corresponding to the received interrupt request according to the interrupt request, and invokes the interrupt
  • the service program processes the interrupt request.
  • the received interrupt request may carry an identifier of the interrupt request, such as an IRQ ID, and subsequently determine a processing entity and an interrupt service program according to the identifier.
  • the virtual computer determines the processing body and the interrupt service program of the interrupt request according to some information and the interrupt request.
  • This information includes the interrupt request (identification), the processing body, and the corresponding relationship of the interrupt service routine.
  • the "processor” here can be understood as a minimum physical processing unit, such as a physical core.
  • the processor configures, in a host mode, a physical interrupt controller that is capable of operating a virtual processor running on the processor;
  • the processor when in the client mode, further performs the following operations: when the processing entity of the received interrupt request is another virtual processor that does not include the virtual processor currently running on the processor and determines the other When at least one of the virtual processors is in position, operating the physical interrupt controller to send an IPI interrupt request to one or more virtual processors in the other virtual processors, the IPI interrupt request carrying The identifier of the received interrupt request.
  • the processor configures an interrupt affinity of an interrupt controller of the virtualization device in a host mode, so that an interrupt request can be sent to a processing body of the interrupt request
  • the interrupt affinity includes a correspondence between an identifier of the interrupt request and an identifier of the processor.
  • the processor receives the interrupt request sent by the interrupt controller to the processor according to the interrupt affinity.
  • the processor after the host mode is switched into a virtual processor, includes the processor and the processing body including the swapped virtual processor All interrupt requests establish a correspondence in the interrupt affinity.
  • the processor deletes the correspondence between the virtual processor to be swapped out and all interrupt requests of the processing entity including the virtual processor from the interrupt affinity before the host mode swaps out a virtual processor .
  • the processor determines the target virtual processor from the other virtual processors in a client mode, and records the storage area in the storage area that the processor can access in both the guest mode and the host mode.
  • An identifier of the interrupt request the processor sends an interrupt request to the target virtual processor according to the identifier recorded in the storage area after the host mode is swapped in the target virtual processor, to facilitate the target virtual processing
  • the interrupt request is processed after the trap.
  • the processor turns off the interrupt response of the host mode before the host mode is swapped into the target virtual processor and the target virtual processor is not trapped, and then according to the identifier recorded in the storage area Send an interrupt request with the same characteristics (because the processor to which the target virtualization processor is currently scheduled is itself). After the target virtual processor is trapped (that is, the processor is in client mode), the interrupt request can be received and processed.
  • the processor sets a priority of the interrupt request in a host mode, and records the priority in the processor in a host a storage area accessible by both the mode and the client mode; the processor determining, in the client mode, the target virtual processor according to a priority of the received interrupt request and a priority of the virtual processor, wherein the virtual processing The priority of the device is stored in a storage area accessible to all virtual processors.
  • the processing entity of the received interrupt request is other virtual processing that does not include the virtual processor currently running on the processor
  • the method further includes: the processor injecting the identity of the target virtual processor in a guest mode (to a host or host mode), after which the processor leaves the client mode and enters a host mode, Wherein the target virtual processor is any one of the other virtual processors or a virtual processor with the highest priority; the processor is swapped in the host mode according to the identifier of the target virtual processor The target virtual processor swaps out the current virtual processor on the processor.
  • the method provided by the second aspect is applied to a virtualization device, the virtualization device comprising a hardware layer, a host running on the hardware layer, and a virtual computer running on the host, the virtual computer including the virtual service
  • a virtual processor of a computer on which a virtual processor can run can run.
  • the actions performed by the processor in the client mode can be understood as the virtual processor (in the client mode) performing the action, and thus can also be understood as the virtual computer performing the action of the virtual processor service; the processor can perform the action in the host mode. Perform actions for the host.
  • the present application provides an apparatus for processing an interrupt request, the processing apparatus being applied to a virtualization device, the virtualization device comprising a hardware layer, a host machine, and a virtual computer; and the processing device includes being deployed on the sink a host interrupt management unit in the host and a client interrupt management unit deployed in the virtual computer;
  • the host interrupt management unit is configured to configure a virtual processor of the virtual computer to receive an interrupt request from the hardware layer;
  • the client interrupt management unit is configured to receive an interrupt request from the hardware layer, where the received interrupt request carries an identifier of the interrupt request, and determine, according to the identifier, a processing entity of the received interrupt request;
  • the processing body of the received interrupt request includes the current virtual processor of the virtual computer
  • the virtual computer determines an interrupt service program corresponding to the received interrupt request according to the identifier, and invokes the interrupt The service program processes the interrupt request.
  • the present application provides a virtualization device including a processor and a memory, the memory for storing computer readable instructions, the processor for reading the computer readable instructions and implementing the foregoing Any of the methods provided.
  • the present application provides a computer storage medium, configured to store computer readable instructions, to cause the processor to implement any of the foregoing provided when the computer readable instructions are read by a processor method. Additionally, a computer program or computer program product is provided, the computer program or computer program product comprising computer readable instructions which, when read by a processor, cause the processor to implement any of the foregoing aspects a way.
  • the present application provides an inter-processor interrupt (IPI) processing method.
  • IPI inter-processor interrupt
  • the method can be applied to the methods or apparatus provided by the foregoing aspects or any implementation.
  • the host configures an interrupt controller operation mode of the source virtual processor, so that the source virtual processor can operate the interrupt controller to send to the physical processor running by the destination virtual processor without trapping Describe the IPI interrupt request.
  • the source virtual processor determines, according to the information, a physical processor that is operated by the destination virtual processor, wherein the information is recorded in a storage area accessible by the source virtual processor, and the information includes the virtual processor indicating the destination Information of the running physical processor; then the source virtual processor operates the interrupt controller to send an IPI interrupt request to the physical processor on which the destination virtual processor is running.
  • the source virtualization processor can send an IPI interrupt request to the destination virtualization processor without trapping.
  • the source virtual processor sends an IPI interrupt request to the destination virtual processor, where the IPI interrupt request carries an identifier of another interrupt request or the IPI interrupt request carries other An identifier of the interrupt request and an identifier of the virtual processor; the destination virtual processor determines that the identifier of the virtual processor is not carried in the IPI interrupt request or determines the identifier and location of the virtual processor carried in the IPI interrupt request If the identifiers of the virtual processors are consistent, the interrupt service program corresponding to the identifier of the other interrupt request is invoked to process the other interrupt requests.
  • the virtual processors can be in the same virtual computer or in different virtual computers. .
  • the method when the IPI interrupt request carries the identifier of the virtual processor (the identifier of the other interrupt request may not be carried), the method further The virtual processor of the destination determines that the identifier of the virtual processor carried in the IPI interrupt request is inconsistent with the identifier of the destination virtual processor, and sends the identifier of the virtual processor to the host and traps So that the host swaps in the virtual processor indicated by the identifier of the virtual processor.
  • the host can swap in the target virtual processor, so that the target virtual processor can process the interrupt request carried in the IPI interrupt request as soon as possible.
  • the source virtual processor sends the IPI interrupt request when determining that the destination virtual processor is in place.
  • the source virtual processor queries the information to determine whether the destination virtual processor is in place, and the information further includes information indicating whether the destination virtual processor is in place.
  • the information may be recorded in a storage area accessible by both the virtual processor and the host, and the host is configured to modify the information when the virtual processor is swapped in and out.
  • the present application further provides an IPI interrupt processing apparatus corresponding to the sixth aspect, comprising one or more modules for implementing the method provided by the sixth aspect or any one of the implementation manners.
  • an IPI interrupt processing apparatus corresponding to the sixth aspect, comprising one or more modules for implementing the method provided by the sixth aspect or any one of the implementation manners.
  • a virtualization device is provided, the virtual processor in the virtualization device being configured to implement the method as described in the sixth aspect or any one of its implementations.
  • a computer storage medium, a computer program, and a computer program product are also provided, with particular reference to the foregoing aspects.
  • the present application further provides a method for interrupt processing for processing an interrupt request requiring a plurality of virtual processor processes, such as a clock interrupt.
  • the method includes: the host machine creates corresponding information for each physical processor, the information including information of the virtual processor that was last run on the physical processor.
  • the virtual processor receives an interrupt request and determines that the interrupt request requires multiple virtual processor processing, and then determines that the virtual processor in the information set is included in the processing body of the interrupt request, and then on the host and Recording the interrupt request in a location corresponding to the virtual processor in an area accessible by the virtual processor, so as to trigger the swapping of the virtual processor, so that the virtual processor can process the interrupt request as soon as possible .
  • Further processing methods can be referred to the foregoing aspects and embodiments thereof. Also provided are devices corresponding to this aspect and readable storage media. In this way, the delay of an interrupt request like a clock interrupt is also effectively reduced.
  • the present application further provides a method for interrupt processing, the host machine receives an application interrupt request, and determines, by using the access information, whether a virtual processor capable of processing the interrupt request is in place, and if any one of the bits is in place, The IPI interrupt sends the interrupt request to the in-place virtual processor; if none of the bits are present, the interrupt request is recorded in an area accessible by both the host and the virtual processor.
  • Whether to actively trigger the swap-in, and how to switch in, refer to the foregoing aspects and specific embodiments thereof.
  • devices corresponding to this aspect and readable storage media are also provided. Through such a method, the application can be applied in a scenario where the host cannot close the interrupt response, and the application range is wider.
  • FIG. 1 is a schematic diagram of a network architecture applied to an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of hardware of a virtualized network device according to an embodiment of the present invention.
  • 3A is a schematic diagram of a configuration of a virtualized network device according to an embodiment of the present invention.
  • FIG. 3B is a schematic diagram of another configuration of a virtualized network device according to an embodiment of the present disclosure.
  • FIG. 4 is a schematic flowchart of an interrupt processing method according to an embodiment of the present invention.
  • FIG. 5 is a schematic diagram 1 of each functional unit module in a virtualized network device according to an embodiment of the present disclosure
  • FIG. 6 is a schematic flowchart of initializing an interrupt management unit of a host according to an embodiment of the present disclosure
  • FIG. 7 is a schematic flowchart of initializing a client interrupt management unit according to an embodiment of the present invention.
  • FIGS. 8A and 8B are schematic flowcharts of an interrupt processing method according to an embodiment of the present invention.
  • FIGS. 9A and 9B are schematic flowcharts of interrupt affinity configuration according to an embodiment of the present invention.
  • FIG. 10 is a second diagram of an example of each functional unit module in a virtualized network device according to an embodiment of the present disclosure.
  • FIG. 11 is a schematic flowchart diagram of a method for processing a replication interrupt according to an embodiment of the present disclosure
  • FIG. 12 is a third diagram of an example of each functional unit module in a virtualized network device according to an embodiment of the present invention.
  • Virtual Machine A collective term for the operating environment virtualized by software in all types of virtualized devices. The concept includes virtual machines, containers, and lightweight virtualization libOS.
  • Virtual machine One or more virtual computers that are simulated on a physical computer by software. These virtual machines run in a completely isolated environment, working like a real computer.
  • a guest operating system can be installed on the virtual machine, and one or more applications run on the guest operating system.
  • Virtual machines also have access to network resources. For an application running in a virtual machine, it's like working on a real computer.
  • the host layer is used as a management layer to manage and allocate hardware resources; to present a virtual hardware platform for virtual machines; to implement scheduling and isolation of virtual machines.
  • the host layer includes a host operating system and a virtual monitoring device, such as a virtual machine monitor (VMM) or a hypervisor, wherein the virtual monitoring device can be deployed within the host operating system, or Deployed outside of the host operating system.
  • the "host layer” may also include a privileged virtual machine (eg, virtualization architecture Xen).
  • the virtual hardware platform provides various hardware resources, such as a virtual processor, a virtual memory, a virtual disk, a virtual network card, and the like, for each virtual computer running thereon.
  • the virtual machine runs on a virtual hardware platform prepared for it at the host layer.
  • the host layer is sometimes simply referred to as a host.
  • Hardware layer The hardware platform on which the virtualized environment runs.
  • the hardware layer may include various hardware.
  • the hardware layer of a physical computer may include a processor and a memory, and may also include an interrupt controller, a network interface card (NIC), and an input/output (input/output I/O). ) Equipment, etc.
  • NIC network interface card
  • I/O input/output
  • Interrupt request refers to an event generated by hardware.
  • the hardware sends the event to the processor.
  • the program corresponding to the event.
  • Hardware-generated interrupt requests may be triggered by the hardware itself or by software-triggered hardware.
  • Interrupt requests are sometimes referred to simply as interrupts.
  • Some hardware in the computer such as network card, sound card, mouse, hard disk, etc.
  • the interrupt number is an identifier of the interrupt request, which is represented by the English IRQ ID in this application.
  • Interrupt controller Set between the hardware that triggers the interrupt request and the processor. It is mainly used to collect interrupt requests generated by each hardware and send them to the processor according to certain priorities or other rules.
  • an advanced programmable interrupt controller APIC
  • the interrupt controller of the present application is a general term, which may include different functional components.
  • the interrupt controller in the X86 system includes an io-APIC and a plurality of local-APICs, and further may include several other interrupt control components; -APIC corresponds to a physical core.
  • Interrupt affinity refers to the correspondence between the interrupt request and the processing entity (usually the physical processing entity, such as the physical core) that handles the interrupt request.
  • the interrupt controller can send an interrupt request to one or more physical processing bodies corresponding to the interrupt request according to the interrupt affinity.
  • Interrupt service routine A program used to process interrupt requests. When the processor receives the interrupt request, the execution of the current program is temporarily stopped and the interrupt service program corresponding to the interrupt request is executed.
  • Application interrupt request The application refers to an application (or business software) deployed in a virtual machine.
  • the application in the virtual machine deploys its own interrupt service program to the guest operating system it runs, if an interrupt request is made.
  • the interrupt service routine is located inside the guest operating system and is deployed by an application (that is, the application needs to be processed), and the interrupt request is called an application interrupt request.
  • applications deployed in virtual machines are usually used to fulfill various actual business requirements, so application interrupt requests can sometimes be called service interruption requests.
  • Physical processor sometimes referred to as a "processor”, in this application, a physical processing unit, specifically a minimum processing unit, that is, a physical core in the present application, and in some embodiments, may also include a plurality of physical Core processing unit.
  • the virtual computer is equivalent to a separate computer, so the virtual computer performing the action can also be considered as the virtual processor performing the action, and the virtual processor is implemented by software, so the virtual processor execution action is actually a virtual processor.
  • the physical processor or physical core that is running performs this action.
  • Virtual processor traps and virtual processor traps Virtualization systems include two modes: host mode and guest mode. When a virtual processor enters the client mode, it is called trapped (virtual); when the virtual processor leaves the client mode, it is called trapped (virtual). After the virtual processor is trapped, the physical processor will temporarily not execute the code of the virtual processor, so it can be understood that the virtual processor is not running at this time.
  • a virtual processor such as a vCPU is taken as an example to introduce a method or device, so in these embodiments, the vCPU is specifically trapped or trapped.
  • the physical processor can be considered to be in the client mode, and the code of the virtual processor is run, and when the virtual processor running on it is trapped in the host mode, The physical processor can be considered to be in host mode, running host-related code, such as VMM.
  • the virtual processor is in or out of position: the state after the virtual processor is trapped is called in-position, and the state that is not trapped is called absent.
  • a virtual processor can be understood as the virtual processor is running, that is, there is a code that the physical processor executes the virtual processor; a virtual processor is not in place, that is, no physical processor executes the code of the virtual processor.
  • a virtual processor such as a vCPU is used as an example to introduce a method or device, so in these embodiments, the vCPU is specifically in place or not.
  • FIG. 1 schematically illustrates an embodiment of a network system.
  • the network system includes a network device such as a user equipment, an evolved base station (eNodeB) 100, a mobility management entity (MME), and a service gateway.
  • the network system can also be a network system that complies with the 5G communication standard.
  • User equipment includes mobile phones, desktop computers, notebooks, in-vehicle devices, and the like.
  • the network system may further include other network devices such as a user home server and a PDN gateway, which are not enumerated here.
  • the type of processor is a central processing unit (CPU), a graphics processor, a microprocessor or a coprocessor.
  • the network interface 130 is used to connect other network devices, including wireless connections and wired connections.
  • the memory 120 includes volatile and non-volatile memory.
  • the non-volatile memory stores the virtualization software program 122, the software 121 of the interrupt request processing method provided by the present application, and other program modules 123.
  • the virtualization software program 122 is read and executed by the processor 110 to implement virtualization of the eNodeB 100, including creating a host layer and a plurality of virtual computers, etc.; the interrupt processing software program 121 provided by the present application is read by the processor 110 and Various interrupt request processing methods provided by various embodiments of the present application are implemented after the operation.
  • the software program 121 provided by the present application can be incorporated in the virtualization software program 122.
  • the above components are connected by a bus 140.
  • the bus 140 can be one or multiple.
  • the bus 140 includes an advanced microcontroller bus architecture (AMBA) industry standard architecture (ISA) bus, a micro channel architecture (MCA) bus, an extended ISA (extended-ISA) bus, video.
  • ABA advanced microcontroller bus architecture
  • MCA micro channel architecture
  • VESA video electronics standards association
  • PCI peripheral component interconnect
  • FIG. 3A shows a schematic diagram of a configuration after the eNodeB 100 is virtualized in the above embodiment.
  • the virtualization device 100 includes a hardware layer, a host layer, and a virtualization layer, and the virtualization layer includes two virtual machines.
  • the hardware layer includes two processors 110, a memory 120, a network interface 130, an interrupt controller 160, and the like. In other embodiments, the number of processors 110 and the number of virtual machines may be more or less.
  • a virtual machine may contain a container, which is equivalent to an application.
  • the virtualization layer is implemented by a lightweight virtualization technology, such as libOS 190.
  • a libOS usually contains an application.
  • the entire libOS is one or more libraries, and the application is linked into a single address space image.
  • the libOS 190 internally includes the client interrupt management unit 191 proposed by the present application.
  • the embodiments of the present application are generally exemplified by a virtual machine implemented by a conventional virtualization technology. Other types of virtualization architectures may refer to implementations of virtual machines.
  • eNodeB 110 is taken as an example in this embodiment, but the method provided by the present application is not limited to the device, and all types of virtualization devices can be applied.
  • the interrupt controller 160 is responsible for collecting interrupt requests generated by hardware devices such as the network interface 130, and transmitting the interrupt requests to the respective processors 110 according to certain rules.
  • Processor 110 may include one or more physical cores (sometimes referred to herein as a physical core).
  • Physical core in this application represents the smallest processing unit. As shown in FIG. 3A or FIG. 3B, each processor in this embodiment has two physical cores: core 0 and core 1, and a plurality of registers. In some other embodiments, the number of cores included in the processor may be more or less, and the number of cores included in each processor may also be different.
  • the host machine has a host operating system 170 and a VMM 180 deployed in the host.
  • the VMM 180 is equivalent to a hypervisor or other type of virtual monitoring device in other virtualization architectures.
  • the VMM 180 can be deployed within the host operating system 170 or can be deployed separately from the host operating system 170.
  • the VMM 180 is responsible for managing one or more virtual machines running on it.
  • a virtual machine includes a virtual hardware layer, a guest operating system 190, and a variety of applications.
  • the virtual hardware layer contains virtual hardware (not shown in the figure), virtual hardware such as virtual processor 110-v.
  • virtual hardware such as virtual processor 110-v.
  • the embodiment includes two virtual machines, each of which includes three virtual processors 110-v.
  • the virtual processor 110-v is implemented by a combination of software and hardware, and its operation is actually implemented by a physical core reading and running a software program, such as a physical core reading software program and a specific mode of hardware assisted virtualization in the physical core.
  • the software program is run under a non-Root mode (eg, x86) to implement a virtual processor 110-v. Therefore, the virtual processor 110-v needs to be scheduled to a certain physical core.
  • the virtual processor 110-v and the physical core may be in a bound relationship, that is, a virtual processor 110-v is fixed on a certain physical core and cannot be scheduled to run on other physical cores, and the virtual processor is tied. Core; a virtual processor 110-v can be scheduled to run on different physical cores as needed, and the virtual processor is a non-tied core.
  • the total number of virtual processors 110-v is 6, which is greater than the number 4 of physical cores.
  • This scenario is called physical processor over-allocation.
  • physical processor over-allocation there may be multiple virtual processors sharing the same physical core in a time-sliced manner or other manner.
  • This physical core is called a non-exclusive core.
  • non-exclusive nuclear may also occur in the case of non-over-allocation.
  • a physical core is bound to a virtual processor and is not shared by other virtual processors.
  • the physical core is an exclusive core.
  • the VMM 180 is responsible for scheduling the virtual processors 110-v of the respective VMs.
  • a kernel-based virtual machine KVM
  • the scheduling of the virtual processor 110-v by the VMM 180 includes swapping in virtual processors and swapping out virtual processors.
  • the VMM 180 creates and initializes a VM object and then creates three virtual processors 110-v for the VM.
  • a VM contains multiple virtual processors 110-v, there will typically be one primary virtual processor and the other a secondary virtual processor.
  • the virtual processor 110-v was not associated with a physical core since its creation.
  • the VMM 180 schedules a virtual processor 110-v to a physical core according to a policy, which is called the virtual processor being swapped in; the VMM 180 suspends or migrates the virtual processor 110-v from the physical core. Going out, called the virtual out processor is swapped out.
  • a virtual processor is scheduled to the same core each time it is swapped in.
  • the VMM 180 may determine which core to schedule the virtual processor 110-v to based on the current operating conditions and/or scheduling algorithms of the system prior to scheduling.
  • VMM virtual processor 110-v
  • the existing interrupt request processing scheme is generally designed based on the principle of system interrupt priority, and the hardware-generated interrupt request is all directly passed to the host layer, so the host layer interrupt request processing process Faster.
  • the application interrupt request needs to be recognized by the host and then sent to the virtual machine, so the entire process involves both the host and the virtual machine (which can also be considered as a virtual processor), and thus involves virtual processing.
  • the trapping and trapping of the device so the processing becomes longer and the delay increases, which obviously cannot meet the requirements of the ultra-low latency of the business processing. Therefore, the present application proposes a method for effectively reducing the application delay request processing delay, and gradually expands more functions based on the method.
  • the device 100 provided in this embodiment includes a host interrupt management unit 181 and a client interrupt management unit 191. These two units can be considered as two functional modules of the interrupt processing software program 121 of FIG.
  • the host interrupt management unit 181 is deployed at the host layer.
  • the host interrupt management unit 181 may be deployed in the host operating system 170, may be deployed in the VMM 180, or may be partially deployed in the host operating system 170, partially deployed.
  • the VMM180 When the VMM 180 is deployed in the host operating system 170, the host interrupt management unit 181 may be deployed in the VMM 180, or may be deployed in the host operating system 170 other than the VMM 180, or partially deployed in the VMM 180, partially deployed.
  • the host interrupt management unit 181 may be deployed in the VMM 180, or may be deployed in the host operating system 170 other than the VMM 180, or partially deployed in the VMM 180, partially deployed.
  • the client outage management unit 191 can be deployed inside the guest operating system 190 of each virtual machine.
  • the client interrupt management unit 191 can be deployed in the runtime of the libOS.
  • the client interrupt management unit 191 is configured to receive an interrupt request directly from the hardware layer.
  • the client interrupt management unit 191 is configured to directly receive an interrupt request from the interrupt controller 160 or other interrupt collection device and determine the processing body of the interrupt request. If the processing body of the interrupt request is the current virtual processor of the current virtual machine, the interrupt service routine is directly called. Further, if the processing entity of the interrupt request is the host, the interrupt request is sent to the host. Further, if the processing body of the interrupt request is not another virtual processor for the current virtual processor, the interrupt request is provisioned to other virtual processor processing. If other virtual processors are in place, the interrupt request can be provisioned by sending an IPI. If other virtual processors are not in place, the interrupt request can be recorded so that other virtual processors can be processed after the bit is in place. It should be noted that the “current virtual machine” is the virtual machine to which the customer interruption management unit 191 belongs, and the “current virtual processor” is the virtual processor that currently reads and runs the client interruption management unit 191.
  • the host interrupt management unit 181 is configured to configure the interrupt receiving mode of the virtual processor 110-v such that the virtual processor 110-v can receive an interrupt request from the hardware layer in the client mode.
  • the host interrupt management unit 181 is further configured to configure the virtual processor 110-v to operate the mode of the interrupt controller 160 such that the virtual processor 110-v can directly operate the physical interrupt controller 160 in the client mode. (generally the local interrupt controller of the physical core on which the virtual processor is running).
  • the host interrupt management unit 181 is further configured to manage information required to process the interrupt request (refer to Table 1 and Table 2 in the following embodiments), including information provided when the application registers the interrupt request, and the information is provided.
  • the host interrupt management unit 181 is further configured to receive an interrupt request sent from the virtual machine, and send the interrupt request to an existing interrupt processing module in the host, where the module is deployed and deployed in the host.
  • the service routine is interrupted to process the interrupt request.
  • the action performed by the client interrupt management unit 191 can be considered to be an action performed by the current virtual processor of the current virtual machine in the client mode (ie, the trapped state).
  • the virtual processor 110-v first determines the processing body of the received interrupt request (S401). If it is determined that the processing body of the interrupt request is itself, the virtual processor 110-v processes the interrupt request (S402); if it is determined that the processing body of the interrupt request is a host, the virtual processor 110-v interrupts the interrupt The request is sent to the host (S403); if it is determined that the processing body of the interrupt request is another virtual processor, the virtual processor 110-v records the interrupt request to record the storage area that all virtual processors can share or interrupt the interrupt The request is sent to other virtual processors, such as by way of IPI (S404), so that other virtual processors can access the storage area and process the interrupt request or process the interrupt request after receiving the IPI.
  • S401 the processing body of the received interrupt request
  • the virtual processor 110-v processes the interrupt request (S402); if it is determined that the processing body of the interrupt request is a host, the virtual processor 110-v interrupts the interrupt The request is sent to the host (S403); if
  • the host interrupt management unit 181 configures the virtual processor 110-v such that the virtual processor 110-v can directly operate the physical interrupt controller 160 in the client mode, the virtual processor 110-v can be in the client mode.
  • the direct operation interrupt controller 160 sends an IPI to other virtual processors, and the IPI carries the information of the unprocessed interrupt request.
  • step S404 is as follows: if it is determined that the processing body of the interrupt request is another virtual processor, in some implementations, the virtual processor records the interrupt only in a storage area that all virtual processors can share. Requesting, the processing entity of the interrupt request accesses the storage area and processes the interrupt request according to its own running condition; in other implementations, the virtual processor may first determine that the processing entity is absent, if the processing entity is Bit, the interrupt request is sent to the in-process processing body by sending an IPI, so that it can process the interrupt request as soon as possible; if the processing body is not in place, the virtual processor can be shared not only in all virtual processors The interrupt request is recorded in the storage area, and a transit virtual processor (possibly itself) can be determined, and an IPI interrupt is sent to the transit virtual processor, and the transit virtual processor sinks to the sink after receiving the IPI interrupt. The host, then the host swaps in the processing body, and processes the interrupt request after swapping in. If the transit virtual processor is itself, then the identity of the
  • step S404 After the mid-end affinity attribute of the interrupt controller is configured according to the method proposed in the present application, if it is determined that the processing body of the interrupt request is another virtual processor, the processing body does not need to be determined. Whether it is in place, because the processing body must not be in place, so the interrupt request can be recorded only in the storage area that all virtual processors can share, or it can be triggered to be triggered by the host machine as in the manner described in the previous paragraph. Into ensure that the interrupt request is processed as soon as possible.
  • the interrupt request processing method enables a virtual processor (or a virtual machine served by the virtual processor) to directly receive an interrupt request generated by a hardware, and an application interrupt request for the interrupt request.
  • the virtual processor can directly call the interrupt service program in the virtual machine for processing, and no longer needs to be trapped and trapped by the host transfer and the virtual processor, thereby greatly improving the processing efficiency of the application interrupt request and reducing the application interruption.
  • the processing delay of the request is applied to the guest operating system interrupt request.
  • the interrupt request can be recorded under the premise that the current virtual processor does not need to be trapped or sent to other virtual virtual machines without the current virtual processor needing to be trapped.
  • the processor enables other virtual processors to process the interrupt request as soon as possible, further improving the processing efficiency of the interrupt request.
  • the interrupt request of the processor is required to be sent to the host in reverse, and the interrupt request is processed in time, so that the method provided by the embodiment of the present invention can be applied to the interrupt request that the host needs to process.
  • the complexity of the system makes the application of the embodiments of the present invention more extensive.
  • Figure 5 illustrates a more specific embodiment, in which the processor is a central processing unit (CPU) 210, the virtual processor is a vCPU, and the interrupt controller is an advanced programmable interrupt controller ( Advanced Programmable Interrupt Controller (APIC)) 260.
  • the two virtual machines are virtual machine 29-1 and virtual machine 29-2, respectively.
  • APIC260 generally includes an io-apic and four local-apic corresponding to four physical cores.
  • the host interrupt management unit 281 includes an interrupt configuration unit 2811, an execution scheduling unit 2812, and an interrupt receiving unit 2813.
  • the client interruption management unit 291 includes an interrupt scheduling unit 2911, an interrupt distribution unit 2912, and an interrupt trigger unit 2913.
  • the interrupt vector table 31 and the running entity table 32 store information necessary for processing an interrupt request.
  • both tables in this embodiment are located in a storage area accessible by all virtual machines (all virtual processors) and the host, which also facilitates the implementation of the methods provided by all the embodiments described below. In other embodiments, the form and content of the two tables allow for some adjustments depending on the situation.
  • the interrupt vector table 31 is mainly used to record the identifier of the application interrupt request and the processing body and interrupt service program corresponding to the application interrupt request. Further, information of the IPI interrupt request and/or the guest operating system interrupt request can also be recorded.
  • the interrupt vector table 31 may also include an identification of the guest operating system interrupt request, such as an IPI interrupt, and a corresponding processing body and interrupt service routine.
  • the running entity table 32 is mainly used to record the current state of all vCPUs included in each VM, such as whether it is in place, and to record interrupt requests to be processed by each vCPU.
  • Tables 1 and 2 are examples of the interrupt vector table 31 and the running entity table 32, respectively.
  • Table 1 stores only the IRQ ID of the application interrupt request and the processing body and interrupt service program corresponding to the application interrupt request. If the IRQ ID of an interrupt request is not in the table, then by default the interrupt request needs to be processed by the host, and the interrupt request will be sent to (or injected) the host to facilitate the host to process the interrupt request.
  • the identifier of all interrupt requests may also be stored in Table 1, and the processing body is recorded as a virtual machine or a host; or the identifier of all interrupt requests is stored, but the VM ID is empty, indicating that the processing host is the host. ,Wait.
  • Table 1 the processing body is recorded as a virtual machine or a host; or the identifier of all interrupt requests is stored, but the VM ID is empty, indicating that the processing host is the host. ,Wait.
  • the specific data structure of the vCPU LIST in the embodiment of the present invention can be implemented as a bitmap, and each bit in the bitmap represents a vCPU.
  • the PRIORITY in Table 1 records the priority of the interrupt request.
  • the priority setting mode of the interrupt request needs to be similar to the setting of the priority of the vCPU in the VMM (refer to Table 2), so that the subsequent two priorities can be compared.
  • the priority of an interrupt request can be different from the priority of the vCPU that handles the interrupt request.
  • the comparison result of the two priorities can be used as a basis for judging which vCPU runs after the interrupt request arrives in some embodiments.
  • PRIORITY is configured before the associated VM starts.
  • the user can be configured by interrupting the unified configuration interface (sysfs interface or proc interface) of the configuration unit (2811).
  • the interrupt type TYPE can also be configured in a similar manner.
  • the content stored in the interrupt vector table 31 and the running entity table 32 may be less or more than the examples of Table 1 and Table 2.
  • the VM IDs in the two tables may not be stored.
  • some scenarios are convenient to store.
  • an interrupt request can be processed by all vCPUs of a VM. In this case, only the VM ID is judged; some embodiments may not store PRIORITY and/or TYPE information.
  • Each virtual machine (29-1 and 29-2) and the host machine have a configuration channel 33 and an injection channel 34.
  • the configuration channel 33 is mainly used by the client interrupt management unit 291 to fill in the interrupt vector table 31, and the injection channel 34 is mainly
  • the interrupt request management unit 291 is used by the client interrupt management unit 291 to inject an interrupt request to be processed by the host into the host, so that the host interrupt management unit 281 processes the interrupt request.
  • the virtual machine and the host respectively contain a plurality of interrupt service programs (292 and 283) for processing the interrupt request after being called.
  • the interrupt service routine 292 in the virtual machine is typically deployed by the application installed on it to handle application interrupt requests. Of course, some 292 are deployed by the guest operating system 290 to handle guest operating system interrupt requests.
  • the host machine further includes a host interrupt distribution unit 282 for receiving an interrupt request received by the host interrupt management unit 281 (specifically, the interrupt receiving unit 2813) from the client interrupt management unit 291, and calling the interrupt service corresponding to the interrupt request.
  • Program 283 The host interrupt distribution unit 282 is also present in some existing virtualization architectures, and is used in this embodiment to receive interrupt requests from the host interrupt management unit 281 rather than directly from the APIC 260.
  • the other modules of FIG. 5 are similar to FIG. 4 and will not be described again.
  • FIG. 6 is a schematic diagram of an initialization process of the host interrupt management unit 281.
  • the host interrupt management unit 281 performs initialization with the initialization of the VMM.
  • the initialization of the interrupt configuration unit 2811 includes preparing the configuration channel 33 (S5011) and preparing the interrupt vector table 31 (S5012).
  • Preparing to configure channel 33 (S5011) includes hooking the hypercall function used as configuration channel 33 to the VMM's hypercall framework so that virtual machines (29-1 and 29-2) can call the function via hypercall to use the configuration channel. 33.
  • the preparation of the interrupt vector table 31 (S5012) includes determining the shared memory area, dividing the entry of the interrupt vector table 31, and the like (refer to Table 1). This shared memory area is used to store the contents of the interrupt vector table.
  • the initialization of the execution scheduling unit 2812 (S502) includes preparing to run the entity table 32 (S5021).
  • Preparing to run the entity table 32 (S5021) includes determining another shared memory area, dividing the entries of the running entity table 32, etc. (refer to Table 2).
  • the shared memory area is used to store the contents of the running entity table 32.
  • the "shared memory area” provided in this embodiment is a section of storage area accessible by all virtual machines (29-1 and 29-2) and the host.
  • the initialization of the interrupt receiving unit 2813 includes preparing the injection channel 34 (S5031), specifically including hooking the hypercall function for interrupt injection into the hypercall framework of the VMM, so that the virtual machines (29-1 and 29-2) This function can be called via hypercall.
  • the initialization of the above three units may be performed before or after the initialization of the core module of the VMM is completed, or after the initialization completion portion of the core module of the VMM, and then the core module of the VMM continues to complete the remaining initialization.
  • the initialization of the above three units may be performed in parallel or in series, and the execution order is not limited in the embodiment of the present invention.
  • the host interrupt management unit 281 is also initialized. After that, VMM will create and launch two virtual machines (29-1 and 29-2). During the creation and startup of the virtual machines (29-1 and 29-2), the client interrupt management unit 291 completes the initialization.
  • the entire boot process of a virtual machine is divided into two parts: before the vCPU is trapped and after the vCPU is trapped.
  • the VMM 180 creates and initializes a VM object.
  • the VMM 180 creates a primary vCPU and a secondary vCPU for the VM object.
  • one virtual machine has three vCPUs, the other one is the main vCPU, and the other two are slave vCPUs.
  • the main vCPU and one of the vCPUs are introduced as an example, and another vCPU initialization process and the introduction are introduced. Similar to vCPU.
  • the VMM 180 configures the interrupt receiving mode of the main vCPU and the slave vCPU and the APIC260 operating mode.
  • the purpose of the configuration is to enable the vCPU to receive interrupt requests sent by the APIC in client mode (ie, after trapping), and the vCPU can operate APIC 260 in client mode.
  • the parameters customized here are defined in the present application, and these parameters are used to notify the VMM to configure the VM according to the above. These two modes of the vCPU are indicated by different bits on the corresponding register of the vCPU.
  • the vCPU can receive the interrupt request and operate the physical APIC without being trapped.
  • the bit 0 (external-interrupt exiting) of the Pin-Based VM-Execution Controls control bit of the VMCS (virtual machine control structure) is set to 0, and the interrupt request can be received without trapping;
  • the Pin of the VMCS is -Based VM-Execution Controls control bit 7 (process posted interrupts) is set to 0, VMCS Primary Processor-Based VM-Execution Controls control bit bit bit bit bit bit bit 21 (Use TPR Shadow) is set to 0, VMCS Secondary Processor-Based VM-
  • the Execution Controls control bit 8 (APCI-register virtualization) and bit 9 (Virtual-interrupt delivery) are set to 0.
  • the value of the memory object involved in the interrupt receiving mode and the APIC260 operating mode is configured in the step S603 (the value is recorded in the memory in essence), and the physical register has not been actually modified.
  • This step S603 can be implemented by the interrupt configuration unit 2811 in the host interrupt management unit 281.
  • the VMM 180 dispatches the primary vCPU and the secondary vCPU to the physical core, respectively, but the primary vCPU and the secondary vCPU are not yet trapped.
  • the VMM 180 records the VM ID of the current vCPU, the vCPU ID, the CORE ID of the physical core corresponding to the vCPU, and the priority of the vCPU into the running entity table 32.
  • the priority of the vCPU is usually set in the VMM, so the VMM can get it.
  • the plurality of vCPUs each update the running entity table 32 before plunging.
  • the embodiment will set the vCPU to fall immediately after updating the running entity table, so the record CORE ID at this time is consistent with the meaning of the previously described table 2.
  • This step S605 can be implemented by the execution scheduling unit 2812 in the host interrupt management unit 281. Not only the initialization phase, but after each vCPU is swapped in, after the client mode is trapped, and before the vCPU is swapped out, the execution scheduling unit 2812 needs to update the running entity table 32 to ensure that the vCPU recorded in the running entity table 32 is in place or not in place. The status is accurate.
  • the main vCPU and the slave vCPU are in client mode.
  • the main vCPU reads the values of the attributes corresponding to the interrupt receiving mode and the APIC operation mode set in step S603 from the respective corresponding memories when the vCPU is trapped, and modifies the respective registers accordingly.
  • the register modified here is the physical register corresponding to the physical core on which the vCPU runs.
  • the main vCPU and the vCPU are in client mode, they are initialized differently.
  • the main vCPU executes the guest operating system (guest OS) initialization, while the vCPU only performs initialization from the vCPU.
  • guest OS guest operating system
  • the client interrupt management unit 291 After the guest operating system and the pre-initialization phase (S607 and S607-d) of the slave vCPU are completed, the client interrupt management unit 291 starts performing initialization (S608 and S608-d).
  • the initialization of the client interruption management unit 291 includes:
  • the interrupt distribution unit 2912 acquires the address information of the interrupt vector table 31 through the configuration channel 33 provided by the interrupt configuration unit 2811 (only the main vCPU needs to be executed).
  • the address information may specifically be the start address and the end address of the interrupt vector table 31 in the memory.
  • the interrupt distribution unit 2912 acquires the VM ID presence variable through the configuration channel 33 provided by the interrupt configuration unit 2811 (only the main vCPU needs to be executed).
  • the VM ID may also not be obtained in some other embodiments.
  • the interrupt distribution unit 2912 acquires that the current vCPU ID is saved in the variable. Both the master and slave vCPUs need to be executed, and the vCPU IDs are saved in their respective variables.
  • the interrupt distribution unit 2912 configures the address of the entry function of the client interrupt management unit 291 in the corresponding register of each vCPU, so that each vCPU can directly acquire and execute the address of the entry function in the read register when receiving the interrupt request.
  • the client interrupts the function of the management unit 291. Since the interrupt distribution unit 2912 is first used in the present embodiment, the entry function of the client interruption management unit 291 is the entry function of the interrupt distribution unit 2912 in this embodiment.
  • the interrupt descriptor table register can be modified by the lidt instruction. Specifically, an interrupt descriptor table (IDT) is loaded into the IDTR by the lidt instruction, and the IDT table is used. The entry function address in the interrupt processing is filled in as the entry function of the interrupt distribution unit 2912.
  • the register vbar_el1 vector base address register el1
  • the msr instruction is modified by the msr instruction.
  • the “entry function” of a program refers to the function that is called when the program (or the functional unit or module) is started.
  • the “entry function for interrupt processing” refers to the function of the first instruction executed after the vCPU is interrupted by the interrupt request. For example, after the vCPU is interrupted by the interrupt request, the first instruction to be executed is the instruction of the interrupt distribution unit 2912, and the entry function of the interrupt processing should be set as the entry function of the interrupt distribution unit 2912.
  • the guest operating system After completing the initialization of the client interruption management unit 291, the guest operating system enters the initialization process of the latter stage (S613 and S613-d) until the initialization of the guest operating system is completed, and the guest operating system enters the application (or service). The status of the run. Thereafter, the application can be deployed on the guest operating system, and the application can register the ISR by interrupting the interface provided by the distribution unit 2912 (S614 and S614-d).
  • the interrupt distribution unit 2912 notifies the interrupt configuration unit 2811 through the configuration channel 33, after which the vCPU is trapped (S615), and then the interrupt configuration unit 2811 modifies the interrupt vector table 31, thereby filling the registration information into the interrupt vector table 31, after which The vCPU is immediately trapped again (S616).
  • each unit in the virtual machine can be understood as being implemented after the vCPU reads and executes the program or instruction of the unit.
  • the interrupt distribution unit 2912 notifies the interrupt configuration unit 2811 through the configuration channel 33, which can be regarded as a program of the vCPU read interrupt distribution unit 2912, thereby calling the hypercall function of the configuration channel 33 according to the program (after which the vCPU sinks into the host mode), Then, the host (the host thread corresponding to the vCPU) reads the program of the interrupt configuration unit 2811, thereby modifying the interrupt vector table according to the program, and the vCPU immediately falls into the client mode after the modification is completed.
  • the host interrupt management unit 281 is located in the VMM, so the action performed by the host interrupt management unit 281 can also be understood as the action performed by the VMM. Whether it is the execution of each unit or vCPU in the virtual machine, or the execution of each unit in the VMM or the host, in the end, the physical processor runs the software program execution.
  • step S603 Since the interrupt configuration unit 2811 has written the configuration into the vCPU object created by the VMM (refer to step S603), each time the vCPU is trapped, the value of the physical register corresponding to the vCPU can be set according to the configuration, thereby achieving the vCPU after the trapping. Receive all interrupt requests directly from the APIC without trapping, and the vCPU can directly manipulate the effects of the physical APIC.
  • the virtualized device has entered the running state, and the virtual machine deployed on it and the application on the virtual machine are running.
  • the process of processing an interrupt request during the operation of the virtualization device proposed in this embodiment is described in detail below.
  • a certain hardware generates an interrupt request and transmits the interrupt request to the APIC 260 (S701a), for example, the hardware network card generates an interrupt request, and transmits the interrupt request to the APIC 260.
  • the APIC 260 transmits the interrupt request to a certain physical core according to a specific rule, and execution of the vCPU running in the client mode on the physical core is interrupted (S702a). After the execution of the vCPU is interrupted, since the vCPU has been configured before, the interrupt can be received in the client mode without trapping, so the vCPU directly jumps to the entry function of the interrupt distribution unit 2912 stored in the execution register, and sends the interrupt request to the interrupt function.
  • the distribution unit 2912 is interrupted (S703a), so that the functions of the client interruption management unit 291 are gradually functioning. Some interrupt requests are sent to multiple physical cores by APIC260. Each physical core is processed in a similar manner to the foregoing, and will not be described again.
  • the sending process of the interrupt request may be different in different computer architectures.
  • the APIC260 includes io-APIC and local-apic, wherein the io-apic is responsible for collecting all hardware-generated interrupt requests. And send the corresponding local-apic accordingly, then loca-apic is forwarded to the corresponding physical core.
  • This process is generally described in the present embodiment as a simplified representation in which the APIC 260 sends an interrupt request to a physical core.
  • the interrupt request is sent to a physical core, but the physical core's vCPU is not in the bit, that is, the physical core is in the host mode, the functional unit on the host is running,
  • the functional unit is typically a VMM, then the physical core (ie, the VMM) will not process the interrupt request because the host mode interrupt response bit is turned off.
  • An embodiment will be provided later to provide a compensation method that describes how the VMM handles the interrupt request without shutting down the interrupt response bit of the host mode.
  • the interrupt distribution unit 2912 identifies the IRQ ID of the interrupt request, and transmits the IRQ ID to the interrupt scheduling unit 2911 (S701b).
  • the interrupt scheduling unit 2911 queries the processing body of the interrupt request in the interrupt vector table and the address of the ISR corresponding to the interrupt request according to the IRQ ID, that is, the vCPU list and the ISR ADDR corresponding to the IRQ ID in the foregoing Table 1 (S702b).
  • the interrupt scheduling unit 2911 determines whether the ISR ADDR can be queried (S703b).
  • the interrupt scheduling unit 2911 returns the query result to the interrupt distribution unit 2912 (S704b), and then interrupts.
  • the distribution unit 2912 injects the interrupt request into the host machine through the injection channel 34 (S705b).
  • the interrupt distribution unit 2912 can send the interrupt request to the interrupt receiving unit 2813 in the host through the injection channel 34, and the interrupt receiving unit 2813 sends the interrupt request to the host interrupt distribution unit 282, and then the host interrupts the distribution.
  • Unit 282 calls the ISR in the host that corresponds to the interrupt request.
  • the processing of the host interrupt distribution unit 282 is prior art and will not be described in detail herein.
  • the interrupt scheduling unit 2911 determines whether the current vCPU (ie, the previously executed vCPU) is included in the queried vCPU list, that is, whether the current vCPU is one of the processing subjects of the interrupt request (S706b) .
  • the application interrupt request and the guest operating system interrupt request are stored in the interrupt vector table 31. Therefore, the above determination method is used when determining the processing body. In other embodiments, if the interrupt vector table 31 is present, There is a change in the content, and the method of determining the processing subject can also be adaptively changed.
  • the interrupt scheduling unit 2911 returns the ISR ADDR obtained by the query to the interrupt distribution unit 2912 (S707b), and then the interrupt distribution unit 2912 notifies the interrupt trigger unit 2913 of the call of the ISR ADDR.
  • the interrupt service routine (S708b) is processed by the interrupt service routine. At this point, the interrupt request is processed, and the vCPU will return to the previously interrupted position to continue execution.
  • the running entity table 32 may be queried to determine that the vCPU in the vCPU LIST does not exist (S709b).
  • the interrupt scheduling unit 2911 selects a vCPU from the in-place vCPUs, and then sends an IPI interrupt to the selected vCPU (S710b) ).
  • the IPI interrupt carries an identifier (IRQ ID) of the interrupt request, so that the selected vCPU processes the interrupt request.
  • IRQ ID an identifier of the interrupt request
  • the interrupt scheduling unit 2911 selects the target vCPU from the vCPU LIST and updates the running entity table 32 (S711b).
  • the update running entity table 32 includes recording a PENDING bit corresponding to the target vCPU in the running entity table 32, and recording the value of the bit as the IRQ ID of the interrupt request, so that the target vCPU processes the interrupt request.
  • the "target vCPU" may include all vCPUs in the vCPU LIST, or may be any vCPU of any choice.
  • the interrupt scheduling unit 2911 can also actively trigger the swapping of the target vCPU (S712b), so that the interrupt request is processed as soon as possible.
  • Which vCPU is selected as the target vCPU and whether the vCPU is actively triggered can be determined according to the priority of the interrupt request and the priority of the vCPU. The specific method will be described in detail in the following embodiments.
  • the process of the target vCPU processing the interrupt request specifically includes: after the target vCPU is swapped in by the host and into the client mode, the execution scheduling unit 2812 in the host reads the PENDING bit in the running entity table 32, and The target vCPU is sent an interrupt request of the same IRQ ID as the interrupt request, so that the target vCPU can process the interrupt request after being trapped in the client mode.
  • the number of "target vCPUs" may be one or more. If the interrupt request only needs one vCPU processing, after performing the interrupt transmission to the first target vCPU, the PENDING bit corresponding to the other vCPUs is cleared to prevent the interrupt from being processed again when other vCPUs are trapped.
  • vCPU after a vCPU receives the interrupt request, the vCPU also needs to save the state of the interrupted task and perform other operations, so that the vCPU can return to continue the interrupted task after the interrupt request processing is completed.
  • the interrupt scheduling unit 2911 determines that the current vCPU is not included in the queried vCPU LIST, and may also directly update the running entity table 32 to set the PENDING position of all vCPUs included in the vCPU LIST to the interrupt request. IRQ ID.
  • the vCPU can directly receive almost all interrupt requests sent by the APIC in the client mode, that is, the interrupt can be directly passed to the client interrupt management unit 291 of the virtual machine, thereby making The vCPU does not need to be trapped/trapped when processing an application interrupt request, so that the application interrupt requesting such a service level interrupt request has a shorter response and processing path, thereby reducing the processing delay of the application interrupt request.
  • the method provided by the present application can ensure ultra-low latency requirements for response and processing of service interruption requests in high-traffic execution environments and high concurrent execution environments, and can be applied to 5G (5th-Generation) and the like to be supported by ultra-low latency. Business scenario.
  • non-service level interrupt request is injected into the host layer through the injection channel 34, and then processed or re-distributed by the host interrupt management unit 281 and/or the host interrupt distribution unit 282 in the host machine to ensure the application. In the case of efficient processing of interrupt requests, timely processing of other interrupt requests is also guaranteed.
  • the interrupt request is recorded by the running entity table 32 shared among the plurality of vCPUs, and the target vCPU can view and process the interrupt request after the swapping in.
  • the VMM interrupts the interrupt request process, which further improves the processing efficiency of the interrupt request.
  • the vCPU that is temporarily out of position can delay receiving and processing interrupt requests. In the scenario of multi-vCPU co-core and vCPU non-exclusive core, the loss of interrupt request is effectively avoided.
  • the vCPU that receives the interrupt request is not the processing body of the interrupt request, not only the running entity table is updated, but also the swapping of the processing body of the interrupt request is actively triggered, thereby further improving the processing efficiency of the interrupt interrupt request.
  • step S702a in the foregoing embodiment after receiving an interrupt request, the APIC sends the interrupt request to a certain (or multiple) physical cores according to a specific rule, and is processed by the running vCPU on the physical core. If no special rules are set, such as APIC random transmission or transmission according to the prior art, in the scenario of over-allocation (multi-vCPU co-core), the interrupt request is likely to be sent to a vCPU that cannot handle the interrupt request. Therefore, the embodiment described below provides a configuration method for interrupt affinity, which enables the interrupt request to be sent to the vCPU that can process the interrupt and is currently in position, so that the steps S709b and S710b are not required to be performed. Further improve the processing efficiency of the interrupt.
  • the interrupt affinity is stored as an attribute of the interrupt controller and is stored in the interrupt controller, indicating the affinity of the interrupt request to the physical core.
  • the interrupt request will be sent by the interrupt controller to the physical core that is related to the interrupt request.
  • the affinity of an interrupt request may be implemented as a affinity list corresponding to the interrupt, and the affinity list includes all CORE IDs of physical cores that can receive the interrupt request.
  • the interrupt affinity of all interrupt requests is stored in the io-APIC; and when there are multiple peripherals
  • the interrupt affinity of the interrupt request generated by different hardware is stored in different interrupt control components, and can be updated separately according to the manners described in the following embodiments.
  • the configuration of the interrupt affinity proposed in this embodiment is executed after a vCPU is swapped in by the VMM, before being dumped into the client mode, and when the vCPU is swapped out by the VMM.
  • This configuration can be implemented by the execution scheduling unit 2812 in the host interrupt management unit 281.
  • 9A and 9B illustrate the configuration process of interrupt affinity.
  • the execution scheduling unit 2812 turns off the VMM external interrupt response (S801a), specifically, modifying the register bit of the vCPU in the host mode to indicate that the external interrupt is turned off, so that the VMM Unable to receive and process interrupt requests.
  • the CORE ID (S802a) of the physical core running by the vCPU is obtained by calling a function.
  • the CORE ID is obtained by calling the smp_processor_id() function.
  • the register bit here is the i bit of the current program status register (cprs) in the ARM64 architecture, and the cli instruction is implemented in the X64 architecture.
  • the running entity table is also updated at this time. Specifically, the VM ID and the vCPU ID to which the vCPU belongs, and the CORE ID are recorded in the running entity table (S803a).
  • the execution scheduling unit 2812 In addition to updating the running entity table, in order to implement the interrupt affinity configuration, the execution scheduling unit 2812 first obtains all interrupt requests that the vCPU can process from the interrupt vector table according to the vCPU ID (IPI does not need to be set), and then accesses the APIC, The affinity of these interrupt requests in the APIC plus the physical core (that is, the previously obtained CORE ID) that the vCPU runs (S804a), so that the APIC can send these interrupt requests to the physical core upon receiving these interrupt requests. .
  • the operation S804a of the affinity configuration may be performed once after the vCPU is first switched in when the VM is started, and the interrupt controller is not required to be changed every time the vCPU is swapped in, because the vCPU runs.
  • the physical core is unchanged.
  • the execution scheduling unit 2812 Before the vCPU is trapped, the execution scheduling unit 2812 also needs to query the running entity table 32. If the value of the PENDING bit is not -1, indicating that the interrupt request is not processed, the vCPU is actively given according to the IRQ ID of the PENDING bit. Send an interrupt request with the same characteristics. Because the host mode (or host) interrupt reception is turned off, the vCPU can receive and process the interrupt request only after it has been trapped.
  • FIG. 9A describe that the interrupt affinity needs to be updated when the vCPU is about to fall, and accordingly, the interrupt affinity is also updated when the vCPU is about to be swapped out.
  • the execution scheduling unit 2812 acquires the CORE ID (S801b) of the physical core of the vCPU, and then executes the CORE corresponding to the vCPU ID of the vCPU in the entity table 32.
  • the entry of the ID is updated to -1 (S802b).
  • the interrupt affinity also needs to update the configuration (S803b).
  • the execution scheduling unit 2812 first obtains all interrupt requests that the vCPU can process from the interrupt vector table 31 according to the vCPU ID (IPI does not need to be set), and then accesses the APIC to subtract the affinity of the interrupt requests in the APIC.
  • the S801b step may also not be performed.
  • the vCPU ID may also be used to ensure that the CORE ID to be modified is found.
  • the operation S803b can be performed only once after the VM is exited.
  • the necessity of distributing some interrupt requests between vCPUs is removed, so that in the vCPU non-binding scenario, the interrupt request can hit the target vCPU with the greatest probability, thereby further shortening the processing time of the interrupt request. , reduce the interruption delay.
  • the interrupt scheduling unit 2911 determines that the current vCPU is not included in the vCPU LIST (S706b), this step of S709b need not be performed because all vCPUs are not in place. Step S710 also does not need to be performed.
  • the interrupt scheduling unit 2911 can continue processing in accordance with the fact that all vCPUs in the vCPU LIST are not in place.
  • the vCPU that receives the interrupt request is not the processing body of the interrupt request, and the processing body is not in the bit, it is necessary to determine the target vCPU that will process the interrupt request from the processing body of the interrupt request.
  • the following embodiment will detail how the target vCPU is determined and how to handle the interrupt request after it is determined.
  • the method provided by this embodiment can be used for an embodiment in which no interrupt affinity is configured, and can also be used in an embodiment in which interrupt affinity is configured.
  • Table 1 and Table 2 record the priority of the interrupt request and the priority of the vCPU, respectively.
  • the interrupt scheduling unit 2911 queries Table 1 to obtain the priority of the interrupt request.
  • the value of the priority of the interrupt request when the value of the priority of the interrupt request is greater than or equal to 0, it is necessary to compare with the priority of the vCPU in the bit to determine whether to preempt the vCPU in place.
  • the value When the value is negative, it does not need to be compared with the priority of the vCPU in the bit. Specifically, when it is -1, it will never preempt the vCPU in place; when it is -2, it will directly preempt the current vCPU that receives the interrupt request. .
  • the interrupt priority defaults to -2. There are many ways to set and judge the priority. This application does not list them one by one. In this way, the following method is introduced as an example.
  • the priority of the vCPU mentioned here refers to the priority of the current task on the vCPU.
  • the interrupt scheduling unit 2911 registers the HOOK of the task switching of the guest operating system at the time of initialization, and executes the HOOK when the guest operating system task is switched.
  • the job of the HOOK is to update the priority of the task that the guest operating system is preparing to switch to the PRIORITY in Table 2.
  • the priority of the interrupt request is -1, it indicates that the priority of the interrupt request is extremely low, and is not compared with the priority of the vCPU in the bit, and the PENDING bit can be directly recorded as described in the above paragraph.
  • the interrupt request Unless the interrupt request is an interrupt request that requires multi-core processing, after a vCPU is sent the interrupt request, the PENDING bits of other vCPUs need to be cleared, so that not all vCPUs will process the interrupt request.
  • the interrupt scheduling unit 2911 selects the vCPU with the lowest priority as the "transit vCPU" in the interrupt request.
  • the vCPU with the highest priority is selected as the target vCPU in the corresponding vCPU LIST, and the corresponding PENDING bit of the target vCPU is modified to the IRQ ID of the interrupt request.
  • the interrupt scheduling unit 2911 notifies the interrupt distribution unit 2912 to send an IPI interrupt to the transit vCPU (ie, the current vCPU sends an IPI interrupt to the transit vCPU), and the IPI interrupt carries the vCPU ID of the target vCPU.
  • the IPI interrupt can also carry the IRQ ID of the interrupt request to be processed, but it is not necessary because the pending IRQ ID has been recorded in the PENDING bit of the target vCPU in the previous step. If the IRQ ID is not recorded in front of the method, it needs to be carried here so that the target vCPU that is swapped in knows that it wants to process the interrupt request.
  • the transit vCPU is selected from the in-place vCPU, so the transit vCPU is currently in place.
  • the transit vCPU executes the ISR corresponding to the IPI interrupt (this ISR is also registered in Table 1, and can be registered by the interrupt trigger unit 2913).
  • the implementation of the ISR corresponding to the IPI interrupt is: when it is determined that the vCPU ID of the target vCPU carried in the IPI interrupt is different from the vCPU ID of the transit vCPU (as in this embodiment), the interrupt is received by the injection channel 32 to the host.
  • the unit 2813 performs reverse injection, and the parameter is the vCPU ID of the target vCPU (optionally, may also include an IRQ ID), and the transit vCPU is trapped after the injection.
  • the interrupt receiving unit 2813 determines that the vCPU ID of the target vCPU is carried therein (indicating that the processing entity of the interrupt request is not the host), so the vCPU ID of the target vCPU is sent to the VMM for scheduling the vCPU scheduling. So that the VMM swaps in the target vCPU and swaps out the transit vCPU.
  • the reason why the swap vCPU is swapped out is because the transit vCPU is the lowest priority vCPU in this embodiment, and swapping out it can minimize the impact of the interrupt request on the current task.
  • other vCPUs may be swapped out according to the situation, which is not limited in this application.
  • the execution scheduling unit 2812 queries the PENDING bit of the running entity table 32 to determine that the target vCPU has an interrupt request unprocessed, and then actively sends the target vCPU an same as the unprocessed interrupt request. Interrupt the request so that the target vCPU is processed after it is trapped in client mode.
  • the interrupt scheduling unit 2911 immediately selects the vCPU with the highest priority from the vCPU LIST as the target vCPU (or any Select one), and then call the ISR corresponding to the IPI in Table 1 (the vCPU ID carrying the target vCPU).
  • the specific implementation of the ISR is: determining that the vCPU ID of the target vCPU is different from the vCPU, and performing reverse injection, the parameter target vCPU ID, to the interrupt receiving unit 2813 of the host through the injection channel 32.
  • the current vCPU immediately sinks after the injection.
  • the interrupt receiving unit 2813 determines that the vCPU ID of the target vCPU is carried in the injection (indicating that the processing body of the interrupt request is not the host), and sends the vCPU ID of the target vCPU to the VMM for execution.
  • the vCPU schedules the scheduler so that the VMM swaps in the target vCPU and swaps out the current vCPU. Similar to the previous method, the IRQ ID may or may not be carried.
  • one vCPU sends an IPI interrupt to another vCPU.
  • the following embodiment details how a vCPU sends an IPI interrupt to another vCPU.
  • These two vCPUs can be located in the same VM or in different VMs.
  • the two vCPUs in the following embodiments are referred to as vCPU A and vCPU B, respectively.
  • the embodiment can be referred to accordingly.
  • the interrupt scheduling unit 2911 directly operates the APIC to send an IPI interrupt to the physical core on which the vCPU B is running.
  • the relay vCPU mentioned in the foregoing embodiment is a vCPU selected from the in-place vCPUs, so it is suitable for this step.
  • the interrupt scheduling unit 2911 directly operates the local-apic corresponding to the physical core running by the vCPU A to send an IPI interrupt to the local-apic corresponding to the physical core operated by the vCPU B.
  • the IPI interrupt is recorded on the PENDING bit associated with vCPU B in runtime entity table 32 to facilitate processing of the IPI interrupt after vCPU B is swapped in. Specifically, after vCPU B is swapped in, before the trap, the PENDING bit is queried, and then an identical IPI interrupt is sent to itself, and the IPI interrupt is processed after the trap.
  • IPI interrupt request is a special interrupt, but the processing procedure is similar to the interrupt request in the foregoing embodiment. Therefore, reference may be made to the foregoing embodiment, and details are not described herein again.
  • the vCPU can directly operate the interrupt controller to send an IPI interrupt without trapping, thereby improving the processing speed of the IPI interrupt.
  • the IPI carries the IRQ ID, and may also carry the IRQ ID and the vCPU ID.
  • the vCPU ID carried is not necessarily the ID of the vCPU B.
  • the IRQ ID means that the role of the IPI is to notify other vCPUs to process the interrupt request indicated by the IRQ ID.
  • the vCPU ID indicates the vCPU (i.e., the target vCPU in the foregoing embodiment) that needs to process this interrupt request.
  • the vCPU B queries Table 1 to call the ISR corresponding to the IPI interrupt to process the IPI interrupt.
  • the specific implementation of the ISR is that if it is determined that the carried vCPU ID is the same as vCPU B or there is no vCPU ID (indicating that vCPU B is the processing body of the interrupt request), query table 1 calls the ISR corresponding to the carried IRQ ID to process the If the vCPU ID is different from the vCPU B, the vCPU ID of the target vCPU is sent to the host through the injection channel 34. Then the vCPU B will sink.
  • the host sends the vCPU ID to the scheduler in the VMM for performing vCPU scheduling, so that the VMM swaps in the vCPU indicated by the vCPU ID.
  • a vCPU wants to send an IPI interrupt to another vCPU without sinking, the host needs to configure the interrupt controller operating mode of the vCPU so that the vCPU can operate the interrupt controller to another without trapping.
  • a vCPU sends an IPI interrupt.
  • interrupt request that requires multiple vCPU processing
  • the following embodiment will describe a method of "interrupt copying" proposed by the present application.
  • a vCPU queue 35 shared by the host and the virtual machine is introduced for each physical core.
  • the vCPU queue 35 of a physical core contains the vCPU that was last run on the physical core. If a vCPU is swapped out of the VMM from the physical core, the execution scheduling unit 2812 joins the vCPU to the vCPU queue 35. If the vCPU is scheduled by the VMM to run on another physical core, the execution scheduling unit 2812 deletes the vCPU from the vCPU queue 35.
  • vCPU queue 35 is created for each physical core, and these queues are stored in a storage area that the host and the virtual machine can share.
  • the detailed procedure of registration can refer to the process of applying the registration interrupt request in the foregoing embodiment.
  • the interrupt scheduling unit 2911 further needs to query the TYPE item of the interrupt vector table according to the IRQ ID of the interrupt request (S901), and determine whether the value of the TYPE item is 1 (S902). .
  • the interrupt vector table 31 and the vCPU queue 35 of the physical core on which the vCPU is running are searched (S903), and it is sequentially determined whether the vCPU in the vCPU queue 35 is in correspondence with the IRQ ID.
  • vCPU LIST (S904), if yes, record the PENDING bit corresponding to the vCPU in the running entity table 32, and determine the transit vCPU, by sending an IPI interrupt to the transit vCPU to finally implement the VMM scheduling of the vCPU, the vCPU is The interrupt request is processed after the schedule is swapped in (S905). For more details on triggering vCPU swapping, reference may be made to the previous embodiments.
  • clock interrupts are a special and important interrupt for an operating system. If the clock interrupt can be directly received by the vCPU in the client mode, the response time of the clock interrupt can be greatly shortened, and its accuracy can be greatly improved. For example, currently under normal circumstances, receiving an interrupt request vCPU needs to sink and sink, then the interrupt latency is 10us+. This means that setting a 5us clock interrupt (to do a lightweight thing with a frequency of 5us, such as a thing that only takes 300ns) is impossible. With the method provided by the embodiment of the present invention, the clock interrupt can directly pass through the client mode, and multiple vCPUs can receive and process the clock interrupt periodically, and the delay of the clock interrupt is greatly reduced, and this setting is possible.
  • Some of the foregoing embodiments turn off the VMM's interrupt response each time the vCPU is swapped in, but in some complex virtualized computer systems it is not allowed to turn off the interrupt response.
  • the following embodiments provide a compensation for such a system. Mechanisms to speed up the processing of application interrupt requests.
  • the host layer adds an interrupt mapping table 284 and a VMM interrupt service routine 2814.
  • the VMM interrupt service routine 2814 is registered in the interrupt mapping table 284, so that the VMM can pass the interrupt mapping after receiving the application interrupt request.
  • Table 284 finds the VMM Interrupt Service Routine 2814.
  • the host interrupt distribution unit 282 queries the interrupt map 284 to invoke the processing function corresponding to the application interrupt request, namely the VMM interrupt service routine 2814.
  • the VMM interrupt service routine 2814 then performs the following actions based on the interrupt vector table 31 and the running entity table 32:
  • the vCPU in the vCPU LIST corresponding to the application interrupt request is not in the bit, refer to the processing manner of modifying the PENDING bit in the foregoing embodiment, and the PENDING bit of all vCPUs may be modified, or may be referred to the foregoing embodiment according to the interrupt priority. deal with. In this way, the interrupt request can be processed after the vCPU is swapped in. If there is an associated vCPU in place, the IPI can be sent to the in-place vCPU for interrupt processing according to the previous embodiment.
  • VMM interrupt service routine 2814 are similar to those of the client interrupt management unit 291 in the foregoing embodiment, so that more specific implementations may refer to the foregoing embodiments.
  • the structure and type of the interrupt vector table and the interrupt map may be the same.
  • the present application has different names for distinguishing the two, and "vector" and “mapping" are not intended to define anything.
  • the vCPU does not have to sink even if the application interrupt request is received in the host mode.
  • the application interrupt request is directed to the corresponding vCPU for processing, so that the solution provided by the present application can be applied to a complex computer system in which the host mode must be interrupted.
  • the processing of the guest operating system interrupt request can achieve the same effect.
  • the method provided by the present application can ensure the ultra-low latency of the service interruption request in response and processing under the high service capacity and high concurrent execution environment, and can be applied to services such as 5G that need to be supported by the system with ultra-low latency. Scenes.
  • the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, ie may be located A place, or it can be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • the connection relationship between the modules indicates that there is a communication connection between them, and specifically, one or more communication buses or signal lines can be realized.
  • the drawing device can be implemented by means of software plus necessary general hardware, and of course, the dedicated hardware can also include an ASIC. , dedicated CPU, dedicated memory, dedicated components, etc. to achieve.
  • functions performed by computer programs can be easily implemented with the corresponding hardware, and the specific hardware structure used to implement the same function can be various, such as analog circuits, digital circuits, or dedicated circuits. Circuits, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Stored Programmes (AREA)
  • Bus Control (AREA)
  • Multi Processors (AREA)

Abstract

本申请提供一种虚拟化设备及运行在该虚拟化设备上的中断处理方法。该方法包括：处理器在客户模式时执行如下操作：所述处理器从硬件接收中断请求；所述处理器根据所述中断请求与处理主体的对应关系确定所述接收到的中断请求的处理主体；当所述接收到的中断请求的处理主体包括所述处理器上当前运行的所述虚拟处理器时，所述处理器根据所述中断请求与中断服务程序的对应关系确定与所述接收到的中断请求对应的中断服务程序，并调用所述中断服务程序以处理所述中断请求。采用这种方式对于应用中断请求而言，可避免处理器的陷入陷出，从而减少应用中断请求的处理时延。

Description

中断请求的处理方法、装置及虚拟化设备 技术领域
本发明实施例涉及计算机技术，尤其涉及一种计算机内中断请求的处理方法以及虚拟化设备等。
背景技术
虚拟化技术通过将一台物理计算机增加特定的软件层次，包括宿主机层和虚拟计算机层，以实现对该物理计算机硬件的“虚拟”和“隔离”。每个软件层次包括不同的运行状态，例如用户态和内核态。软件层次和运行状态的多样化使得该物理计算机内部针对某些需求的处理环节增加，从而增加了这些需求的处理时延。
中断处理是虚拟化设备的关键需求，现有虚拟化设备的中断处理过程(指的是物理中断处理过程)是将硬件(比如网卡、键盘或鼠标等)产生的中断请求发送到处理器，然后处理器调用宿主机中的中断处理模块分发中断请求，当该中断请求需要某个虚拟计算机内的中断服务程序处理时，该中断处理模块将该中断请求再分发到该虚拟计算机，这种软件层次的跨越以及其中可能涉及的不同运行状态的切换增加了这种中断请求的处理时延。特别是，当虚拟计算机内部部署有实现业务的各种应用时，这些应用的中断服务程序均部署在虚拟计算机内，中断处理过程实际上是业务处理过程的一部分，因此这种时延的增加会导致业务处理时延的增加。
发明内容
本申请提供一种中断请求的处理方法、装置及虚拟化设备等，用以减少虚拟化设备中应用中断请求的处理时延，进而提升业务处理速度。
第一方面，本申请提供一种虚拟化设备，所述虚拟化设备包括硬件层、运行在硬件层上的宿主机和运行在宿主机上的虚拟计算机，所述虚拟计算机内包含有服务于该虚拟计算机的一个或多个虚拟处理器。
所述宿主机用于配置所述虚拟计算机的虚拟处理器能够从所述硬件层接收中断请求，通过修改寄存器位实现。具体的，所述宿主机通过修改寄存器中用于指示所述虚拟处理器的中断接收模式的寄存器位来实现所述虚拟处理器在客户模式下直接从所述硬件层接收所有中断请求。其中，虚拟处理器的中断接收模式用一个或多个寄存器位指示，该寄存器是与该虚拟处理器运行的物理处理器关联的物理寄存器，所以该配置步骤最终需要修改的是物理寄存器。
所述虚拟计算机(也可以说是下述的“当前虚拟处理器”)用于从所述硬件层接收中断请求；根据所述中断请求确定所述接收到的中断请求的处理主体；当所述接收到的中断请求的处理主体包括所述虚拟计算机的当前虚拟处理器时，所述虚拟计算机根据所述中断请求确定与所述接收到的中断请求对应的中断服务程序(具体是中断服务程序的地址)，并调 用所述中断服务程序以处理所述中断请求。具体的，接收到的中断请求中可以携带所述中断请求的标识，例如IRQ ID，后续根据标识确定处理主体和中断服务程序。
需要说明的是，在虚拟化设备中，虚拟计算机(例如虚拟机或libOS)执行动作可以理解为是服务于该虚拟计算机的一个虚拟处理器执行动作，所以“虚拟计算机的当前虚拟处理器”可以理解为是当上述配置被运行起来之后，正在执行上述配置的虚拟处理器。另外，本申请中中断请求的“处理主体”可能是一个或多个虚拟处理器，也可能是宿主机，当然这两种处理主体的本质都是物理处理器，是物理处理器的不同模式。
具体的，所述虚拟计算机根据一些信息和所述中断请求确定所述中断请求的处理主体和中断服务程序。这些信息包括中断请求(标识)、处理主体以及中断服务程序(地址)的对应关系。该信息存储在用它的虚拟处理器可以访问的存储区域，例如客户地址空间，这样虚拟处理器可以直接访问该信息，不需要陷出。该对应关系可以被宿主机更新。为了方便信息的管理和节省存储空间，这些信息中可以存储在多个VM的所有虚拟处理器均可以访问的存储区域中，以便于任意一个虚拟处理器访问。进一步的，宿主机也可访问该信息，因为宿主机可以更新这些信息。
可见，在这种虚拟化设备中，虚拟计算机可以直接从硬件层接收所有中断请求并进行中断请求的分发。当该中断请求的处理主体包括该虚拟计算机的当前虚拟处理器，那么该中断请求就可以直接被该虚拟计算机处理。如果一个中断请求是应用中断请求，且该中断请求的处理主体包括该虚拟计算机的当前虚拟处理器，那虚拟计算机就可以直接处理该中断请求，避免了虚拟计算机的陷入和陷出，避免了中断处理过程跨虚拟化设备的多个层次，从而降低了应用中断请求的处理时延。当然也降低了客户操作系统中断请求的处理时延。
结合第一方面，在第一种实现方式下，当所述虚拟计算机确定所述接收到的中断请求的处理主体为不包括所述虚拟计算机的当前虚拟处理器的其他虚拟处理器时，所述虚拟计算机判断所述其他虚拟处理器是否在位，若在位，则操作物理的中断控制器向所述其他虚拟处理器中在位的一个或多个虚拟处理器发送IPI中断请求，该IPI中断请求中携带所述接收到的中断请求的标识。这个操作的执行前提是宿主机配置所述虚拟处理器的中断控制器操作模式，使得该虚拟处理器能够操作物理的中断控制器，且是在不陷出的情况下操作。在位的虚拟处理器接收到该IPI之后，执行该IPI对应的中断服务程序，该中断服务程序的具体实现就调用IPI中携带的中断请求的标识对应的中断服务程序。
这里的“其他虚拟处理器”可以是为所述虚拟计算机服务的虚拟处理器，也可以是为其它虚拟计算机服务的虚拟处理器。与中断接收模式类似，虚拟处理器的中断控制器操作模式与该虚拟处理器所运行的物理处理器关联的寄存器的一个或多个位指示。
为了方便管理和节省空间，所有有关虚拟处理器在位或不在位的状态的信息可以存储在所有虚拟处理器均可访问的存储区域中，以供任意一个虚拟处理器访问。进一步的，该信息还可以被宿主机访问，因为宿主机可以在换入/换出虚拟处理器时修改虚拟处理器的状态。一个虚拟处理器向另一个虚拟处理器发送IPI中断请求时需要知道另一个虚拟处理器所运行的物理处理器，虚拟处理器所运行的物理处理器(例如下述实施例CORE ID)的信息也可以如前述状态信息类似的存储方式。下述利用虚拟处理器在位或不在位的方案或发 送IPI的方案也可以利用这些信息。
可见，虚拟计算机的当前虚拟处理器接收到一个中断请求，但却不是该中断请求的处理主体，且可处理该中断请求的虚拟处理器是在位的，这种情况下，当前虚拟处理器在不陷出的前提下直接通过IPI中断将该不能处理的中断请求发送给在位的可处理该中断请求的虚拟处理器，避免了当前虚拟处理器陷出，然后由宿主机中转该中断请求的时间，使得其他虚拟处理器可以尽快收到并处理该中断请求，进一步缩短了应用中断请求的处理时延。更多具体实现方法可参考第六方面及其实现方式。
结合第一方面或第一方面的第一种实现方式，在第二种实现方式下，所述虚拟计算机还用于当所述接收到的中断请求的处理主体为不包括所述虚拟计算机的当前虚拟处理器的其他虚拟处理器且经过判断确定所述其他虚拟处理器均不在位时，从所述其他虚拟处理器中确定目标虚拟处理器，在所述当前虚拟处理器和所述宿主机都可以访问的存储区域内记录所述接收到的中断请求的标识。当然这里记录标识的时候需要将该标识与该目标虚拟处理器建立关系，以便于指示这是目标虚拟处理器待处理的中断请求。
本申请中提到的A和B都可以访问的存储区域，具体可以是A和B都可以访问的共享内存，也可以是其他类型的可以被A和B访问的存储空间。
相应的，所述宿主机还用于在换入所述目标虚拟处理器之后根据所述存储区域内记录的标识向所述目标虚拟处理器发送中断请求，以便于所述目标虚拟处理器在陷入之后处理所述中断请求。具体的，处理主体中的任意一个虚拟处理器被宿主机换入之后且该虚拟处理器陷入之前，宿主机查看所述存储区域发现该虚拟处理器有未处理的中断请求，因此发送一个与接收到的中断请求具有相同特征的中断请求给该被换入的虚拟处理器(实际上是发送给该虚拟处理器调度到的物理处理器)，该被换入的虚拟处理器陷入之后接收并处理所述中断请求。
所谓相同特征的中断请求，可以是一个和最初接收到的那个中断请求标识相同的中断请求，也可以是一个携带了最初接收到的那个中断请求的标识的IPI中断。
这里的“目标虚拟处理器”可以是中断请求的所有处理主体，因此，可以理解的是，这里的确定目标虚拟处理器然后记录标识包括这样一种具体实现：即直接为中断请求的所有处理主体记录该中断请求的标识。
可见，虚拟计算机的当前虚拟处理器接收到一个中断请求，但却不是该中断请求的处理主体，同时可处理该中断请求的目标虚拟处理器又不在位，这种情况下，虚拟计算机通过在当前虚拟处理器和宿主机都可以访问的存储区域内记录下所述中断请求的标识，使得宿主机在换入该目标虚拟处理器后通过访问该存储区域能够发送一个相同的中断请求给该目标虚拟处理器处理，该目标虚拟处理器陷入之后就可以处理该中断请求，从而实现了当前虚拟处理器不陷出的前提下多个虚拟处理器之间的中断请求的共享，进一步缩短了中断请求的处理时延。
进一步的，对于仅需一个虚拟处理器处理就可以的中断请求，宿主机发送完一次中断请求之后可以将其他处理主体的相应记录清除掉，这样可避免该中断请求被多个虚拟处理器重复处理。
结合第一方面的第二种实现方式，在第三种实现方式下，所述宿主机还用于设置中断 请求的优先级，并将所述优先级记录在所述宿主机和所述虚拟计算机均可以访问的存储区域；所述虚拟计算机在从所述其他虚拟处理器中确定目标虚拟处理器方面具体用于：根据所述接收到的中断请求的优先级和虚拟处理器的优先级确定所述目标虚拟处理器，其中，所有虚拟处理器的状态和优先级存储在所有虚拟计算机均可以访问的存储区域。
虚拟处理器的优先级指的是虚拟处理器上当前任务的优先级。虚拟处理器不在位时，当前任务没有运行，在位时当前任务正在运行。
为了方便信息管理，中断请求的优先级可以和前述实现方式中提到的中断服务程序等信息存储在同一块存储区域；虚拟处理器的优先级则可以和前述实现方式中提到的虚拟处理器的状态存储在同一块存储区域。
通过引入中断优先级，然后将中断优先级于虚拟处理器上当前任务的优先级进行比较来选择一个合适的目标虚拟处理器，从而避免对虚拟处理器上的当前任务产生较大的影响。
结合第一方面的第三种实现方式，在第四种实现方式下，所述虚拟计算机根据所述接收到的中断请求的标识在所述宿主机和所述虚拟计算机均可以访问的所述存储区域内查找以获取所述接收到的中断请求的优先级，比较所述接收到的中断请求的优先级与在位的所有虚拟处理器的优先级；若所述所有在位的虚拟处理器的优先级均高于(或等于)所述接收到的中断请求的优先级，则确定所述接收到的中断请求的处理主体包括的所有虚拟处理器为所述目标虚拟处理器；若存在一个或多个在位的虚拟处理器的优先级低于所述接收到的中断请求的优先级，则确定所述接收到的中断请求的处理主体包括的所有虚拟处理器中优先级最高的虚拟处理器为所述目标虚拟处理器。
结合第一方面的第四种实现方式，在第五种实现方式下，若存在一个或多个在位的虚拟处理器的优先级低于所述接收到的中断请求的优先级，所述虚拟计算机还用于：确定所述在位的所有虚拟处理器中优先级最低的虚拟处理器为中转虚拟处理器，并发送IPI中断请求给所述中转虚拟处理器，所述IPI中断请求中携带所述目标虚拟处理器的标识，以便于所述中转虚拟处理器根据所述IPI中断请求陷出；所述宿主机还用于在所述中转虚拟处理器陷出之后换入所述目标虚拟处理器。更多具体实现方法可参考第六方面及其实现方式。
若当前虚拟处理器即为优先级最低的虚拟处理器，那么当前虚拟处理器将所述目标虚拟处理器的标识发送给宿主机，然后陷出。也就是说，不需要发送IPI中断请求，自己就是那个要被换出的“中转虚拟处理器”。
换句话说，若中断请求的优先级最低，那么记录下中断请求的标识即可，不需要主动触发目标虚拟处理器的换入；若存在在位的虚拟处理器的优先级比中断请求的优先级要低，则说明该中断请求可以优先于该虚拟处理器的当前任务处理，那么该虚拟处理器可以被换出。从这些可以被换出的虚拟处理器里确定一个优先级最低的作为中转处理器，在中断请求的处理主体中确定出一个优先级最高的作为目标虚拟处理器，然后将该目标虚拟处理器换入，将该中转虚拟处理器换出。这样尽量避免了对虚拟处理器当前任务的影响。这里的“最低”或“最高”也仅是本申请的一种实现方式，例如，如果系统允许也可以分别选择对应的第二名次的虚拟处理器。
结合第一方面的第二种实现方式，在第六种实现方式下，当所述接收到的中断请求的处理主体为不包括所述虚拟计算机的当前虚拟处理器的其他虚拟处理器且确定所述其他虚 拟处理器均不在位时，所述虚拟计算机还用于：将所述目标虚拟处理器的标识发送给宿主机并陷出，所述目标虚拟处理器为所述处理主体中的任意一个虚拟处理器或优先级最高的虚拟处理器；所述宿主机还用于：根据所述目标虚拟处理器的标识换入所述目标虚拟处理器并将所述虚拟计算机的所述当前虚拟处理器换出。
例如，有时中断请求本身很紧急或有优先级的情况下优先级很高，需要立刻被处理，所以不需要再确定中转虚拟处理器，直接将当前虚拟处理器换出，将任意一个处理主体或优先级最高的处理主体换入，以便尽快处理该中断请求。
在其他一些实现方式中，当采用主动换入目标虚拟处理器的方式时，也可以事先不记录中断请求的标识，而是在用于触发该目标虚拟处理器换入的事件或消息中携带中断请求的标识。例如，前述第五种实现方式的IPI中断请求中除所述目标虚拟处理器的标识之外还携带中断请求的标识，所述中转虚拟处理器陷出时将该中断请求的标识发送给宿主机，宿主机换入目标虚拟化处理器后根据该标识向目标虚拟处理器发送一个相同的中断请求。
结合第一方面的以上任意一种实现方式，在一些实现方式下，该虚拟化设备将虚拟处理器在位还是不在位的状态信息存储在所有虚拟处理器(亦即所有虚拟机)均可以访问的存储区域内，具体可以通过一个或多个表来记录。为了方便描述，该记录在本申请的一些实施例称之为“运行实体表”，但本申请对该表名称不做限定。同样的，下述实现方式中将会出现的“中断向量表”或“中断映射表”也是如此。
结合第一方面的以上任意一种实现方式，在一些实现方式下，虚拟处理器的调度是由宿主机执行，具体可以是宿主机中的虚拟机监控装置执行的，所以运行实体表的更新由宿主机来执行，这就意味运行实体表的存储区域宿主机也能访问。具体的，当宿主机换入一个虚拟处理器之后且虚拟处理器陷入之前将该虚拟处理器在运行实体表的相应状态更新为在位，然后虚拟处理器陷入。一个虚拟处理器陷出但宿主机换出该虚拟处理器之前将该虚拟处理器在运行实体表的相应状态更新为不在位，然后宿主机换出该虚拟处理器。
通过所有虚拟处理器和宿主机均可访问的运行实体表，能够及时获取虚拟处理器的最新状态。若中断请求的处理主体在位，当前虚拟处理器可以在不陷出的情况下直接发送该中断请求给该在位的虚拟处理器；若中断请求的处理主体均不在位，当前虚拟处理器也可以在不陷出的情况下在运行实体表内记录下该中断请求或进一步触发目标虚拟处理器的陷入等，这样目标虚拟处理器陷入之后就可以处理该中断请求，避免虚拟处理器陷入陷出造成的时延，提高了中断请求的处理效率。
结合第一方面或第一方面的以上任意一种实现方式，在第七种实现方式下，为了尽量避免出现收到中断请求的虚拟处理器并不是该中断请求的处理主体，以期进一步降低中断处理的时延，需要修改一下中断控制器的中断亲缘性，中断亲缘性是中断控制器的一个属性。该中断亲缘性包含中断请求的标识和物理处理器的标识(本申请可简称为处理器)的对应关系。中断控制器是一个硬件，用于接收其他硬件产生的中断请求并根据中断亲缘性发送中断请求给对应的物理处理器。相应的，所述宿主机还用于配置所述中断控制器中的中断亲缘性，使得一个中断请求能够被发送到该中断请求的处理主体包括的虚拟处理器上。由于虚拟处理器运行在物理处理器上，所以要保证中断请求被发送的对的虚拟处理器上，实际上就是保证中断请求被发送到该对的虚拟处理器所运行的物理处理器上。
结合第一方面的第七种实现方式，在第八种实现方式下，所述宿主机在换入一个虚拟处理器之后且该虚拟处理器陷入之前，将将要运行所述被换入的虚拟处理器的物理处理器与处理主体包括该被换入的虚拟处理器的所有中断请求在所述中断亲缘性中建立对应关系，之后该虚拟处理器就陷入运行。
这样，中断控制器就能够根据该修改后的中断亲缘性将中断请求发送给该虚拟处理器所运行的物理处理器，亦即发送给该虚拟处理器，而该中断请求的处理主体正好包括该虚拟处理器，那该虚拟处理器就可以直接处理该中断请求，有效避免了中断请求在虚拟处理器之间的分发。
相应的，宿主机在换出一个虚拟处理器之前，(除了更新运行实体表之外)从中断亲缘性中删除该将要被换出的虚拟处理器与处理主体包括该虚拟处理器的所有中断请求之间的对应关系。
配置中断控制器的中断亲缘性之后，中断请求会被最大可能地发送给能够处理该中断请求且当前在位的虚拟处理器，极大地避免了虚拟处理器之间的中断请求分发，进一步提高了中断请求的处理效率。
结合第一方面的第七或第八种实现方式，在第九种实现方式下，即便配置了中断亲缘性，一个虚拟处理器还是有可能收到自己不可处理的中断请求，这个时候，由于配置了中断亲缘性，那么可以确定该中断请求的处理主体所包括的所有虚拟处理器均不在位，所以此时不需要判断中断请求的处理主体是否在位。其他的实现方式可参考前述第二种、第三种、第四种、第五种或第六种实现方式，相应的效果也可参考。例如，从中断请求的处理主体中确定待处理该中断请求的目标虚拟处理器(可以包括全部处理主体)，然后针对该目标虚拟处理器仅记录下中断请求的标识；进一步的，还可以根据中断请求的优先级合理选择目标虚拟处理器；更进一步的，还可以主动触发该目标虚拟处理器的换入，使得该中断请求尽快被处理。
结合第一方面或第一方面的以上任意一种实现方式，在一些实现方式下，所述虚拟计算机还用于当所述接收到的中断请求的处理主体为所述宿主机时，所述虚拟计算机将所述接收到的中断请求注入所述宿主机；所述宿主机还用于接收并处理所述虚拟计算机注入的所述中断请求。
结合第一方面或第一方面的以上任意一种实现方式，在一些实现方式下，所述虚拟计算机具体用于根据中断向量表和所述接收到的中断请求的标识确定所述中断请求的处理主体和所述中断请求对应的中断服务程序，所述中断向量表中包含中断请求的标识、所述中断请求的处理主体以及所述中断请求的中断服务程序之间的对应关系，所述中断向量表存储在所述虚拟计算机和所述宿主机均可以访问的存储区域内；所述宿主机还用于(在所述虚拟计算机的触发下)修改所述中断向量表以增加中断请求的标识、所述中断请求的处理主体和中断服务程序的对应关系。
通过跨层共享(即虚拟处理器和宿主机可以共享)的中断向量表存储中断请求、中断请求的处理主体以及中断服务程序之间的对应关系等信息，能够使得一个虚拟处理器在需要这些信息处理中断请求时直接访问存储区域即可，不需要陷出，避免了因陷出带来的中断时延。这些信息这样存储可节省存储空间，进一步的，可以由宿主机修改这些信息，这 样设计更加合理和安全。
第二方面，本申请提供一种中断请求的处理方法，该方法应用于虚拟化设备，虚拟化设备中包括处理器以及宿主模式和客户模式两种不同的运行模式。
处理器在宿主模式时配置寄存器以使所述处理器在运行有虚拟处理器且所述虚拟处理器运行于客户模式时能够从所述虚拟化设备的其他硬件接收中断请求；
所述处理器在客户模式时执行如下操作：所述处理器从所述其他硬件接收中断请求，所述处理器根据所述中断请求确定所述接收到的中断请求的处理主体；当所述接收到的中断请求的处理主体包括所述处理器上当前运行的虚拟处理器时，所述处理器根据所述中断请求确定与所述接收到的中断请求对应的中断服务程序，并调用所述中断服务程序以处理所述中断请求。具体的，接收到的中断请求中可以携带所述中断请求的标识，例如IRQ ID，后续根据标识确定处理主体和中断服务程序。
进一步的，虚拟计算机根据一些信息和所述中断请求确定所述中断请求的处理主体和中断服务程序。这些信息包括中断请求(标识)、处理主体以及中断服务程序的对应关系。
这里的“处理器”可以理解为一个最小的物理处理单元，比如物理核。
结合第二方面，在第一种实现方式下，所述处理器在宿主模式时配置所述将在所述处理器上运行的虚拟处理器能够操作所述虚拟化设备的物理的中断控制器；
所述处理器在客户模式时还执行如下操作：当所述接收到的中断请求的处理主体为不包括所述处理器上当前运行的所述虚拟处理器的其他虚拟处理器且确定所述其他虚拟处理器中至少有一个在位时，操作所述物理的中断控制器向所述其他虚拟处理器中在位的一个或多个虚拟处理器发送IPI中断请求，所述IPI中断请求中携带所述接收到的中断请求的标识。
结合第二方面，在第二种实现方式下，所述处理器在宿主模式时配置所述虚拟化设备的中断控制器的中断亲缘性，使得一个中断请求能够被发送到该中断请求的处理主体所包括的虚拟处理器上，所述中断亲缘性包含中断请求的标识和处理器的标识的对应关系。相应的，所述处理器接收所述中断控制器根据所述中断亲缘性向所述处理器发送的所述中断请求。
结合第二方面的第二种实现方式，在第三种实现方式下,所述处理器在宿主模式换入一个虚拟处理器之后将所述处理器与处理主体包括所述换入的虚拟处理器的所有中断请求在所述中断亲缘性中建立对应关系。相应的，所述处理器在宿主模式换出一个虚拟处理器之前，从中断亲缘性中删除该将要被换出的虚拟处理器与处理主体包括该虚拟处理器的所有中断请求之间的对应关系。
结合第二方面的第二种或第三种实现方式，在第四种实现方式下，当所述接收到的中断请求的处理主体为不包括所述处理器上当前运行的所述虚拟处理器的其他虚拟处理器时，所述处理器在客户模式从所述其他虚拟处理器中确定目标虚拟处理器，并在所述处理器在客户模式和和宿主模式都可以访问的存储区域内记录所述中断请求的标识；所述处理器在宿主模式在换入所述目标虚拟处理器之后根据所述存储区域内记录的标识向所述目标虚拟处理器发送中断请求，以便于所述目标虚拟处理器陷入之后处理所述中断请求。
具体的，所述处理器在宿主模式在换入所述目标虚拟处理器且所述目标虚拟处理器没有陷入之前，关闭该宿主模式的中断响应，然后根据所述存储区域内记录的标识向自己发送一个相同特征的中断请求(因为目标虚拟化处理器当前被调度到的处理器就是自己)。目标虚拟处理器陷入之后(也就是该处理器在客户模式)就可以接收和处理该中断请求了。
结合第二方面的第四种实现方式，在第五种实现方式下，所述处理器在宿主模式时设置所述中断请求的优先级，并将所述优先级记录在所述处理器在宿主模式和客户模式均可以访问的存储区域；所述处理器在客户模式根据所述接收到的中断请求的优先级和虚拟处理器的优先级确定所述目标虚拟处理器，其中，所述虚拟处理器的优先级存储在所有虚拟处理器均可以访问的存储区域。
结合第二方面的第四种实现方式，在第六种实现方式下，当所述接收到的中断请求的处理主体为不包括所述处理器上当前运行的所述虚拟处理器的其他虚拟处理器时，所述方法还包括：所述处理器在客户模式时将所述目标虚拟处理器的标识反向注入(到宿主机或宿主模式)，之后所述处理器离开客户模式进入宿主模式，其中所述目标虚拟处理器为所述其他虚拟处理器中的任意一个虚拟处理器或优先级最高的虚拟处理器；所述处理器在宿主模式根据所述目标虚拟处理器的标识换入所述目标虚拟处理器并将所述处理器上的当前虚拟处理器换出。
第二方面提供的方法应用于虚拟化设备中，该虚拟化设备包括硬件层、运行在硬件层上的宿主机和运行在宿主机上的虚拟计算机，所述虚拟计算机内包含有服务于该虚拟计算机的虚拟处理器，一个虚拟处理器可以在一个所述处理器上运行。处理器在客户模式下执行的动作可以理解为虚拟处理器(在客户模式下)执行动作，进而也可以理解为该虚拟处理器服务的虚拟计算机执行动作；处理器在宿主模式下执行动作可以理解为宿主机执行动作。
更多第二方面的实现方式可参考前述第一方面。
第三方面，本申请提供一种中断请求的处理装置，该处理装置应用于虚拟化设备中，所述虚拟化设备包括硬件层、宿主机和虚拟计算机；所述处理装置包括部署在所述宿主机内的宿主机中断管理单元和部署在所述虚拟计算机内的客户中断管理单元；
所述宿主机中断管理单元用于配置所述虚拟计算机的虚拟处理器能够从所述硬件层接收中断请求；
所述客户中断管理单元用于从所述硬件层接收中断请求，所述接收到的中断请求中携带所述中断请求的标识；根据所述标识确定所述接收到的中断请求的处理主体；当所述接收到的中断请求的处理主体包括所述虚拟计算机的当前虚拟处理器时，所述虚拟计算机根据所述标识确定与所述接收到的中断请求对应的中断服务程序，并调用所述中断服务程序以处理所述中断请求。
更多具体实现可参考前述第一方面或第二方面。
第四方面，本申请提供一种虚拟化设备，该虚拟化设备包括处理器和存储器，所述存储器用于存储计算机可读指令，所述处理器用于读取所述计算机可读指令并实现前述提供的任意一种方法。
第五方面，本申请提供一种计算机存储介质，其特征在于，用于存储计算机可读指令， 当所述计算机可读指令被处理器读取时促使所述处理器实现前述提供的任意一种方法。另外，还提供一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品中包含计算机可读指令，当该计算机可读指令被处理器读取时促使所述处理器实现前述方面提供的任意一种方法。
第六方面，本申请提供一种处理器间中断(IPI)的处理方法。该方法可以应用于前述方面或任意实现方式提供的方法或装置中。
宿主机配置源虚拟处理器的中断控制器操作模式，使得所述源虚拟处理器可以在不陷出的前提下操作中断控制器向所述目的虚拟处理器所运行的所述物理处理器发送所述IPI中断请求。源虚拟处理器根据信息确定目的虚拟处理器所运行的物理处理器，其中所述信息记录在所述源虚拟处理器可以访问的存储区域内，所述信息中包括指示所述目的虚拟处理器所运行的物理处理器的信息；然后所述源虚拟处理器操作所述中断控制器向所述目的虚拟处理器所运行的所述物理处理器发送IPI中断请求。
这样，通过中断控制器操作模式的配置和可直接访问的信息，源虚拟化处理器可以在不陷出的情况下发送IPI中断请求给目的虚拟化处理器。
结合第六方面，在第一种实现方式下，源虚拟处理器向所述目的虚拟处理器发送IPI中断请求，所述IPI中断请求中携带其他中断请求的标识或者所述IPI中断请求中携带其他中断请求的标识和虚拟处理器的标识；所述目的虚拟处理器确定所述IPI中断请求中没有携带虚拟处理器的标识或确定所述IPI中断请求中携带的所述虚拟处理器的标识与所述目的虚拟处理器的标识一致，则调用所述其他中断请求的标识对应的中断服务程序，以处理所述其他中断请求。
这样，通过虚拟处理器之间发送IPI中断请求，就可以实现普通中断请求在虚拟处理器之间的分发，这些虚拟处理器可以是同一个虚拟计算机内的，也可以是不同的虚拟计算机内的。
结合第六方面或第六方面的第一种实现方式，在第二种实现方式下，所述IPI中断请求中携带虚拟处理器的标识(其他中断请求的标识可以不携带)时，该方法还包括：所述目的虚拟处理器确定所述IPI中断请求中携带的所述虚拟处理器的标识与所述目的虚拟处理器的标识不一致，则向宿主机发送所述虚拟处理器的标识并陷出，以便于所述宿主机将所述虚拟处理器的标识所指示的虚拟处理器换入。
这样，通过虚拟处理器之间发送IPI中断请求，就可以实现宿主机对目标虚拟处理器的换入，以便于目标虚拟处理器尽快处理IPI中断请求中携带的那个中断请求。
结合第六方面或第六方面的任意一种实现方式，在第三种实现方式下，所述源虚拟处理器在确定所述目的虚拟处理器在位时才发送所述IPI中断请求。具体的，所述源虚拟处理器查询所述信息以确定所述目的虚拟处理器是否在位，所述信息中还包括指示所述目的虚拟处理器是否在位的信息。具体的，所述信息可以记录在虚拟处理器和宿主机均可以访问的存储区域内，所述宿主机用于在换入和换出虚拟处理器时修改所述信息。
第七方面，本申请还提供一种对应第六方面的IPI中断处理装置，包括一个或多个模块用以实现第六方面或其任意一种实现方式提供的方法。另外，还提供一种虚拟化设备，该虚拟化设备中的虚拟处理器被配置为实现如第六方面或其任意一种实现方式所描述的方 法。另外，还提供一种计算机存储介质、一种计算机程序以及计算机程序产品，具体参考前述方面。
第八方面，本申请还提供一种中断处理的方法，用于处理需要多个虚拟处理器处理的中断请求，例如时钟中断等。该方法包括：宿主机为每个物理处理器创建对应的信息，该信息中包含上一次在该物理处理器运行的虚拟处理器的信息。虚拟处理器接收到一个中断请求并确定该中断请求需要多个虚拟处理器处理，然后确定所述信息集合中的虚拟处理器包含在所述中断请求的处理主体中，之后在所述宿主机和所述虚拟处理器均可以访问的区域中与所述虚拟处理器对应的位置记录所述中断请求，以便于触发所述虚拟处理器的换入，使得所述虚拟处理器可以尽快处理该中断请求。更多处理方法可参考前述方面及其实施例。另外还提供与该方面相应的装置以及可读存储介质。通过这样的方法，类似时钟中断这样的中断请求的时延也得到有效降低。
第九方面，本申请还提供一种中断处理的方法，宿主机接收到应用中断请求，并通过访问信息确定能够处理该中断请求的虚拟处理器是否在位，若存在任意一个在位，则通过IPI中断将该中断请求发送给该在位的虚拟处理器；若均不在位，则在所述宿主机和所述虚拟处理器均可以访问的区域中记录该中断请求。是否主动触发换入，如何换入，可参考前述方面及其具体实施例。另外还提供与该方面相应的装置以及可读存储介质。通过这样的方法，使得本申请可应用在宿主机不能关闭中断响应的场景下，应用范围更广。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例应用的网络架构示意图；
图2为本发明实施例提供的虚拟化网络设备的硬件结构示意图；
图3A为本发明实施例提供的一种虚拟化网络设备的配置示意图；
图3B为本发明实施例提供的另一种虚拟化网络设备的配置示意图；
图4为本发明实施例提供的中断处理方法的流程示意图；
图5为本发明实施例提供的虚拟化网络设备中各个功能单元模块的示例图一；
图6为本发明实施例提供的宿主机中断管理单元初始化的流程示意图；
图7为本发明实施例提供的客户中断管理单元初始化的流程示意图；
图8A和图8B为本发明实施例提供的中断处理方法的流程示意图；
图9A和图9B为本发明实施例提供的中断亲缘性配置的流程示意图；
图10为本发明实施例提供的虚拟化网络设备中各个功能单元模块的示例图二；
图11为本发明实施例提供的复制中断的处理方法的流程示意图；
图12为本发明实施例提供的虚拟化网络设备中各个功能单元模块的示例图三。
具体实施方式
为了方便理解本发明实施例，首先在此介绍本发明实施例描述中会引入的几个要素。
虚拟计算机：所有类型的虚拟化设备中软件虚拟出来的运行环境的统称。该概念包括虚拟机、容器、以及轻量级虚拟化libOS等。
虚拟机(virtual machine,VM)：通过软件在一台物理计算机上模拟出的一台或者多台虚拟计算机。这些虚拟机运行在完全隔离的环境中，就像真正的计算机那样进行工作。虚拟机上可以安装客户操作系统(guest operating system,guest OS)，客户操作系统上运行有一个或多个应用。虚拟机还可访问网络资源。对于在虚拟机中运行的应用而言，就像是在真正的计算机中工作。
宿主机(host)层：作为管理层，用以完成硬件资源的管理、分配；为虚拟机呈现虚拟硬件平台；实现虚拟机的调度和隔离等。在一些实现方式下，宿主机层包括宿主机操作系统和虚拟监控装置，例如虚拟机监视器(virtual machine monitor,VMM)或hypervisor，其中虚拟监控装置可部署在宿主机操作系统之内，也可以部署在宿主机操作系统之外。在另一些实现方式下，“宿主机层”还可以包括1个特权虚拟机(例如虚拟化架构Xen)。其中，虚拟硬件平台对其上运行的各个虚拟计算机提供各种硬件资源，如虚拟处理器、虚拟内存、虚拟磁盘、虚拟网卡等。虚拟计算机则运行在宿主机层为其准备的虚拟硬件平台上。本申请中有时将宿主机层简称为宿主机。
硬件层：虚拟化环境运行的硬件平台。其中，硬件层可包括多种硬件，例如某物理计算机的硬件层可包括处理器和存储器，还可以包括中断控制器、网卡(network interface card，NIC)、输入/输出(input/output I/O)设备等。
中断请求(interrupt request)、中断号：中断请求指的是硬件产生的一种事件，硬件将该事件发送到处理器，当处理器接收到该事件时，暂时停止当前程序的执行转而执行该事件对应的程序。硬件产生中断请求可能是硬件自己触发的，也可能是软件触发硬件产生的。中断请求有时也简称为中断。计算机中的某些硬件(例如网卡、声卡、鼠标、硬盘等)能在没有处理器介入的情况下完成一定的工作，但是这些硬件还是需要定期中断处理器，让处理器为其做一些特定的工作。中断号为一个中断请求的标识，本申请中用英文IRQ ID表示。
中断控制器：设置在触发中断请求的硬件和处理器之间，主要用于收集各个硬件产生的中断请求，并按照一定的优先级或其他规则发送给处理器。例如高级可编程中断控制器(advanced programmable interrupt controller,APIC)。本申请中断控制器是一个总称，其中可能包含不同的功能部件，例如X86系统中中断控制器包括一个io-APIC和多个local-APIC，进一步的还可以包括若干个其他中断控制部件；一个local-APIC对应一个物理核。
中断亲缘性：指的是中断请求与处理该中断请求的处理主体(通常是物理处理主体，例如物理核)的对应关系。中断控制器可根据该中断亲缘性将一个中断请求发送到该中断请求对应的一个或多个物理处理主体上。
中断服务程序(interrupt service routine,ISR)：用于处理中断请求的程序。当处理器接收到中断请求时，暂时停止当前程序的执行转而执行该中断请求对应的中断服务程序。
应用中断请求：该应用指的是部署在虚拟机内的应用(或称业务软件)，虚拟机内的应用会将自己的中断服务程序部署到它所运行的客户操作系统内，如果一个中断请求的中断服 务程序位于客户操作系统内部且是某个应用部署的(即需要该应用处理)，则该中断请求称之为应用中断请求。在大多数虚拟化网络设备中，虚拟机中部署的应用通常是用来完成各种实际的业务需求的，所以应用中断请求有时也可以称之为业务中断请求。
客户操作系统中断请求：这种中断请求对应的中断服务程序是虚拟机内的客户操作系统提供的，而非虚拟机内的应用部署的。与应用中断请求一样，这种中断请求的中断服务程序也部署在虚拟机的客户操作系统内。
libOS(library operating system)：轻量级虚拟化技术提供的一种操作系统，libOS是一种运行库，能够提供类操作系统的功能且与应用链接在一起运行，从而使得应用运行所必须的全部的资源由应用自身而不是操作系统管理。比如unikernel、OSv、dune等。libOS可以认为是一种轻量级的虚拟计算机。
物理处理器：有时简称为“处理器”，在本申请中指物理的处理单元，具体可以是一个最小处理单元，即本申请中的物理核，在某些实施例中也可以指包含多个物理核的处理单元。
虚拟处理器：在虚拟化技术下，以共享或者分片方式提供给虚拟计算机使用的物理处理单元的表示，例如虚拟CPU(virtual central processing unit,vCPU)。一台虚拟计算机可以有一个或多个虚拟处理器为其服务，当存在多个虚拟处理器时，通常有一个虚拟处理器为主虚拟处理器,其他为从虚拟处理器。
应理解，虚拟计算机相当于一台独立的计算机，所以虚拟计算机执行动作也可以认为是虚拟处理器执行该动作，而虚拟处理器是软件实现的，所以虚拟处理器执行动作实际上是虚拟处理器所运行的物理处理器或物理核执行该动作。在本发明的多个实施例中，为遵循当下场景的技术表达习惯，会有选择地使用以上表述方式。
虚拟处理器陷入和虚拟处理器陷出：虚拟化系统包括两种模式：宿主模式(host mode)与客户模式(guest mode)。当一个虚拟处理器进入客户模式，叫做陷入(虚拟)；当该虚拟处理器离开客户模式，叫陷出(虚拟)。虚拟处理器陷出后物理处理器将暂时不执行该虚拟处理器的代码，所以此时可以理解为虚拟处理器没有运行。在本申请的多数实施例中以vCPU这种虚拟处理器为例介绍方法或装置，所以这些实施例中具体为vCPU陷入或陷出。针对一个物理处理器而言，其上运行的虚拟处理器陷入，则可以认为该物理处理器处于客户模式，运行虚拟处理器的代码，当其上运行的虚拟处理器陷出到宿主模式，则可以认为该物理处理器处于宿主模式，运行宿主机相关的代码，比如VMM。
虚拟处理器在位或不在位：虚拟处理器陷入之后的状态称之为在位，没有陷入的状态称之为不在位。一个虚拟处理器在位可以理解为该虚拟处理器正在运行，即存在一个物理处理器执行了该虚拟处理器的代码；一个虚拟处理器不在位即没有物理处理器执行该虚拟处理器的代码。在本申请的多数实施例中以vCPU这种虚拟处理器为例介绍方法或装置，所以这些实施例中具体为vCPU在位或不在位。
IPI：inter-processor interrupt，即处理器间的中断，是一种特别的中断，是一个处理器发送给另一个处理器的中断请求。例如，APIC的中断命令寄存器(interrupt command register,ICR)，该ICR就允许处理器上运行的软件向其他处理器发送IPI中断。有些IPI是由客户操作系统触发的，用来实现系统维护，可以视作客户操作系统中断请求；有些则是由业务 触发的，所以可以视作应用中断请求。本申请在不同的场景下让IPI中断携带不同的参数，并新增相应的中断服务程序，从而在一些实施例中实现技术效果。
另外，在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。本申请中的术语“和/或”或字符“/”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，或A/B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚地描述。
图1示意性地示出了网络系统的一个实施例。该网络系统包括用户设备、演进型基站(eNodeB)100、移动性管理实体(mobility management entity,MME)以及服务网关等网络设备。该网络系统还可以是符合5G通信标准的网络系统。用户设备包括手机、台式计算机、笔记本、车载设备等。该网络系统另外还可以包括用户归属服务器、PDN网关等其他网络设备，在此不一一列举。
图2为以上实施例中eNodeB 100的硬件结构示意图，具体可以认为是演进型基站的业务处理板的硬件结构示意图。该eNodeB 100包括处理器110、存储器120以及网络接口130(也被称为网卡或网络适配器等)等组件。其中，处理器110可以为单核处理器，也可以为多核处理器。当处理器110为多核处理器时，本申请提供的方法可以运行在一个核上，也可以分布运行在不同的核上。处理器110可以为一个，也可以为多个，多个处理器的类型可以相同或不相同。处理器的类型有中央处理器(central processing unit,CPU)、图形处理器、微处理器或协处理器等。网络接口130用于连接其他网络设备，包括无线连接和有线连接。存储器120包括易失性和非易失性存储器，通常非易失性存储器上存储有虚拟化软件程序122、本申请提供的中断请求处理方法的软件121以及其他程序模块123。虚拟化软件程序122被处理器110读取和运行之后实现eNodeB 100的虚拟化，包括创建宿主机层以及多个虚拟计算机等；本申请提供的中断处理软件程序121在被处理器110读取和运行之后实现本申请各个实施例提供的各种中断请求处理方法。本申请提供的软件程序121可以结合在虚拟化软件程序122中。
以上组件通过总线140连接。总线140可以是一条，也可以是多条。总线140包括高级微控制器总线(advance microcontroller bus architecture,AMBA)工业标准结构(industry standard architecture,ISA)总线，微通道结构(micro channel architecture,MCA)总线，扩展ISA(extended-ISA)总线，视频电子标准协会(video electronics standards association,VESA)局域总线，以及外围器件互联(peripheral component interconnect,PCI)总线等。
图3A示出了以上实施例中eNodeB 100虚拟化之后的一种配置的示意图。该虚拟化设备100包括硬件层、宿主机层和虚拟化层，虚拟化层包含两台虚拟机。硬件层包括两个处理器110、存储器120、网络接口130、中断控制器160等硬件。在其他实施例中，处理器110的个数和虚拟机的个数还可以更多或更少。
在其他一些实施例中，虚拟机内可以包含容器(container)，容器相当于应用。在其他一些实施例中，参考图3B,虚拟化层由轻量级虚拟化技术实现，例如libOS190。一个libOS 内通常包含一个应用，整个libOS是一个或多个库，和该应用链接成一个单地址空间镜像。libOS190内部包含有本申请提出的客户中断管理单元191。本申请实施例通常以传统虚拟化技术实现的虚拟机为例，其他类型的虚拟化架构可参考虚拟机的实现。
需要说明的是，本实施例以该eNodeB 110为例，但本申请提供的方法并不局限于该设备，所有类型的虚拟化设备均可以应用。
中断控制器160负责收集网络接口130等硬件设备产生的中断请求，并根据一定的规则将这些中断请求发送给各个处理器110。处理器110可以包括一个或多个物理核(本申请中有时将物理核简称为核)。
“物理核”在本申请中代表最小处理单元。如图3A或图3B所示，本实施例中每个处理器具有两个物理核：核0和核1，以及多个寄存器。在其他一些实施例中，处理器包含的核的数量可以更多或更少，各个处理器包含的核的个数也可以不同。
宿主机内部署有宿主机操作系统170和VMM180，VMM180在其他虚拟化架构中相当于hypervisor或其他类型的虚拟监控装置。VMM180可以部署在宿主机操作系统170内部，也可以和宿主机操作系统170分开部署。VMM180负责管理在其上运行的一台或多台虚拟机。
虚拟机(VM)包括虚拟硬件层、客户操作系统190以及多种应用。虚拟硬件层包含虚拟存储器(未在图中示出)、虚拟处理器110-v等虚拟硬件。如图3A或图3B所示，本实施例包含两个虚拟机，每个虚拟机包含三个虚拟处理器110-v。虚拟处理器110-v是软硬件结合实现的，它的运行实际是物理核读取并运行软件程序实现的，例如一个物理核读取软件程序并在该物理核的硬件辅助虚拟化的特定模式(例如x86的non-Root模式)下运行该软件程序以实现一个虚拟处理器110-v。也因此，虚拟处理器110-v需要被调度到某一个物理核上。
虚拟处理器110-v和物理核可以是绑定的关系，即一个虚拟处理器110-v固定在某个物理核上运行，不能被调度到其他物理核上运行，则该虚拟处理器为绑核；一个虚拟处理器110-v可以根据需要被调度到不同的物理核上运行，则该虚拟处理器为非绑核。
在本实施例中，虚拟处理器110-v的总个数为6，大于物理核的数量4，这种场景称之为物理处理器超分配。在物理处理器超分配的情况下，会存在多个虚拟处理器以时间分片方式或其他方式共享同一个物理核的情况，这种物理核叫做非独占核。当然非超分配的情况下也可能出现非独占核。一个物理核与一个虚拟处理器绑核且不被其他虚拟处理器共享，则该物理核是独占核。
VMM180作为虚拟监控装置，负责调度各个VM的虚拟处理器110-v。例如，基于内核的虚拟机(kernel-based virtual machine,KVM)就是一种典型的VMM。VMM180对虚拟处理器110-v的调度包括换入虚拟处理器和换出虚拟处理器。首先，VMM180创建并初始化一个VM的对象，然后为该VM创建三个虚拟处理器110-v。当一个VM包含多个虚拟处理器110-v时，一般会有一个为主虚拟处理器，其他为从属虚拟处理器。虚拟处理器110-v被创建之初还没有与某个物理核关联。VMM180会依据策略将某个虚拟处理器110-v调度到某个物理核上，这称为该虚拟处理器被换入；VMM180将该虚拟处理器110-v挂起或从该物理核上迁移出去，称为该虚拟出处理器被换出。在绑核的场景下，一个虚拟处理器每 次被换入时都被调度到相同的核上。在非绑核的场景下，VMM180可以在调度之前根据系统当前的运行状况和/或调度算法确定将该虚拟处理器110-v调度到哪个核上。
需要说明的是，一个虚拟处理器110-v被换入之后可以不立即陷入运行，在虚拟处理器110-v被换入且还没有陷入之前，宿主机(具体为VMM)还可以实现一些对该虚拟处理器110-v的配置，然后该虚拟处理器110-v再陷入客户模式。
基于图3A或图3B的配置，现有的中断请求处理方案通常是基于系统中断优先的原则进行设计的，将硬件产生的中断请求全部直通到宿主机层，因此宿主机层的中断请求处理过程较快。但是，在这种方案下，应用中断请求需要宿主机识别然后再发送到虚拟机，因此整个处理过程涉及宿主机和虚拟机(也可以认为是虚拟处理器)两种处理主体，因而涉及虚拟处理器的陷入和陷出，所以处理过程变长，延时增大，这明显无法满足业务处理超低时延的要求。因此，本申请提出一种有效降低应用中断请求处理时延的方法，且在该方法的基础上逐步扩展了更多的功能。
为解决上述应用中断请求处理时延长的问题，本实施例提供的设备100中包括宿主机中断管理单元181和客户中断管理单元191。这两个单元可以认为是图2中断处理软件程序121的两个功能模块。
宿主机中断管理单元181部署在宿主机层。当VMM180部署在宿主机操作系统170之上时，宿主机中断管理单元181可以部署在宿主机操作系统170内，也可以部署在VMM180内，也可以部分部署在宿主机操作系统170内，部分部署在VMM180内。当VMM180部署在宿主机操作系统170内部时，宿主机中断管理单元181可以部署在VMM180内，也可以部署在除VMM180之外的宿主机操作系统170内部，也可以部分部署在VMM180内，部分部署在除VMM180之外的宿主机操作系统170内部。
客户中断管理单元191可以部署在每个虚拟机的客户操作系统190内部。当虚拟化计算机设备的虚拟层为libOS时，客户中断管理单元191可以部署在libOS的运行库中。客户中断管理单元191被配置为可以直接从硬件层接收中断请求。
客户中断管理单元191用于从中断控制器160或其他中断收集装置直接接收中断请求，并确定该中断请求的处理主体。若中断请求的处理主体为当前虚拟机的当前虚拟处理器，则直接调用中断服务程序。进一步的，若中断请求的处理主体为宿主机，则将该中断请求发送给宿主机。更进一步的，若中断请求的处理主体不为当前的虚拟处理器而为其它虚拟处理器，则将该中断请求调配到其它虚拟处理器处理。若其他虚拟处理器在位，那可以通过发送IPI的方式进行中断请求的调配，若其他虚拟处理器不在位，那可以将该中断请求记录下来以便于其他虚拟处理器在位之后再处理绍。需要说明的是，“当前虚拟机”为该客户中断管理单元191所属的虚拟机，“当前虚拟处理器”为当前读取并运行该客户中断管理单元191的虚拟处理器。
宿主机中断管理单元181用于配置虚拟处理器110-v的中断接收模式，使得虚拟处理器110-v可以在客户模式下从硬件层接收中断请求。在一些实现方式下，宿主机中断管理单元181还用于配置虚拟处理器110-v操作中断控制器160的模式，使得虚拟处理器110-v能够在客户模式下直接操作物理的中断控制器160(一般是该虚拟处理器所运行物理核的本地中断控制器)。进一步的，宿主机中断管理单元181还用于管理处理中断请求所需的信 息(可参考下述实施例中的表1和表2)，包括应用注册中断请求时提供的信息，并将这些信息存储到虚拟机和宿主机可以共享的存储区域中，以便虚拟机和宿主机可以访问/修改该信息。更进一步的，宿主机中断管理单元181还用于接收从虚拟机发送过来的中断请求，并将该中断请求发送给宿主机中现有的中断处理模块，由该模块调用部署在宿主机中的中断服务程序，从而处理该中断请求。
参考图4，从虚拟处理器110-v的角度，客户中断管理单元191执行的动作可以认为是当前虚拟机的当前虚拟处理器在客户模式(亦即陷入状态)下执行的动作。
具体的，虚拟处理器110-v首先确定接收到的中断请求的处理主体(S401)。若确定该中断请求的处理主体为自己，则该虚拟处理器110-v处理该中断请求(S402)；若确定该中断请求的处理主体为宿主机，则该虚拟处理器110-v将该中断请求发送到宿主机(S403)；若确定该中断请求的处理主体为其它虚拟处理器，则该虚拟处理器110-v将该中断请求记录所有虚拟处理器均可以共享的存储区域或将该中断请求发送给其他虚拟处理器，例如通过IPI的方式(S404)，以便于其它虚拟处理器访问该存储区域并处理该中断请求或收到该IPI后处理该中断请求。如果宿主机中断管理单元181配置该虚拟处理器110-v使得该虚拟处理器110-v能够在客户模式下直接操作物理的中断控制器160，那么该虚拟处理器110-v可以在客户模式下直接操作中断控制器160发送一个IPI给其他虚拟处理器，该IPI中携带该未被处理的中断请求的信息。
进一步的，步骤S404的实现方式如下：若确定该中断请求的处理主体为其它虚拟处理器，在一些实现方式下，该虚拟处理器仅在所有虚拟处理器均可以共享的存储区域内记录该中断请求，该中断请求的处理主体根据自己的运行情况适时访问该存储区域并处理该中断请求；在另一些实现方式下，该虚拟处理器可以先判断该处理主体在不在位，若该处理主体在位，则通过发送IPI的方式把该中断请求发送给该在位的处理主体，以便于它尽快处理该中断请求；若该处理主体不在位，该虚拟处理器不仅在所有虚拟处理器均可以共享的存储区域内记录该中断请求，还可以确定一个中转虚拟处理器(可能是自己)，并向该中转虚拟处理器发送一个IPI中断，该中转虚拟处理器收到该IPI中断后陷出到宿主机，然后宿主机将该处理主体换入，换入之后处理该中断请求。如果中转虚拟处理器是自己，那自己向宿主机发送该处理主体的标识并陷出，以便于宿主机将该处理主体换入。
对于步骤S404还有另一些实现方式：按照本申请提出的方法配置了中断控制器的中端亲缘性属性之后，若确定该中断请求的处理主体为其它虚拟处理器，则不需要判定该处理主体是否在位，因为该处理主体一定不在位，所以可以仅在所有虚拟处理器均可以共享的存储区域内记录该中断请求，也可以似上段介绍的方式一样，主动去触发处理主体被宿主机换入，从而确保该中断请求被尽快处理。
由以上实施例可以看出，本发明实施例提供的中断请求处理方法使得虚拟处理器(或者说该虚拟处理器所服务的虚拟机)能够直接接收硬件产生的中断请求，对于其中的应用中断请求，虚拟处理器可以直接调用虚拟机内的中断服务程序进行处理，不再需要宿主机中转和虚拟处理器的陷入和陷出，从而极大的提升了应用中断请求的处理效率，降低了应用中断请求的处理时延。当然，对于客户操作系统中断请求，也有同样的效果。
进一步的，针对非当前虚拟处理器处理的中断请求，能够将该中断请求在当前虚拟处理器不需要陷出的前提下记录下来或在当前虚拟处理器不需要陷出的前提下发送给其他虚拟处理器，使得其他虚拟处理器可以尽快处理该中断请求，进一步提升了中断请求的处理效率。
进一步的，针对宿主机需要处理器的中断请求，能够反向发送到宿主机，实现该中断请求的及时处理，这样本发明实施例提供的方法就可以应用在必然存在宿主机需要处理的中断请求的复杂的系统中，使得本发明实施例的应用更广泛。
图5展示了一个更具体的实施例，在该实施例中，处理器为中央处理单元(central processing unit,CPU)210，虚拟处理器为vCPU，中断控制器为高级可编程中断控制器((Advanced Programmable Interrupt Controller,APIC))260。两个虚拟机分别为虚拟机29-1和虚拟机29-2。APIC260一般包括一个io-apic和4个分别于4个物理核对应的local-apic.
宿主机中断管理单元281包括中断配置单元2811、执行调度单元2812和中断接收单元2813。客户中断管理单元291包括中断调度单元2911、中断分发单元2912和中断触发单元2913。中断向量表31和运行实体表32中存储有处理中断请求所需的信息。为了方便信息管理，本实施例这两个表均位于所有虚拟机(所有虚拟处理器)和宿主机均可以访问的存储区域内，这样也方便实现下述所有实施例提供的方法。在其他一些实施例中，这两个表的形式和内容允许根据情况做些调整。
中断向量表31主要用来记录应用中断请求的标识以及该应用中断请求对应的处理主体和中断服务程序。进一步的，还可以记录IPI中断请求和/或客户操作系统中断请求的信息。
中断向量表31中还可以包括客户操作系统中断请求的标识，例如IPI中断，以及相应的处理主体和中断服务程序。
运行实体表32主要用来记录各个VM包含的所有vCPU当前的状态，比如是否在位，以及记录待各个vCPU处理的中断请求。
表1和表2分别为中断向量表31和运行实体表32的示例。
表1-中断向量表
Figure PCTCN2018092933-appb-000001
表1仅存储应用中断请求的IRQ ID以及该应用中断请求对应的处理主体和中断服务程序等信息。若一个中断请求的IRQ ID不在该表中，则默认该中断请求需要宿主机处理，该中断请求将会被发送给(或称注入)宿主机以便于宿主机处理该中断请求。
在其他一些实施例中，表1中也可以存储所有中断请求的标识，处理主体则记录为虚拟机或宿主机；或者存储所有中断请求的标识,但VM ID为空则表示处理主体为宿主机，等。信息存储的各种变形方式本领域技术人员均容易想到，在此不在一一赘述。
vCPU LIST在本发明实施例中的具体数据结构可以实现为位图，该位图中的每个位(bit)代表一个vCPU。
表1中的PRIORITY记录的是中断请求的优先级，中断请求的优先级设置方式需要和VMM中vCPU的优先级(参考表2)的设置方式相似，以便于后续两种优先级可以进行比较。一个中断请求的优先级可以与处理该中断请求的vCPU的优先级不相同。两种优先级的比较结果可作为一些实施例中中断请求到来后抢占哪个vCPU运行的判断依据。
PRIORITY在相关的VM启动之前进行配置。具体的，用户可以通过中断配置单元(2811)的统一配置接口(sysfs接口或proc接口)进行配置。中断类型TYPE也可以通过类似的方式配置。
表2-运行实体表
Figure PCTCN2018092933-appb-000002
在本申请的一些实施例中，中断向量表31和运行实体表32中存储的内容可以比表1和表2的示例更少或更多，例如两个表中的VM ID也可以不存储，但存储起来有些场景会方便一些，比如某中断请求可以被某个VM的所有vCPU处理，这时只判断VM ID就行；有些实施例可以不存储PRIORITY和/或TYPE信息。
每个虚拟机(29-1和29-2)和宿主机之间均具有配置通道33和注入通道34，配置通道33主要被客户中断管理单元291用来填写中断向量表31，注入通道34主要被客户中断管理单元291用来将待宿主机处理的中断请求注入到宿主机中，以便于宿主机中断管理单元281处理该中断请求。
虚拟机和宿主机中分别包含多个中断服务程序(292和283)，用于被调用后处理中断请求。虚拟机中的中断服务程序292通常是安装在其上的应用部署的，用来处理应用中断请求。当然也有一些292是客户操作系统290部署的，用来处理客户操作系统中断请求。
宿主机中还包含宿主机中断分发单元282，用于接收宿主机中断管理单元281(具体是中断接收单元2813)从客户中断管理单元291接收到的中断请求，并调用该中断请求对应的中断服务程序283。该宿主机中断分发单元282在一些现有的虚拟化架构中也存在，在本实施例中用于从宿主机中断管理单元281接收中断请求，而非直接从APIC260接收。图5的其他模块与图4类似，在此不再赘述。
基于图5，下面介绍详细的方法实现过程。
(一)宿主机中断管理单元的初始化
本实施例以宿主机中断管理单元281位于VMM内为例。图6为宿主机中断管理单元281的初始化过程的示意图。宿主机中断管理单元281伴随着VMM的初始化执行初始化。
中断配置单元2811的初始化(S501)包括准备配置通道33(S5011)和准备中断向量表31(S5012)。准备配置通道33(S5011)包括将用作配置通道33的hypercall函数挂接到VMM的hypercall框架中，这样虚拟机(29-1和29-2)就可以通过hypercall调用该函数以使用该配置通道33。准备中断向量表31(S5012)包括确定共享内存区，划分中断向量表31的表项等(参考表1)。该共享内存区用来存储中断向量表的内容。执行调度单元2812的初始化(S502)包括准备运行实体表32(S5021)。准备运行实体表32(S5021)包括确定另一个共享内存区，划分运行实体表32的表项等(参考表2)。该共享内存区用来存储运行实体表32的内容。
本实施例提供的“共享内存区”是所有虚拟机(29-1和29-2)和宿主机都可以访问的一段存储区域。
中断接收单元2813的初始化(S503)包括准备注入通道34(S5031)，具体包括将用于中断注入的hypercall函数挂接到VMM的hypercall框架中，这样虚拟机(29-1和29-2)就可以通过hypercall调用该函数。
以上三个单元的初始化可以在VMM的核心模块的初始化完成之前或之后进行，也可以在VMM的核心模块的初始化完成部分后执行，然后VMM的核心模块再继续完成剩余的初始化。以上三个单元的初始化可以并行执行，也可以串行执行，执行顺序本发明实施例不做限定。
(二)客户中断管理单元的初始化
VMM初始化完成并启动之后，宿主机中断管理单元281也初始化完成。之后，VMM将会创建并启动两台虚拟机(29-1和29-2)。在虚拟机(29-1和29-2)的创建和启动过程中，客户中断管理单元291完成初始化。
参考图7，一台虚拟机的整个启动过程分为两个部分：vCPU陷入之前和vCPU陷入之后。
S601：VMM180创建并初始化VM对象。
S602和S602-d：VMM180为该VM对象创建主vCPU和从vCPU。
图5中一台虚拟机有三个vCPU，其他一个为主vCPU，另两个为从vCPU，本实施例以主vCPU和其中一个从vCPU为例介绍，另一个从vCPU的初始化过程与该介绍的从vCPU类似。
S603：根据自定义的参数，VMM180配置主vCPU和从vCPU的中断接收模式和APIC260操作模式。配置的目的是使得vCPU在客户模式下(即陷入之后)可以接收APIC发送的中断请求，以及vCPU在客户模式下可以操作APIC260。这里自定义的参数是本申请定义的，这些参数用于通知VMM按照以上配置该VM。vCPU的这两个模式分别用该vCPU对应的寄存器上的不同位指示。
具体的，ARM64平台上关闭物理CPU的HCR_EL2(hypervisor configuration register EL2)寄存器的FMO和IMO两个bit位之后，vCPU即可在不陷出的前提下接收中断请求和操作物理APIC。X86平台上，将VMCS(virtual machine control structure)的Pin-Based VM-Execution Controls控制位的bit 0(external-interrupt exiting)置0，可以在不陷出的前提下接收中断请求；将VMCS的Pin-Based VM-Execution Controls控制位的bit 7(process posted interrupts)置0、VMCS的Primary Processor-Based VM-Execution Controls控制位的bit 21(Use TPR Shadow)置0、VMCS的Secondary Processor-Based VM-Execution Controls控制位的bit 8(APCI-register virtualization)和bit 9(Virtual-interrupt delivery)置0、VMCS的VM-execution control的MSR-Bitmap中涉及LAPIC的相关bit置0之后，vCPU可以直接操作物理APIC。
但该步骤S603中配置的是中断接收模式和APIC260操作模式所涉及到的内存对象的值(实质是将值记录在了内存中)，还没有真正修改物理的寄存器。
该步骤S603可以由宿主机中断管理单元281中的中断配置单元2811实现。
S604和S604-d：VMM180将主vCPU和从vCPU分别调度到物理核上，但此时主vCPU和从vCPU还没有陷入。
S605:VMM180更新运行实体表32。
VMM180将当前的vCPU的VM ID、vCPU ID,vCPU对应的物理核的CORE ID、以及vCPU的优先级记录到运行实体表32中。vCPU的优先级通常设置在VMM中，因此VMM可以获取到。多个vCPU的情况下，这多个vCPU各自在陷入之前更新运行实体表32。
由于经过步骤S604和S604-d，vCPU已经被换入，所以在运行实体表32中记录该vCPU运行的物理核的实际CORE ID。此时vCPU虽然还没有陷入，即vCPU还不在位，但是本实施例在更新运行实体表之后会设置vCPU马上陷入，所以在此时记录CORE ID和之前描述的表2的意义还是相符的。
该步骤S605可以由宿主机中断管理单元281中的执行调度单元2812实现。不仅初始化阶段，以后每次vCPU被换入之后，陷入客户模式之前，以及vCPU被换出之前执行调度单元2812都需要更新运行实体表32，保证运行实体表32中记录的vCPU在位或不在位的状态是准确的。
S606和S606-d:主vCPU和从vCPU陷入客户模式。主vCPU和从vCPU陷入时从各自对应的内存中读取步骤S603设置的中断接收模式和APIC操作模式所对应的属性的值，据此修改各自的寄存器。这里所修改的寄存器是vCPU所运行的物理核所对应的物理寄存器。
主vCPU和从vCPU陷入客户模式之后，分别进行不同的初始化。主vCPU这边执行 客户操作系统(guest OS)初始化，而从vCPU仅执行从vCPU的初始化。
在客户操作系统和从vCPU的初始化前阶段(S607和S607-d)完成后，客户中断管理单元291开始执行初始化(S608和S608-d)。客户中断管理单元291的初始化包括：
S609：中断分发单元2912通过中断配置单元2811提供的配置通道33获取中断向量表31的地址信息(仅需主vCPU执行)。地址信息具体可以是中断向量表31在存储器中的起始地址和结束地址。
S610：中断分发单元2912通过中断配置单元2811提供的配置通道33获取VM ID存在变量中(仅需主vCPU执行)。VM ID在其他一些实施例中也可以不获取。
S611：中断分发单元2912获取当前vCPU ID保存在变量中。主从vCPU均需执行，将vCPU ID保存在各自的变量中。
S612：中断分发单元2912将客户中断管理单元291的入口函数的地址配置于各个vCPU的相应寄存器，这样各个vCPU在接收到中断请求时就可以直接通过读取寄存器中的入口函数的地址获取并执行客户中断管理单元291的功能。因为本实施例中首先发挥作用的是中断分发单元2912，所以客户中断管理单元291的入口函数在本实施例中是中断分发单元2912的入口函数。
不同处理器对于利用哪一个寄存器存储中断处理的入口函数的规定不一样。对于X86系统，可以通过lidt指令修改中断描述符表寄存器(interrupt descriptor table register，IDTR)实现，具体的，通过lidt指令加载一个中断描述符表(interrupt descriptor table，IDT)到IDTR中，该IDT表中的关于中断处理的入口函数地址填为中断分发单元2912的入口函数。对于ARM64系统，通过msr指令修改寄存器vbar_el1(vector base address register el1)实现。
需要说明的是，一段程序(一个功能单元或模块)的“入口函数”就是指该程序(或该功能单元或模块)运行时候最开始调用的函数。“中断处理的入口函数”指的是vCPU被中断请求打断后执行的第一条指令所在的函数。例如，vCPU被中断请求打断后，需要执行的第一条指令是中断分发单元2912的指令，那么中断处理的入口函数就应该设置为中断分发单元2912的入口函数。
在完成客户中断管理单元291的初始化后，客户操作系统进入后一阶段的初始化过程(S613和S613-d)，直到客户操作系统的初始化全部完成，进而客户操作系统进入到应用(或业务)可运行的状态。之后，应用可以在客户操作系统上部署，并且应用可以通过中断分发单元2912提供的接口进行ISR的注册(S614和S614-d)。ISR注册时，中断分发单元2912通过配置通道33通知中断配置单元2811，此后vCPU陷出(S615)，然后中断配置单元2811修改中断向量表31，从而将注册信息填写到中断向量表31中，之后vCPU马上再陷入(S616)。
本领域技术人员应理解的是，在虚拟化设备中，虚拟机中各个单元的功能可以理解为vCPU读取并执行该单元的程序或指令后实现的。例如，中断分发单元2912通过配置通道33通知中断配置单元2811，可以认为是vCPU读取中断分发单元2912的程序，从而根据该程序调用配置通道33的hypercall函数(此后vCPU陷出到宿主模式)，然后宿主机(vCPU对应的host线程)读取中断配置单元2811的程序，从而根据该程序修改中断向量表，修改完成后vCPU再马上陷入客户模式。另外，本实施例中宿主机中断管理单元281位于VMM 内，所以宿主机中断管理单元281执行的动作也可以理解为是VMM执行的动作。不论是虚拟机中各个单元或vCPU执行，还是VMM或宿主机中各个单元执行，归根到底都是物理处理器运行软件程序执行。
由于中断配置单元2811已经将配置写入了VMM创建的vCPU对象中(参考步骤S603)，后续每次vCPU陷入时，均可以根据该配置设置vCPU对应的物理寄存器的值，从而达到vCPU在陷入之后直接从APIC接收所有中断请求而不需要陷出，以及vCPU可以直接操作物理APIC的效果。
(三)中断请求处理流程
经过以上步骤之后，虚拟化设备已经进入运行状态，其上部署的虚拟机以及虚拟机上的应用正在运行。下面详细介绍本实施例提出的虚拟化设备在运行过程中对中断请求的处理过程。
如图8A所示，首先，某一个硬件产生中断请求并将该中断请求发送给APIC260(S701a)，例如硬件网卡产生一个中断请求，并将该中断请求发送给APIC260。APIC260根据特定的规则将该中断请求发送给某一个物理核，则该物理核上正在客户模式运行的vCPU的执行被打断(S702a)。该vCPU的执行被打断后，由于之前已经配置了vCPU可以在客户模式接收中断，无需陷出，所以vCPU直接跳转到执行寄存器中存储的中断分发单元2912的入口函数，将中断请求发送给中断分发单元2912(S703a)，这样客户中断管理单元291的功能就陆续开始发挥作用了。有的中断请求会被APIC260发送到多个物理核上，每个物理核的处理方式均类似前述，不再一一赘述。
需要说明的是，中断请求的发送过程在不同的计算机架构中可能有所不同，例如在x86系统中，APIC260包括io-APIC和local-apic，其中，io-apic负责收集所有硬件产生的中断请求，并相应发送该一个local-apic，然后loca-apic再转发给对应的物理核。本实施例中为简化表述将此过程概括描述为APIC260发送中断请求给某一个物理核。
需要说明的是，在本实施例中，如果该中断请求被发送到的一个物理核上，但该物理核的vCPU不在位，即该物理核正在宿主模式，正在运行宿主机上的功能单元，该功能单元通常是VMM，那么该物理核(即该VMM)将不处理该中断请求，因为宿主模式的中断响应位被关闭了。后面会有实施例提供一种补偿方法，介绍在不关闭宿主模式的中断响应位的情况下，VMM如何处理该中断请求。
承接前述步骤S703a，如图8B所示，中断分发单元2912识别该中断请求的IRQ ID,并将该IRQ ID发送给中断调度单元2911(S701b)。中断调度单元2911根据该IRQ ID查询中断向量表中该中断请求的处理主体以及该中断请求对应的ISR的地址，即前述表1中该IRQ ID对应的vCPU list和ISR ADDR(S702b)。中断调度单元2911判断是否能查询到ISR ADDR(S703b)。
若不存在ISR ADDR，则说明该中断请求不是应用中断请求或客户操作系统中断请求，其处理主体不是虚拟机，所以中断调度单元2911将该查询结果返回给中断分发单元2912(S704b)，然后中断分发单元2912将该中断请求通过注入通道34注入宿主机(S705b)。具体的，中断分发单元2912可以将该中断请求通过注入通道34发送给宿主机中的中断接收单元2813，由中断接收单元2813将该中断请求发给宿主机中断分发单元282，然后宿主 机中断分发单元282调用宿主机中与该中断请求对应的ISR。宿主机中断分发单元282的处理为现有技术，在此不详述。
若存在ISR ADDR，则中断调度单元2911判断当前vCPU(即前述被打断执行的vCPU)是否包含在查询到的vCPU list中，即判断当前vCPU是否为该中断请求的处理主体之一(S706b)。
需要说明的是，在本实施例中，中断向量表31中存储了应用中断请求和客户操作系统中断请求，所以在判断处理主体时有以上判断方法，在其他实施例中，若中断向量表31的内容有变化，其判定处理主体的方法也可以适应性改变。
若当前vCPU包含在查询到的vCPU list中，则中断调度单元2911将查询获得的ISR ADDR返回给中断分发单元2912(S707b)，然后中断分发单元2912通知中断触发单元2913调用该ISR ADDR所指示的中断服务程序(S708b)，由该中断服务程序处理该中断请求。至此该中断请求处理完毕，vCPU将返回之前被打断的位置继续执行。
若当前vCPU没有包含在查询到的vCPU LIST中，则可以查询运行实体表32以确定vCPU LIST中存不存在在位的vCPU(S709b)。
若当前vCPU没有包含在查询到的vCPU LIST中且vCPU LIST中存在至少一个vCPU在位，那么中断调度单元2911从在位的vCPU中选择一个vCPU，然后发送一个IPI中断给该选择的vCPU(S710b)。该IPI中断中携带中断请求的标识(IRQ ID)，以便于该选择的vCPU对该中断请求进行处理。这里的选择可以是任意选择，也可以是根据vCPU LIST中所有vCPU的优先级选择一个优先级最低的。
若当前vCPU没有包含在查询到的vCPU LIST中且vCPU LIST中的vCPU均不在位，那么中断调度单元2911从该vCPU LIST中选择目标vCPU，并更新运行实体表32(S711b)。具体的，更新运行实体表32包括在运行实体表32中记录与该目标vCPU对应的PENDING位，记录该位的值为该中断请求的IRQ ID，以便于该目标vCPU处理该中断请求。“目标vCPU”可以包括vCPU LIST中的所有vCPU，也可以是任意选择的一个vCPU。进一步的，除了更新运行实体表32之外，中断调度单元2911还可以主动触发该目标vCPU的换入(S712b)，以便于该中断请求尽快被处理。选择什么vCPU作为目标vCPU以及是否主动触发该vCPU的换入可根据中断请求的优先级和vCPU的优先级确定，具体方法在下述实施例中会有详细介绍。
“目标vCPU”处理该中断请求的过程具体包括：该目标vCPU在被宿主机换入之后且陷入客户模式之前，宿主机中的执行调度单元2812读取运行实体表32中的该PENDING位，并给该目标vCPU发送一个与该中断请求的IRQ ID相同的中断请求，从而该目标vCPU可以在陷入客户模式之后处理该中断请求。该“目标vCPU”的数量可以是一个，也可以是多个。如果是该中断请求仅需一个vCPU处理即可，则在向第一个目标vCPU执行中断发送之后，清除掉其它vCPU对应的PENDING位，以避免其它vCPU陷入时再次对中断进行处理。
需要说明的是，一个vCPU接收到中断请求之后，该vCPU还需要保存被打断的任务的状态以及执行其他一些操作，以便于中断请求处理完成之后该vCPU能够返回继续执行被打断的任务，这些属于中断处理的惯常流程，本实施例在此不详述。
在其他一些实施例中，中断调度单元2911在确定当前vCPU没有包含在查询到的vCPU LIST中，也可以直接更新运行实体表32，以将vCPU LIST中包含的所有vCPU的PENDING位置为该中断请求的IRQ ID。
通过以上实施例可以看出，通过配置vCPU的中断接收模式，使得vCPU可以在客户模式下直接接收APIC发送的几乎所有中断请求，亦即中断可以直通到虚拟机的客户中断管理单元291，从而使得vCPU在处理应用中断请求时不需要陷入/陷出等切换，使得应用中断请求这种业务层面的中断请求具有更短的响应与处理路径，从而减小了应用中断请求的处理时延。本申请提供的方法可以保证高业务容量与高并发执行环境下业务中断请求在响应与处理上的超低时延要求，进而可以应用到5G(5th-Generation)等需要以超低时延作支撑的业务场景。
进一步的，对于非业务层面的中断请求通过注入通道34注入到宿主机层，然后由宿主机内的宿主机中断管理单元281和/或宿主机中断分发单元282作处理或再次分发，在保证应用中断请求高效处理的情况下，也保证了其他中断请求的及时处理。
进一步的，当接收到中断请求的vCPU并不是该中断请求的处理主体时，通过多个vCPU间共享的运行实体表32记录该中断请求，而且目标vCPU可以在换入之后查看并处理该中断请求，避免了VMM对中断请求的中转过程，进一步提高了中断请求的处理效率。并且让暂时不在位的vCPU可以延迟接收和处理中断请求，在多vCPU共核，vCPU非独占核的场景下，有效避免了中断请求的丢失。
进一步的，当接收到中断请求的vCPU并不是该中断请求的处理主体时，不仅更新运行实体表，还可以主动触发中断请求的处理主体的换入，从而进一步提高中断中断请求的处理效率。
如前述实施例中步骤S702a所示，APIC接收到一个中断请求后，将该中断请求根据特定的规则发送给某一个(或多个)物理核，由该物理核上正在运行的vCPU进行处理。如果不设置特别的规则，比如APIC随机发送或根据现有技术发送，那么在超分配(多vCPU共核)的场景下，中断请求很有可能被发送到一个不能处理该中断请求的vCPU中，所以下面介绍的实施例提供一种中断亲缘性的配置方法，能够使得中断请求最大概率地被发送给可以处理该中断且当前在位的vCPU，从而不需要执行前述步骤S709b和S710b等步骤，进而进一步提高中断的处理效率。
中断亲缘性作为中断控制器的属性，存储在中断控制器中，表示的是中断请求与物理核的亲缘性。中断请求将会被中断控制器发送给与该中断请求具有亲缘性的物理核上。具体的，一个中断请求的亲缘性可以实现为与该中断对应的一个亲缘性列表，该亲缘性列表中包含所有可以接收该中断请求的物理核的CORE ID。例如，X86系统中，当有一个io-APIC时，即所有产生中断请求的硬件均连接io-APIC,那么所有中断请求的中断亲缘性存储在io-APIC中；而当存在多个外设的中断控制部件时，不同硬件产生的中断请求的中断亲缘性存储在不同的中断控制部件中，可根据如下实施例介绍的方式分别进行更新。
本实施例提出的中断亲缘性的配置在一个vCPU被VMM换入之后，陷入客户模式之前执行，以及该vCPU被VMM换出时执行。该配置可以由宿主机中断管理单元281中的 执行调度单元2812实现。图9A和图9B介绍了中断亲缘性的配置过程。
参考图9A，在一个vCPU被换入但陷入客户模式之前，执行调度单元2812关闭VMM外部中断响应(S801a)，具体的，将该vCPU在宿主模式的寄存器位修改为指示关闭外部中断，使得VMM不能接收和处理中断请求。然后通过调用函数获取该vCPU运行的物理核的CORE ID(S802a)，例如在linux系统中，通过调用smp_processor_id()函数获取CORE ID。这里寄存器位在ARM64架构是程序状态寄存器(current program status register，cprs)的i bit位，在X64架构是cli指令实现.
当然因为vCPU被换入，所以此时也要更新运行实体表，具体的，将该vCPU所属的VM ID和vCPU ID，以及CORE ID记录到运行实体表中(S803a)。
除了更新运行实体表之外，为了实现中断亲缘性配置，执行调度单元2812先根据该vCPU ID从中断向量表中获取该vCPU可以处理的所有中断请求(IPI不需要设置)，然后访问APIC，将这些中断请求在APIC中的亲缘性加上该vCPU所运行的物理核(即前面获取的CORE ID)(S804a)，使得APIC在收到这些中断请求时，可以将这些中断请求发送给该物理核。
需要说明的是，对于vCPU绑核的场景，该亲缘性配置的操作S804a可以在VM启动时vCPU初次被换入后做一次，不需要每次vCPU换入时都修改中断控制器，因为vCPU运行的物理核是不变的。
在该vCPU陷入之前，执行调度单元2812还需要查询运行实体表32，如果发现有PENDING位的值不为-1，说明有中断请求未处理，则根据该PENDING位的IRQ ID，主动给该vCPU发送一个相同特征的中断请求。因为关闭了宿主模式(或者说宿主机)的中断接收，所以该vCPU只有在陷入之后才能接收并处理该中断请求。
图9A和以上描述为vCPU将要陷入时需要更新中断亲缘性，相应的，vCPU将要被换出时也要更新中断亲缘性。参考图9B，在一个vCPU陷出但被VMM换出之前，执行调度单元2812获取该vCPU运行的物理核的CORE ID(S801b))，然后将运行实体表32中该vCPU的vCPU ID对应的CORE ID的表项更新为-1(S802b)。除了更新运行实体表32之外，中断亲缘性也需要更新配置(S803b)。具体的，执行调度单元2812先根据该vCPU ID从中断向量表31中获取该vCPU可以处理的所有中断请求(IPI不需要设置)，然后访问APIC，将这些中断请求在APIC中的亲缘性减去该vCPU所运行的物理核。如果一个中断请求的亲缘性列表为空，则填充为-1，意思是所有物理核均可以接收该中断请求。在其他实施例中，S801b步骤也可以不执行，采用一些方式用vCPU ID也可以保证查找到需要修改的CORE ID。
需要说明的是，对于vCPU绑核的场景，该操作S803b可以在VM退出后只做一次。
采用上述方法配置亲缘性之后，去除了某些中断请求在vCPU间分发的必要性，使在vCPU非绑核场景下，中断请求能够以最大的概率命中目标vCPU，从而进一步缩短中断请求的处理时间，减少中断时延。
结合前述图8B的实施例，在设置了中断亲缘性之后，若中断调度单元2911在确定当前vCPU没有包含在vCPU LIST(S706b)之后，不需要执行S709b这个步骤，因为所有vCPU均不在位。步骤S710也不需要执行。中断调度单元2911可以直接按照vCPU LIST中所有 vCPU均不在位的情况继续进行处理。
前述实施例中当接收到中断请求的vCPU并不是该中断请求的处理主体时，且处理主体均不在位时，需要从该中断请求的处理主体中确定将来处理该中断请求的目标vCPU。下面一个实施例将详细介绍该目标vCPU如何确定，以及确定出来之后如何处理中断请求。该实施例提供的方法可以用于没有配置中断亲缘性的实施例，也可以用于配置了中断亲缘性的实施例。
表1的和表2分别记录了中断请求的优先级和vCPU的优先级。当确定接收到中断请求的vCPU并不是该中断请求的处理主体时，中断调度单元2911查询表1获得该中断请求的优先级。
本实施例中，当中断请求的优先级的数值大于或等于0时，需要与在位的vCPU的优先级进行比较，以确定是否抢占在位的vCPU。当数值为负数则不需要与在位的vCPU的优先级进行比较，具体的，当为-1，则永远不抢占在位的vCPU；当为-2，则直接抢占当前接收中断请求的当前vCPU。中断优先级默认为-2。优先级的设置和判断方式有很多种，本申请不一一列举，仅以此方式为例介绍下面的方法。
另外，这里所说的vCPU的优先级是指该vCPU上当前任务的优先级。中断调度单元2911在初始化时，注册客户操作系统的任务切换的HOOK，在客户操作系统任务切换时执行该HOOK。该HOOK的工作就是将客户操作系统的正准备换入的任务的优先级更新到表2中的PRIORITY中。
方法详细描述如下：
当该中断请求的优先级为-1时，说明该中断请求的优先级极低，不与在位的vCPU的优先级比较，直接如上段所述记录PENDING位即可。
当该中断请求的优先级大于或等于0且确定在位的所有vCPU的优先级均高于或等于该中断请求的优先级时，中断调度单元2911根据表1将该中断请求对应的vCPU LIST中的所有vCPU作为目标vCPU，然后将该目标vCPU在表2的相应的PENDING位修改为该中断请求的IRQ ID。这样vCPU LIST中的任何一个vCPU陷入之前，执行调度单元2812都能够查询到相应的PENDING位有中断请求未处理，然后发送一个相同的中断请求给该vCPU，而该vCPU在陷入之后可以接收并处理该中断请求。除非该中断请求是需要多核处理的中断请求，否则有一个vCPU被发送了该中断请求之后，其他vCPU的PENDING位需要被清除掉，这样就不会所有的vCPU都处理一遍该中断请求了。
当该中断请求的优先级大于或等于0且确定存在任意一个vCPU的优先级低于该中断请求的优先级时，中断调度单元2911选择优先级最低的vCPU作为“中转vCPU”，在该中断请求对应的vCPU LIST中选择优先级最高的vCPU作为目标vCPU，将该目标vCPU在表2的相应的PENDING位修改为该中断请求的IRQ ID。然后，中断调度单元2911通知中断分发单元2912发送一个IPI中断给中转vCPU(即当前vCPU向中转vCPU发一个IPI中断)，该IPI中断中携带目标vCPU的vCPU ID。该IPI中断中还可以携带待处理的中断请求的IRQ ID，但不是必须的，因为待处理的IRQ ID在前面步骤中已经记录在目标vCPU的PENDING位了。如果在方法前面没有记录IRQ ID，那这里需要携带，以便于被换入的目标vCPU知道自己要处理这个中断请求。
中转vCPU因为是从在位的vCPU中选择出来的，所以中转vCPU当前在位。中转vCPU收到该IPI中断之后，执行该IPI中断对应的ISR(这个ISR也注册在表1中，可以由中断触发单元2913来注册)。该IPI中断对应的ISR的实现是：当确定该IPI中断中携带的目标vCPU的vCPU ID与中转vCPU的vCPU ID不同时(本实施例就是如此)，则通过注入通道32向宿主机的中断接收单元2813执行反向注入，参数是目标vCPU的vCPU ID(可选的，还可以包括IRQ ID)，注入之后该中转vCPU就陷出。中断接收单元2813收到该注入之后，确定其中携带有目标vCPU的vCPU ID(说明中断请求的处理主体不是宿主机)，因此将该目标vCPU的vCPU ID发送给VMM中用于执行vCPU调度的调度器，以使得该VMM将该目标vCPU换入并将中转vCPU换出。
需要说明的是，这里之所以换出的是中转vCPU是因为中转vCPU在本实施例中是优先级最低的vCPU，换出它能够将中断请求对当前任务的影响降到最低。在其他实施例中，可以根据情况换出其他的vCPU，本申请对此不做限定。
目标vCPU换入之后，陷入客户模式之前，执行调度单元2812查询运行实体表32的PENDING位，确定该目标vCPU有中断请求未处理，则主动给该目标vCPU发送一个与未处理的中断请求同样的中断请求，以便于该目标vCPU在陷入客户模式之后处理。
当该中断请求的优先级为-2时,说明该中断请求非常紧急，也不需要和vCPU的优先级比较，中断调度单元2911立刻从vCPU LIST中选择优先级最高的vCPU作为目标vCPU(或任意选择一个)，然后调用表1中IPI对应的ISR(携带目标vCPU的vCPU ID)。该ISR的具体实现是：判断目标vCPU的vCPU ID与本vCPU不同，则通过注入通道32向宿主机的中断接收单元2813执行反向注入，参数目标vCPU ID。注入之后当前vCPU马上陷出。中断接收单元2813收到该反向注入之后，确定该注入中携带有目标vCPU的vCPU ID(说明该中断请求的处理主体不是宿主机)，将该目标vCPU的vCPU ID发送给VMM中用于执行vCPU调度的调度器，以使得该VMM将该目标vCPU换入并将当前vCPU换出。与前述方法类似，IRQ ID可以携带，也可以不携带。
可见，当在位的所有vCPU上的当前任务的优先级比该中断请求的优先级要高或相等时，这些vCPU暂时都不能被换出，所以为不影响当前任务的运行，不能主动触发vCPU的换出和换入，因此先记录下该中断请求，等待目标vCPU中的一个在恰当的时机被换入之后再处理。当该中断请求的优先级比较大或非常大时，可以主动抢占某个优先级低的vCPU的运行。这样，在尽量避免对vCPU当前任务影响的前提下，加快中断请求的处理。在实施该方法的过程中，通过运行实体表32获知的是整个系统的所有vCPU的状态和优先级，所以这种管理是系统级的，能够一定程度上保证系统的正常运行。
前述实施例中提到了一个vCPU向另一个vCPU发送IPI中断。下面一个实施例详细介绍一个vCPU如何向另一个vCPU发送IPI中断。这两个vCPU可以位于同一个VM内，也可以位于不同的VM内。为方便描述，下面实施例中将两个vCPU分别称为vCPU A和vCPU B。前面实施例使用IPI中断的地方可以相应参考该实施例。
vCPU A在客户模式且确定要向vCPU B发送IPI中断之后，vCPU A调用其所属的VM内的中断分发单元2912中的IPI发送函数，中断分发单元2912通知中断调度单元2911进 行调度，中断调度单元2911在运行实体表32中查找vCPU B对应的CORE ID表项用以确认vCPU B是否在位。
如果确定vCPU B在位，则中断调度单元2911直接操作APIC向vCPU B所运行的物理核发送IPI中断。前述实施例中提到的中转vCPU是从在位的vCPU中选择出的vCPU，所以适用于该步骤。例如在x86系统中，中断调度单元2911直接操作vCPU A所运行的物理核对应的local-apic向vCPU B所运行的物理核对应的local-apic发送IPI中断。
如果确定vCPU B不在位，则在运行实体表32中与vCPU B相关的PENDING位上记录该IPI中断，以便于vCPU B被换入之后处理该IPI中断。具体的，vCPU B被换入之后，陷入之前，查询PENDING位，然后向自己发送一个相同的IPI中断，陷入之后处理该IPI中断。
需要说明的是，IPI中断请求虽是一个特别的中断，但是其处理过程有些和前述实施例中的中断请求类似，所以可参考前述实施例，在此不再赘述。
通过不同vCPU间共享运行实体表以及前述实施例初始化时对vCPU的配置，使得vCPU可以在不陷出的情况下直接操作中断控制器发送IPI中断，提高了IPI中断的处理速度。
以上步骤可以应用于任意一种IPI中断请求。
进一步的，如果发送的IPI是前述实施例中用到的那种IPI的话，该IPI携带IRQ ID，也可以同时携带IRQ ID和vCPU ID。携带的vCPU ID不一定是vCPU B的ID。IRQ ID意味着该IPI的作用是通知别的vCPU处理IRQ ID指示的这个中断请求。vCPU ID指示的是需要处理这个中断请求的vCPU(即前述实施例中的目标vCPU)。
相应的，vCPU B收到该IPI中断后查询表1以调用该IPI中断对应的ISR来处理该IPI中断。该ISR的具体实现是，如果确定携带的vCPU ID与vCPU B相同或没有vCPU ID(说明vCPU B就是这个中断请求的处理主体)，则查询表1以调用携带的IRQ ID对应的ISR以处理该中断请求；如果确定携带的vCPU ID与vCPU B不同，则通过注入通道34向宿主机发送目标vCPU的vCPU ID。之后该vCPU B就陷出。宿主机将该vCPU ID发送给VMM中用于执行vCPU调度的调度器，以使得该VMM将该vCPU ID指示的vCPU换入。具体过程可参考前述涉及优先级配置的实施例。
一个vCPU要想在不陷出的前提下向另一个vCPU发送IPI中断，则需要宿主机配置该vCPU的中断控制器操作模式，使得该vCPU可以在不陷出的前提下操作中断控制器向另一个vCPU发送IPI中断。具体配置方法可参考前述实施例。
有一类中断请求需要多个vCPU处理，具体可以用表1中TYPE＝1表示。典型的如时钟中断、ARM64架构下的N2N外设中断，这类型的中断在物理CPU超分配的情况下,有可能无法到达每个需要处理该中断请求的vCPU，因为这些vCPU可能没有同时在位。这种情况下，需要将这个中断以“复制”的方式作再转发。下面的这个实施例将介绍本申请提出的一种“中断复制”的方法。
如图10所示，为每个物理核引入一个宿主机和虚拟机共享的vCPU队列35。一个物理核的vCPU队列35中包含有上一次在该物理核运行的vCPU。如果一个vCPU从该物理核 上被VMM换出，执行调度单元2812将该vCPU加入该vCPU队列35。如果该vCPU被VMM调度到别的物理核上运行，那么执行调度单元2812将该vCPU从该vCPU队列35中删除。
首先进行初始化。具体的，在宿主机中断管理单元281初始化阶段为每个物理核创建对应的vCPU队列35，这些队列存储在宿主机和虚拟机可共享的存储区域内。每个vCPU将自己希望处理的TYPE＝1的中断请求注册到中断向量表31中，注册的详细过程可参考前述实施例应用注册中断请求的过程。
对于已经处于客户模式的一个vCPU，在收到一个需要自己处理的中断请求之后，可以直接处理(包括直接在此操作物理中断控制器重新发起新的超时等待)，处理方法可参考前述实施例。除此之外，参考图11,在本实施例中，中断调度单元2911还需根据该中断请求的IRQ ID查询中断向量表的TYPE项(S901)，判断TYPE项的值是否为1(S902)。当确定该中断请求需要多个vCPU处理时，查找中断向量表31和该vCPU所运行的物理核的vCPU队列35(S903)，依次判断该vCPU队列35中的vCPU是否在与该IRQ ID对应的vCPU LIST中(S904)，如果是，则在运行实体表32中记录该vCPU对应的PENDING位，并确定中转vCPU，通过发送IPI中断给中转vCPU以最终实现VMM对该vCPU的调度，该vCPU被调度换入后处理该中断请求(S905)。关于触发vCPU换入的的更多详细内容可参考前述实施例。
通过为每个物理CPU设置跨层共享的vCPU队列，能够降低需要多个vCPU处理的中断请求的中断处理时延。以时钟中断为例，时钟中断对于一个操作系统来说是个既特殊又十分重要的中断。如果时钟中断能够被vCPU在客户模式直接接收到话，就可以极大的缩短时钟中断的响应时间，同时也能极大的提升它的精度。例如，目前在通常情况下，接收一个中断请求vCPU需要陷出和陷入，那么中断时延在10us+。这就意味着，设置一个5us的时钟中断(以5us的频率来做一个轻量级的事情，比如只耗费300ns的事情)是不可能的。采用本发明实施例提供的方法，时钟中断可以直通客户模式，且多个vCPU都可以定时接收和处理时钟中断，那时钟中断的时延就大大降低，这种设置就存在可能性了。
前述一些实施例在vCPU每次被换入时都关闭了VMM的中断响应，但是有些复杂的虚拟化计算机系统中是不允许关闭该中断响应的，下面的实施例针对此种系统提供一种补偿机制来加快应用中断请求的处理。
请参考图12，宿主机层新增了中断映射表284和VMM中断服务程序2814，VMM中断服务程序2814被注册到中断映射表284中，从而使得VMM收到应用中断请求后可以通过该中断映射表284查找到该VMM中断服务程序2814。
在宿主模式时(比如vCPU因异常而陷出)，VMM或Host的其它代码接收到应用中断请求，然后进入宿主机中断分发单元282。宿主机中断分发单元282查询中断映射表284以调用该应用中断请求对应的处理函数，即VMM中断服务程序2814。然后VMM中断服务程序2814根据中断向量表31和运行实体表32执行如下动作：
若该应用中断请求对应的vCPU LIST中的vCPU均不在位，那么可以参考前述实施例中修改PENDING位的处理方式，可以全部vCPU的PENDING位均修改，也可以根据中断优先级参考前述实施例进行处理。这样，vCPU被换入之后就可以处理该中断请求。如果存在有 相关的vCPU在位，则可以根据前述实施例发送IPI给在位的vCPU进行中断处理。
本领域技术人员可以理解的是，VMM中断服务程序2814的功能和前述实施例中客户中断管理单元291的部分功能类似，所以更多具体实现可参考前述实施例。中断向量表和中断映射表的结构和类型可以相同，本申请为了区分二者所以为二者起了不同的名字，其中“向量”和“映射”无意限定什么。
通过在宿主机的中断映射表284中注册VMM中断服务程序2814并在接收到应用中断请求时实现该VMM中断服务程序2814的功能，使得即使在宿主模式接收到应用中断请求，vCPU不必陷入就可以利用与其它实施例类似的发明机制，将应用中断请求引导到相应的vCPU进行处理，这样可以让本申请提供的方案可应用在宿主模式一定要开中断处理的复杂的计算机系统中。当然客户操作系统中断请求的处理也可以达到同样的效果。
随着网络技术的发展，5G将来会成为主流，在5G场景下，对网络设备的业务中断时延也有更加严苛的要求。采用本申请提供的方法，可以保证高业务容量与高并发执行环境下，业务中断请求在响应与处理上的超低时延，进而可以应用到5G等需要以超低时延作系统支撑的业务场景。
需要说明的是，前述实施例中提出单元或模块的划分仅作为一种示例性的示出，所描述的各个单元的功能仅是举例说明，本申请并不以此为限。程序设计人员可以根据需求合并其中两个或更多单元的功能，或者将一个单元的功能拆分从而获得更多更细粒度的单元，以及其他变形方式。
以上描述的各个实施例之间相同或相似的部分可相互参考。
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本发明提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明实施例所述的绘图装置可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。
以上所述，仅为本发明的一些具体实施方式，但本发明的保护范围并不局限于此。

Claims (30)

  1. 一种虚拟化设备，其特征在于：所述虚拟化设备包括硬件层、宿主机和虚拟计算机，所述虚拟计算机内包含有服务于该虚拟计算机的虚拟处理器，其中，
    所述宿主机用于配置所述虚拟计算机的虚拟处理器能够从所述硬件层接收中断请求；
    所述虚拟计算机用于从所述硬件层接收中断请求，根据信息确定所述接收到的中断请求的处理主体；当所述接收到的中断请求的处理主体包括所述虚拟计算机的当前虚拟处理器时，所述虚拟计算机根据所述信息调用与所述接收到的中断请求对应的中断服务程序以处理所述中断请求，所述信息中包括所述中断请求、所述处理主体以及所述中断服务程序的对应关系。
  2. 根据权利要求1所述的虚拟化设备，其特征在于，
    所述宿主机还用于配置所述虚拟计算机的虚拟处理器能够操作物理的中断控制器；
    所述虚拟计算机还用于当所述接收到的中断请求的处理主体为其他虚拟处理器且确定所述其他虚拟处理器中至少有一个在位时，操作所述物理的中断控制器向所述其他虚拟处理器中在位的一个或多个虚拟处理器发送IPI中断请求，所述IPI中断请求中携带所述接收到的中断请求的标识，所述其他虚拟处理器不包括所述虚拟计算机的所述当前虚拟处理器。
  3. 根据权利要求1或2所述的虚拟化设备，其特征在于，
    所述虚拟计算机还用于当所述接收到的中断请求的处理主体为其他虚拟处理器且确定所述其他虚拟处理器均不在位时，从所述其他虚拟处理器中确定目标虚拟处理器，在所述当前虚拟处理器和所述宿主机都可以访问的存储区域内记录所述接收到的中断请求的标识，所述其他虚拟处理器不包括所述虚拟计算机的所述当前虚拟处理器；
    所述宿主机还用于在换入所述目标虚拟处理器之后且所述目标虚拟处理器陷入之前根据所述存储区域内记录的标识向所述目标虚拟处理器发送中断请求，以便于所述目标虚拟处理器在陷入之后处理所述中断请求。
  4. 根据权利要求3所述的虚拟化设备，其特征在于,
    所述宿主机还用于设置中断请求的优先级，并将所述优先级记录在所述宿主机和所述虚拟计算机均可以访问的存储区域；
    所述虚拟计算机在从所述其他虚拟处理器中确定目标虚拟处理器方面具体用于：根据所述接收到的中断请求的优先级和虚拟处理器的优先级确定所述目标虚拟处理器，其中，所述虚拟处理器的优先级存储在所有虚拟计算机均可以访问的存储区域。
  5. 根据权利要求4所述的虚拟化设备，其特征在于,
    所述虚拟计算机在根据接收到的所述中断请求的优先级和虚拟处理器的优先级确定所述目标虚拟处理器方面具体用于：
    根据所述接收到的中断请求的标识在所述宿主机和所述虚拟计算机均可以访问的所述存储区域内查找以获取所述接收到的中断请求的优先级，比较所述接收到的中断请求的优先级与在位的所有虚拟处理器的优先级；若所述所有在位的虚拟处理器的优先级均高于或等于所述接收到的中断请求的优先级，则确定可以处理所述接收到的中断请求的所有虚拟处理器为所述目标虚拟处理器；
    若存在一个或多个在位的虚拟处理器的优先级低于所述接收到的中断请求的优先级，则确定可以处理所述接收到的中断请求的所有虚拟处理器中优先级最高的虚拟处理器为所述目标虚拟处理器。
  6. 根据权利要求5所述的虚拟化设备，其特征在于,若存在一个或多个在位的虚拟处理器的优先级低于所述接收到的中断请求的优先级，
    所述虚拟计算机还用于确定所述在位的所有虚拟处理器中优先级最低的虚拟处理器为中转虚拟处理器，并发送IPI中断请求给所述中转虚拟处理器，所述IPI中断请求中携带所述目标虚拟处理器的标识，以便于所述中转虚拟处理器根据所述IPI中断请求陷出；
    所述宿主机还用于换出所述中转虚拟处理器并换入所述目标虚拟处理器。
  7. 根据权利要求3所述的虚拟化设备，其特征在于，
    当所述接收到的中断请求的处理主体为所述其他虚拟处理器且确定所述其他虚拟处理器均不在位时，
    所述虚拟计算机还用于：将所述目标虚拟处理器的标识发送给宿主机并陷出，所述目标虚拟处理器为所述处理主体中的任意一个虚拟处理器或优先级最高的虚拟处理器；
    所述宿主机还用于：将所述虚拟计算机的所述当前虚拟处理器换出并根据所述目标虚拟处理器的标识换入所述目标虚拟处理器。
  8. 根据权利要求1所述的虚拟化设备，其特征在于，所述硬件层包括中断控制器，
    所述中断控制器用于根据中断亲缘性发送中断请求给对应的物理处理器，其中，所述中断亲缘性包含中断请求和物理处理器的对应关系；
    所述虚拟计算机在从所述硬件层接收中断请求方面具体用于从所述中断控制器接收所述中断请求；
    所述宿主机还用于配置所述中断控制器中的中断亲缘性，使得一个中断请求能够被发送到该中断请求的处理主体所包括的虚拟处理器上。
  9. 根据权利要求8所述的虚拟化设备，其特征在于，所述宿主机在配置所述中断控制器中的中断亲缘性方面具体用于：在换入一个虚拟处理器之后且该虚拟处理器陷入之前，将将要运行所述被换入的虚拟处理器的物理处理器与处理主体包括该虚拟处理器的所有中断请求在所述中断亲缘性中建立对应关系。
  10. 根据权利要求8或9所述的虚拟化设备，其特征在于，
    所述虚拟计算机还用于当所述接收到的中断请求的处理主体为其他虚拟处理器时，从所述其他虚拟处理器中确定目标虚拟处理器，并在所述当前虚拟处理器和所述宿主机都可以访问的存储区域内记录所述中断请求的标识，所述其他虚拟处理器不包括所述虚拟计算机的所述当前虚拟处理器；
    所述宿主机还用于在换入所述目标虚拟处理器之后根据所述存储区域内记录的标识向所述目标虚拟处理器发送中断请求，以便于所述目标虚拟处理器陷入之后处理所述中断请求。
  11. 根据权利要求10所述的虚拟化设备，其特征在于，
    所述宿主机还用于设置中断请求的优先级，并将所述优先级记录在所述宿主机和所述 虚拟计算机均可以访问的存储区域；
    所述虚拟计算机在从所述其他虚拟处理器中确定目标虚拟处理器方面具体用于：根据所述接收到的中断请求的优先级和虚拟处理器的优先级确定所述目标虚拟处理器，其中，所述虚拟处理器的优先级存储在所有虚拟处理器均可以访问的存储区域。
  12. 根据权利要求11所述的虚拟化设备，其特征在于，
    所述虚拟计算机在根据所述接收到的中断请求的优先级和虚拟处理器的优先级确定所述目标虚拟处理器方面具体用于：
    根据所述接收到的中断请求的标识在所述宿主机和所述虚拟计算机均可以访问的所述存储区域内查找以获取所述接收到的中断请求的优先级，比较所述接收到的中断请求的优先级与在位的所有虚拟处理器的优先级；若所述所有在位的虚拟处理器的优先级均高于或等于所述接收到的中断请求的优先级，则确定可以处理所述接收到的中断请求的所有虚拟处理器为所述目标虚拟处理器；
    若存在一个或多个在位的虚拟处理器的优先级低于所述接收到的中断请求的优先级，则确定可以处理所述接收到的中断请求的所有虚拟处理器中优先级最高的虚拟处理器为所述目标虚拟处理器。
  13. 根据权利要求12所述的虚拟化设备，其特征在于，若存在一个或多个在位的虚拟处理器的优先级低于所述接收到的中断请求的优先级，
    所述虚拟计算机还用于：确定所述在位的所有虚拟处理器中优先级最低的虚拟处理器为中转虚拟处理器，并发送IPI中断请求给所述中转虚拟处理器，所述IPI中断请求中携带所述目标虚拟处理器的标识，以便于所述中转虚拟处理器根据所述IPI中断请求陷出；
    所述宿主机还用于在所述中转虚拟处理器陷出之后换入所述目标虚拟处理器。
  14. 根据权利要求10所述的虚拟化设备，其特征在于，当所述接收到的中断请求的处理主体为所述其他虚拟处理器时，
    所述虚拟计算机还用于：将所述目标虚拟处理器的标识发送给宿主机并陷出，所述目标虚拟处理器为所述处理主体中的任意一个虚拟处理器或优先级最高的虚拟处理器；
    所述宿主机还用于：将所述虚拟计算机的所述当前虚拟处理器换出并根据所述目标虚拟处理器的标识换入所述目标虚拟处理器。
  15. 一种中断请求的处理方法，其特征在于，所述方法应用于虚拟化设备，所述方法包括：
    处理器在宿主模式时配置寄存器以使所述处理器在运行有虚拟处理器且所述虚拟处理器运行于客户模式时能够从所述虚拟化设备的其他硬件接收中断请求；
    所述处理器在客户模式时执行如下操作：
    所述处理器从所述其他硬件接收中断请求；
    所述处理器根据信息确定所述接收到的中断请求的处理主体；当所述接收到的中断请求的处理主体包括所述处理器上当前运行的虚拟处理器时，所述处理器根据所述信息调用与所述接收到的中断请求对应的中断服务程序以处理所述中断请求，所述信息中包括所述中断请求、所述处理主体以及所述中断服务程序的对应关系。
  16. 根据权利要求15所述的方法，其特征在于，还包括：
    所述处理器在宿主模式时配置所述将在所述处理器上运行的虚拟处理器能够操作所述虚拟化设备的物理的中断控制器；
    所述处理器在客户模式时还执行如下操作：
    当所述接收到的中断请求的处理主体为其他虚拟处理器且确定所述其他虚拟处理器中至少有一个在位时，操作所述物理的中断控制器向所述其他虚拟处理器中在位的一个或多个虚拟处理器发送IPI中断请求，所述IPI中断请求中携带所述接收到的中断请求的标识，所述其他虚拟处理器不包括所述处理器上当前运行的虚拟处理器。
  17. 根据权利要求15所述的方法，其特征在于，还包括：所述处理器在宿主模式时配置所述虚拟化设备的中断控制器的中断亲缘性，使得一个中断请求能够被发送到该中断请求的处理主体所包括的虚拟处理器上，所述中断亲缘性包含中断请求的标识和处理器的标识的对应关系；
    相应的，所述处理器从硬件接收中断请求包括：所述处理器接收所述中断控制器根据所述中断亲缘性向所述处理器发送的所述中断请求。
  18. 根据权利要求17所述的方法，其特征在于，
    所述处理器在宿主模式配置中断控制器的中断亲缘性包括：所述处理器在宿主模式换入一个虚拟处理器之后将所述处理器与处理主体包括所述换入的虚拟处理器的所有中断请求在所述中断亲缘性中建立对应关系。
  19. 根据权利要求17或18所述的方法，其特征在于，还包括：
    当所述接收到的中断请求的处理主体为其他虚拟处理器时，所述处理器在客户模式从所述其他虚拟处理器中确定目标虚拟处理器，并在所述处理器在客户模式和宿主模式都可以访问的存储区域内记录所述中断请求的标识，所述其他虚拟处理器不包括所述处理器上当前运行的虚拟处理器；
    所述处理器在宿主模式时在换入所述目标虚拟处理器之后且所述目标虚拟处理器陷入之前根据所述存储区域内记录的标识向所述目标虚拟处理器发送中断请求，以便于所述目标虚拟处理器陷入之后处理所述中断请求。
  20. 根据权利要求19所述的方法，其特征在于，还包括：
    所述处理器在宿主模式时设置所述中断请求的优先级，并将所述优先级记录在所述处理器在宿主模式和客户模式时均可以访问的存储区域；
    所述处理器在客户模式时从所述其他虚拟处理器中确定目标虚拟处理器包括：
    所述处理器根据所述接收到的中断请求的优先级和虚拟处理器的优先级确定所述目标虚拟处理器，其中，所述虚拟处理器的优先级存储在所有虚拟处理器均可以访问的存储区域。
  21. 根据权利要求19所述的方法，其特征在于，当所述接收到的中断请求的处理主体为所述其他虚拟处理器时，所述方法还包括：所述处理器在客户模式将所述目标虚拟处理器的标识反向注入，之后所述处理器离开客户模式进入宿主模式，其中所述目标虚拟处理器为所述其他虚拟处理器中的任意一个虚拟处理器或优先级最高的虚拟处理器；所述处理器在宿主模式将所述处理器上的虚拟处理器换出并根据所述目标虚拟处理器的标识换入所 述目标虚拟处理器。
  22. 根据权利要求15-21任意一项所述的方法，其特征在于，还包括：
    所述处理器在宿主模式修改所述信息以增加中断请求的标识、中断请求的处理主体和中断服务程序的对应关系，其中，所述信息存储在所述处理器在宿主模式和客户模式时均可以访问的存储区域内；
    所述处理器在客户模式根据所述信息确定所述接收到的中断请求的处理主体以及所述中断服务程序，包括：
    所述处理器访问所述信息，根据所述接收到的中断请求中携带的标识确定所述中断请求的处理主体和所述中断请求对应的中断服务程序。
  23. 一种中断请求的处理装置，其特征在于，所述处理装置应用于虚拟化设备中，所述虚拟化设备包括硬件层、宿主机和虚拟计算机；所述处理装置包括部署在所述宿主机内的宿主机中断管理单元和部署在所述虚拟计算机内的客户中断管理单元；
    所述宿主机中断管理单元用于配置所述虚拟计算机的虚拟处理器能够从所述硬件层接收中断请求；
    所述客户中断管理单元用于从所述硬件层接收中断请求，根据信息确定所述接收到的中断请求的处理主体；当所述接收到的中断请求的处理主体包括所述虚拟计算机的当前虚拟处理器时，所述虚拟计算机根据所述信息调用与所述接收到的中断请求对应的中断服务程序以处理所述中断请求，所述信息中包括所述中断请求、所述处理主体以及所述中断服务程序的对应关系。
  24. 一种虚拟化设备，其特征在于，包括处理器和存储器，所述存储器用于存储计算机可读指令，所述处理器用于读取所述计算机可读指令并实现如权利要求15-22任意一项所述的方法。
  25. 一种可读存储介质，其特征在于，用于存储计算机可读指令，当所述计算机可读指令被处理器读取时促使所述处理器实现如权利要求15-22任意一项所述的方法。
  26. 一种IPI中断请求的处理方法，其特征在于，包括：
    源虚拟处理器根据信息确定目的虚拟处理器所运行的物理处理器，其中所述信息记录在所述源虚拟处理器可以访问的存储区域内，所述信息中包括指示所述目的虚拟处理器所运行的物理处理器的信息；
    所述源虚拟处理器操作中断控制器向所述目的虚拟处理器所运行的所述物理处理器发送IPI中断请求；
    其中，所述源虚拟处理器由宿主机配置中断控制器操作模式，使得所述源虚拟处理器可以在不陷出的前提下操作所述中断控制器向所述目的虚拟处理器所运行的所述物理处理器发送所述IPI中断请求。
  27. 根据权利要求26所述的方法，其特征在于，所述IPI中断请求中携带其他中断请求的标识或者所述IPI中断请求中携带其他中断请求的标识和虚拟处理器的标识，所述方 法还包括：
    所述目的虚拟处理器确定所述IPI中断请求中没有携带虚拟处理器的标识或确定所述IPI中断请求中携带的所述虚拟处理器的标识与所述目的虚拟处理器的标识一致，则调用所述其他中断请求的标识对应的中断服务程序，以处理所述其他中断请求。
  28. 根据权利要求26所述的方法，其特征在于，所述IPI中断请求中携带虚拟处理器的标识，所述方法还包括：
    所述目的虚拟处理器确定所述IPI中断请求中携带的所述虚拟处理器的标识与所述目的虚拟处理器的标识不一致，则向所述宿主机发送所述虚拟处理器的标识并陷出，以便于所述宿主机将所述虚拟处理器的标识所指示的虚拟处理器换入。
  29. 根据权利要求26-28任意一项所述的方法，其特征在于，所述源虚拟处理器在确定所述目的虚拟处理器在位时才发送所述IPI中断请求，
    其中，所述源虚拟处理器确定所述目的虚拟处理器在位包括：
    所述源虚拟处理器查询所述信息以确定所述目的虚拟处理器是否在位，所述信息中还包括指示所述目的虚拟处理器是否在位的信息。
  30. 一种虚拟化设备，其特征在于，所述虚拟化设备包括源虚拟处理器和目的虚拟处理器，所述源虚拟处理器和目的虚拟处理器服务于同一个或不同的虚拟计算机，其中，
    所述源虚拟处理器根据信息确定所述目的虚拟处理器所运行的物理处理器，其中所述信息记录在所述源虚拟处理器可以访问的存储区域内，所述信息中包括指示所述目的虚拟处理器所运行的物理处理器的信息；
    所述源虚拟处理器操作中断控制器向所述目的虚拟处理器所运行的所述物理处理器发送IPI中断请求；
    其中，所述源虚拟处理器由所述宿主机配置中断控制器操作模式，使得所述源虚拟处理器可以在不陷出的前提下操作所述中断控制器向所述目的虚拟处理器所运行的所述物理处理器发送所述IPI中断请求。
PCT/CN2018/092933 2017-06-27 2018-06-26 中断请求的处理方法、装置及虚拟化设备 WO2019001434A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP23165232.2A EP4235420A3 (en) 2017-06-27 2018-06-26 Processing method and apparatus for interrupt request, and virtualization device
KR1020207000394A KR102339095B1 (ko) 2017-06-27 2018-06-26 인터럽트 요청 처리 방법 및 장치, 및 가상화된 디바이스
EP18822992.6A EP3627330B1 (en) 2017-06-27 2018-06-26 Processing method and apparatus for interrupt request, and virtualization device
US16/719,282 US11972285B2 (en) 2017-06-27 2019-12-18 Interrupt request processing method and apparatus, and virtualized device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710497931.0A CN109144679B (zh) 2017-06-27 2017-06-27 中断请求的处理方法、装置及虚拟化设备
CN201710497931.0 2017-06-27

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/719,282 Continuation US11972285B2 (en) 2017-06-27 2019-12-18 Interrupt request processing method and apparatus, and virtualized device

Publications (1)

Publication Number Publication Date
WO2019001434A1 true WO2019001434A1 (zh) 2019-01-03

Family

ID=64742803

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/092933 WO2019001434A1 (zh) 2017-06-27 2018-06-26 中断请求的处理方法、装置及虚拟化设备

Country Status (6)

Country Link
US (1) US11972285B2 (zh)
EP (2) EP4235420A3 (zh)
KR (1) KR102339095B1 (zh)
CN (1) CN109144679B (zh)
TW (1) TWI705375B (zh)
WO (1) WO2019001434A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3757783A1 (en) * 2019-06-28 2020-12-30 INTEL Corporation Inter-processor interrupt virtualization with pass-through of local interrupt controller

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11487574B2 (en) 2017-09-19 2022-11-01 Microsoft Technology Licensing, Llc Targeted interrupts for virtual processors
CN110633127A (zh) 2018-06-25 2019-12-31 华为技术有限公司 一种数据处理方法及相关设备
JP7196439B2 (ja) * 2018-07-03 2022-12-27 株式会社デンソー 仮想化環境におけるデバイスへのアクセス方法
CN111459623B (zh) * 2019-01-18 2024-04-12 华为技术有限公司 应用程序恢复运行的方法、装置及计算机
JP7450627B2 (ja) 2019-02-14 2024-03-15 インターナショナル・ビジネス・マシーンズ・コーポレーション 実行中インジケータを使用した有向割り込みの仮想化方法、システム、プログラム
IL284681B2 (en) 2019-02-14 2024-03-01 Ibm INTENDED DISRUPTION FOR MULTILEVEL VIRTUALIZATION
TWI759677B (zh) 2019-02-14 2022-04-01 美商萬國商業機器公司 用於具有回退之經引導中斷虛擬化之方法、電腦系統及電腦程式產品
US11113216B2 (en) * 2019-03-20 2021-09-07 Mediatek Inc. Dispatching interrupts in a multi-processor system based on power and performance factors
DE102019126897B4 (de) * 2019-10-07 2021-10-28 Infineon Technologies Ag Datenverarbeitungsvorrichtung und verfahren zum verarbeiten eines interrupts
US20210107512A1 (en) * 2020-03-27 2021-04-15 Intel Corporation Computing system for mitigating execution drift
CN112783600A (zh) * 2020-07-01 2021-05-11 中兴通讯股份有限公司 中断处理方法、中断管理器、电子设备、计算机可读介质
CN113918272B (zh) * 2020-07-10 2024-07-02 上海交通大学 分离式虚拟机及其虚拟机架构、构建方法和优化方法
CN114077379B (zh) * 2020-08-19 2024-03-26 华为技术有限公司 一种计算机设备、异常处理的方法以及中断处理的方法
US11748141B2 (en) * 2020-10-30 2023-09-05 Red Hat, Inc. Providing virtual devices direct access to clock times in memory locations managed by a hypervisor
CN114640579A (zh) * 2020-11-30 2022-06-17 华为技术有限公司 管理网络设备的方法、设备和系统
CN112817690B (zh) * 2021-01-22 2022-03-18 华东计算技术研究所（中国电子科技集团公司第三十二研究所） 一种面向arm架构虚拟化领域的中断虚拟化处理方法及系统
CN116762061A (zh) * 2021-01-28 2023-09-15 华为技术有限公司 一种中断上报装置、方法及虚拟化系统
US11755512B2 (en) 2021-08-17 2023-09-12 Red Hat, Inc. Managing inter-processor interrupts in virtualized computer systems
CN114003363B (zh) * 2021-11-01 2022-07-22 支付宝(杭州)信息技术有限公司 线程间中断信号发送方法及装置
CN114327814A (zh) * 2021-12-09 2022-04-12 阿里巴巴（中国）有限公司 任务调度方法、虚拟机、物理主机和存储介质
CN116795557B (zh) * 2022-03-15 2024-07-23 华为技术有限公司 通信方法、电子设备及可读存储介质
KR20240015952A (ko) * 2022-07-28 2024-02-06 삼성전자주식회사 컴퓨팅 장치 및 그 동작 방법
TWI816498B (zh) * 2022-08-03 2023-09-21 新唐科技股份有限公司 匯流排直接中斷服務裝置
WO2024065829A1 (en) * 2022-09-30 2024-04-04 Intel Corporation User interrupt moderation for user inter-processor-interrupts
CN115801531B (zh) * 2023-02-03 2023-05-12 广州世炬网络科技有限公司 部署于Linux物理机的基站系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050080965A1 (en) * 2003-09-30 2005-04-14 Bennett Steven M. Mechanism to control hardware interrupt acknowledgement in a virtual machine system
CN101135997A (zh) * 2006-08-29 2008-03-05 联想(北京)有限公司 一种虚拟机系统及其硬件设备中断处理方法
CN101436966A (zh) * 2008-12-23 2009-05-20 北京航空航天大学 虚拟机环境下的网络监控与分析系统
CN101620551A (zh) * 2009-05-07 2010-01-06 曙光信息产业(北京)有限公司 一种面向多虚拟机应用的网卡中断控制方法
CN102792272A (zh) * 2010-02-05 2012-11-21 超威半导体公司 配置成虚拟化客户本地中断控制器的处理器
CN106095578A (zh) * 2016-06-14 2016-11-09 上海交通大学 基于硬件辅助技术和虚拟cpu运行状态的直接中断递交方法

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8286162B2 (en) * 2005-12-30 2012-10-09 Intel Corporation Delivering interrupts directly to a virtual processor
CN100570587C (zh) * 2007-03-19 2009-12-16 联想(北京)有限公司 虚拟机系统及其高级可编程中断控制器的访问处理方法
US8055827B2 (en) * 2009-01-26 2011-11-08 Advanced Micro Devices, Inc. Guest interrupt controllers for each processor to aid interrupt virtualization
CN101561764B (zh) * 2009-05-18 2012-05-23 华为技术有限公司 一种多核环境下的补丁方法与补丁装置
US8949498B2 (en) * 2011-08-11 2015-02-03 Mellanox Technologies Ltd. Interrupt handling in a virtual machine environment
US9003094B2 (en) * 2011-08-30 2015-04-07 Red Hat Israel, Ltd. Optimistic interrupt affinity for devices
US9110878B2 (en) * 2012-01-18 2015-08-18 International Business Machines Corporation Use of a warning track interruption facility by a program
US9298504B1 (en) * 2012-06-11 2016-03-29 Amazon Technologies, Inc. Systems, devices, and techniques for preempting and reassigning tasks within a multiprocessor system
CN103744716B (zh) * 2014-01-15 2016-09-07 上海交通大学 一种基于当前vcpu调度状态的动态中断均衡映射方法
US9734326B2 (en) * 2014-02-04 2017-08-15 Nxp Usa, Inc. Dynamic interrupt stack protection
WO2015192381A1 (zh) * 2014-06-20 2015-12-23 华为技术有限公司 虚拟化平台处理中断方法和相关设备
US9772868B2 (en) * 2014-09-16 2017-09-26 Industrial Technology Research Institute Method and system for handling interrupts in a virtualized environment
US9910699B2 (en) * 2014-10-28 2018-03-06 Intel Corporation Virtual processor direct interrupt delivery mechanism
KR20160144688A (ko) * 2015-06-09 2016-12-19 한국전자통신연구원 큐를 이용한 smp 가상 머신 이벤트 라우터 및 방법
US10713195B2 (en) * 2016-01-15 2020-07-14 Intel Corporation Interrupts between virtual machines

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050080965A1 (en) * 2003-09-30 2005-04-14 Bennett Steven M. Mechanism to control hardware interrupt acknowledgement in a virtual machine system
CN101135997A (zh) * 2006-08-29 2008-03-05 联想(北京)有限公司 一种虚拟机系统及其硬件设备中断处理方法
CN101436966A (zh) * 2008-12-23 2009-05-20 北京航空航天大学 虚拟机环境下的网络监控与分析系统
CN101620551A (zh) * 2009-05-07 2010-01-06 曙光信息产业(北京)有限公司 一种面向多虚拟机应用的网卡中断控制方法
CN102792272A (zh) * 2010-02-05 2012-11-21 超威半导体公司 配置成虚拟化客户本地中断控制器的处理器
CN106095578A (zh) * 2016-06-14 2016-11-09 上海交通大学 基于硬件辅助技术和虚拟cpu运行状态的直接中断递交方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3757783A1 (en) * 2019-06-28 2020-12-30 INTEL Corporation Inter-processor interrupt virtualization with pass-through of local interrupt controller
US11003484B2 (en) 2019-06-28 2021-05-11 Intel Corporation Inter-processor interrupt virtualization with pass-through of local interrupt controller

Also Published As

Publication number Publication date
KR102339095B1 (ko) 2021-12-15
TW201905686A (zh) 2019-02-01
EP3627330B1 (en) 2023-04-26
CN109144679B (zh) 2022-03-29
US20200125397A1 (en) 2020-04-23
EP3627330A4 (en) 2020-10-21
US11972285B2 (en) 2024-04-30
TWI705375B (zh) 2020-09-21
KR20200015721A (ko) 2020-02-12
EP4235420A3 (en) 2023-11-08
EP3627330A1 (en) 2020-03-25
CN109144679A (zh) 2019-01-04
EP4235420A2 (en) 2023-08-30

Similar Documents

Publication Publication Date Title
TWI705375B (zh) 中斷請求的處理方法、裝置、虛擬化設備及可讀存儲介質
US10846145B2 (en) Enabling live migration of virtual machines with passthrough PCI devices
US10169269B2 (en) Architecture and method for managing interrupts in a virtualized environment
US10176007B2 (en) Guest code emulation by virtual machine function
CN107015845B (zh) Gpu虚拟化
US9619270B2 (en) Remote-direct-memory-access-based virtual machine live migration
US8151032B2 (en) Direct memory access filter for virtualized operating systems
EP2316069B1 (en) Lazy handling of end of interrupt messages in a virtualized environment
US8230155B2 (en) Direct memory access filter for virtualized operating systems
US8635612B2 (en) Systems and methods for hypervisor discovery and utilization
US10409633B2 (en) Hypervisor-visible guest thread management
US20160085568A1 (en) Hybrid virtualization method for interrupt controller in nested virtualization environment
US20060020940A1 (en) Soft-partitioning systems and methods
NO340567B1 (no) Hierarkisk virtualisering med en flernivå virtualiseringsmekanisme
WO2015088374A1 (en) Systems and methods for cross-architecture container virtualization
US11474848B2 (en) Fail-safe post copy migration of virtual machines
US20230229497A1 (en) Transparent and remote kernel execution in a heterogeneous computing system
US20200327048A1 (en) Implementing fine grain data coherency of a shared memory region
US11726807B2 (en) Safe execution of virtual machine callbacks in a hypervisor
US9038075B2 (en) Batch execution of system calls in an operating system
US20230043180A1 (en) Fail-safe post copy migration of containerized applications
CN117215718A (zh) 一种国产处理器虚拟化适配调优方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18822992

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20207000394

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2018822992

Country of ref document: EP

Effective date: 20191219