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

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中断请求中除所述目标虚拟处理器的标识之外还携带中断请求的标识，所述中转虚拟处理器陷出时将该中断请求的标识发送给宿主机，宿主机换入目标虚拟化处理器后根据该标识向目标虚拟处理器发送一个相同的中断请求。

结合第一方面的以上任意一种实现方式，在一些实现方式下，该虚拟化设备将虚拟处理器在位还是不在位的状态信息存储在所有虚拟处理器(亦即所有虚拟机)均可以访问的存储区域内，具体可以通过一个或多个表来记录。为了方便描述，该记录在本申请的一些实施例称之为“运行实体表”，但本申请对该表名称不做限定。同样的，下述实现方式中将会出现的“中断向量表”或“中断映射表”也是如此。

结合第一方面的以上任意一种实现方式，在一些实现方式下，虚拟处理器的调度是由宿主机执行，具体可以是宿主机中的虚拟机监控装置执行的，所以运行实体表的更新由宿主机来执行，这就意味运行实体表的存储区域宿主机也能访问。具体的，当宿主机换入一个虚拟处理器之后且虚拟处理器陷入之前将该虚拟处理器在运行实体表的相应状态更新为在位，然后虚拟处理器陷入。一个虚拟处理器陷出但宿主机换出该虚拟处理器之前将该虚拟处理器在运行实体表的相应状态更新为不在位，然后宿主机换出该虚拟处理器。

通过所有虚拟处理器和宿主机均可访问的运行实体表，能够及时获取虚拟处理器的最新状态。若中断请求的处理主体在位，当前虚拟处理器可以在不陷出的情况下直接发送该中断请求给该在位的虚拟处理器；若中断请求的处理主体均不在位，当前虚拟处理器也可以在不陷出的情况下在运行实体表内记录下该中断请求或进一步触发目标虚拟处理器的陷入等，这样目标虚拟处理器陷入之后就可以处理该中断请求，避免虚拟处理器陷入陷出造成的时延，提高了中断请求的处理效率。

结合第一方面或第一方面的以上任意一种实现方式，在第七种实现方式下，为了尽量避免出现收到中断请求的虚拟处理器并不是该中断请求的处理主体，以期进一步降低中断处理的时延，需要修改一下中断控制器的中断亲缘性，中断亲缘性是中断控制器的一个属性。该中断亲缘性包含中断请求的标识和物理处理器的标识(本申请可简称为处理器)的对应关系。中断控制器是一个硬件，用于接收其他硬件产生的中断请求并根据中断亲缘性发送中断请求给对应的物理处理器。相应的，所述宿主机还用于配置所述中断控制器中的中断亲缘性，使得一个中断请求能够被发送到该中断请求的处理主体包括的虚拟处理器上。由于虚拟处理器运行在物理处理器上，所以要保证中断请求被发送的对的虚拟处理器上，实际上就是保证中断请求被发送到该对的虚拟处理器所运行的物理处理器上。

结合第一方面的第七种实现方式，在第八种实现方式下，所述宿主机在换入一个虚拟处理器之后且该虚拟处理器陷入之前，将将要运行所述被换入的虚拟处理器的物理处理器与处理主体包括该被换入的虚拟处理器的所有中断请求在所述中断亲缘性中建立对应关系，之后该虚拟处理器就陷入运行。

这样，中断控制器就能够根据该修改后的中断亲缘性将中断请求发送给该虚拟处理器所运行的物理处理器，亦即发送给该虚拟处理器，而该中断请求的处理主体正好包括该虚拟处理器，那该虚拟处理器就可以直接处理该中断请求，有效避免了中断请求在虚拟处理器之间的分发。

相应的，宿主机在换出一个虚拟处理器之前，(除了更新运行实体表之外)从中断亲缘性中删除该将要被换出的虚拟处理器与处理主体包括该虚拟处理器的所有中断请求之间的对应关系。

配置中断控制器的中断亲缘性之后，中断请求会被最大可能地发送给能够处理该中断请求且当前在位的虚拟处理器，极大地避免了虚拟处理器之间的中断请求分发，进一步提高了中断请求的处理效率。

结合第一方面的第七或第八种实现方式，在第九种实现方式下，即便配置了中断亲缘性，一个虚拟处理器还是有可能收到自己不可处理的中断请求，这个时候，由于配置了中断亲缘性，那么可以确定该中断请求的处理主体所包括的所有虚拟处理器均不在位，所以此时不需要判断中断请求的处理主体是否在位。其他的实现方式可参考前述第二种、第三种、第四种、第五种或第六种实现方式，相应的效果也可参考。例如，从中断请求的处理主体中确定待处理该中断请求的目标虚拟处理器(可以包括全部处理主体)，然后针对该目标虚拟处理器仅记录下中断请求的标识；进一步的，还可以根据中断请求的优先级合理选择目标虚拟处理器；更进一步的，还可以主动触发该目标虚拟处理器的换入，使得该中断请求尽快被处理。

结合第一方面或第一方面的以上任意一种实现方式，在一些实现方式下，所述虚拟计算机还用于当所述接收到的中断请求的处理主体为所述宿主机时，所述虚拟计算机将所述接收到的中断请求注入所述宿主机；所述宿主机还用于接收并处理所述虚拟计算机注入的所述中断请求。

结合第一方面或第一方面的以上任意一种实现方式，在一些实现方式下，所述虚拟计算机具体用于根据中断向量表和所述接收到的中断请求的标识确定所述中断请求的处理主体和所述中断请求对应的中断服务程序，所述中断向量表中包含中断请求的标识、所述中断请求的处理主体以及所述中断请求的中断服务程序之间的对应关系，所述中断向量表存储在所述虚拟计算机和所述宿主机均可以访问的存储区域内；所述宿主机还用于(在所述虚拟计算机的触发下)修改所述中断向量表以增加中断请求的标识、所述中断请求的处理主体和中断服务程序的对应关系。

通过跨层共享(即虚拟处理器和宿主机可以共享)的中断向量表存储中断请求、中断请求的处理主体以及中断服务程序之间的对应关系等信息，能够使得一个虚拟处理器在需要这些信息处理中断请求时直接访问存储区域即可，不需要陷出，避免了因陷出带来的中断时延。这些信息这样存储可节省存储空间，进一步的，可以由宿主机修改这些信息，这样设计更加合理和安全。

第二方面，本申请提供一种中断请求的处理方法，该方法应用于虚拟化设备，虚拟化设备中包括处理器以及宿主模式和客户模式两种不同的运行模式。

处理器在宿主模式时配置寄存器以使所述处理器在运行有虚拟处理器且所述虚拟处理器运行于客户模式时能够从所述虚拟化设备的其他硬件接收中断请求；

所述处理器在客户模式时执行如下操作：所述处理器从所述其他硬件接收中断请求，所述处理器根据所述中断请求确定所述接收到的中断请求的处理主体；当所述接收到的中断请求的处理主体包括所述处理器上当前运行的虚拟处理器时，所述处理器根据所述中断请求确定与所述接收到的中断请求对应的中断服务程序，并调用所述中断服务程序以处理所述中断请求。具体的，接收到的中断请求中可以携带所述中断请求的标识，例如IRQID，后续根据标识确定处理主体和中断服务程序。

进一步的，虚拟计算机根据一些信息和所述中断请求确定所述中断请求的处理主体和中断服务程序。这些信息包括中断请求(标识)、处理主体以及中断服务程序的对应关系。

这里的“处理器”可以理解为一个最小的物理处理单元，比如物理核。

结合第二方面，在第一种实现方式下，所述处理器在宿主模式时配置所述将在所述处理器上运行的虚拟处理器能够操作所述虚拟化设备的物理的中断控制器；

所述处理器在客户模式时还执行如下操作：当所述接收到的中断请求的处理主体为不包括所述处理器上当前运行的所述虚拟处理器的其他虚拟处理器且确定所述其他虚拟处理器中至少有一个在位时，操作所述物理的中断控制器向所述其他虚拟处理器中在位的一个或多个虚拟处理器发送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)。其中，虚拟硬件平台对其上运行的各个虚拟计算机提供各种硬件资源，如虚拟处理器、虚拟内存、虚拟磁盘、虚拟网卡等。虚拟计算机则运行在宿主机层为其准备的虚拟硬件平台上。本申请中有时将宿主机层简称为宿主机。

硬件层：虚拟化环境运行的硬件平台。其中，硬件层可包括多种硬件，例如某物理计算机的硬件层可包括处理器和存储器，还可以包括中断控制器、网卡(networkinterface 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)。一台虚拟计算机可以有一个或多个虚拟处理器为其服务，当存在多个虚拟处理器时，通常有一个虚拟处理器为主虚拟处理器,其他为从虚拟处理器。

应理解，虚拟计算机相当于一台独立的计算机，所以虚拟计算机执行动作也可以认为是虚拟处理器执行该动作，而虚拟处理器是软件实现的，所以虚拟处理器执行动作实际上是虚拟处理器所运行的物理处理器或物理核执行该动作。在本发明的多个实施例中，为遵循当下场景的技术表达习惯，会有选择地使用以上表述方式。

虚拟处理器陷入和虚拟处理器陷出：虚拟化系统包括两种模式：宿主模式(hostmode)与客户模式(guest mode)。当一个虚拟处理器进入客户模式，叫做陷入(虚拟)；当该虚拟处理器离开客户模式，叫陷出(虚拟)。虚拟处理器陷出后物理处理器将暂时不执行该虚拟处理器的代码，所以此时可以理解为虚拟处理器没有运行。在本申请的多数实施例中以vCPU这种虚拟处理器为例介绍方法或装置，所以这些实施例中具体为vCPU陷入或陷出。针对一个物理处理器而言，其上运行的虚拟处理器陷入，则可以认为该物理处理器处于客户模式，运行虚拟处理器的代码，当其上运行的虚拟处理器陷出到宿主模式，则可以认为该物理处理器处于宿主模式，运行宿主机相关的代码，比如VMM。

虚拟处理器在位或不在位：虚拟处理器陷入之后的状态称之为在位，没有陷入的状态称之为不在位。一个虚拟处理器在位可以理解为该虚拟处理器正在运行，即存在一个物理处理器执行了该虚拟处理器的代码；一个虚拟处理器不在位即没有物理处理器执行该虚拟处理器的代码。在本申请的多数实施例中以vCPU这种虚拟处理器为例介绍方法或装置，所以这些实施例中具体为vCPU在位或不在位。

IPI：inter-processor interrupt，即处理器间的中断，是一种特别的中断，是一个处理器发送给另一个处理器的中断请求。例如，APIC的中断命令寄存器(interruptcommand 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 channelarchitecture,MCA)总线，扩展ISA(extended-ISA)总线，视频电子标准协会(videoelectronics standards association,VESA)局域总线，以及外围器件互联(peripheralcomponent 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展示了一个更具体的实施例，在该实施例中，处理器为中央处理单元(centralprocessing 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-中断向量表

表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-运行实体表

在本申请的一些实施例中，中断向量表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是客户操作系统部署的，用来处理客户操作系统中断请求。

宿主机中还包含宿主机中断分发单元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 configurationregister 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的SecondaryProcessor-Based VM-Execution Controls控制位的bit 8(APCI-registervirtualization)和bit 9(Virtual-interrupt delivery)置0、VMCS的VM-executioncontrol的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开始执行初始化。客户中断管理单元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 tableregister，IDTR)实现，具体的，通过lidt指令加载一个中断描述符表(interruptdescriptor table，IDT)到IDTR中，该IDT表中的关于中断处理的入口函数地址填为中断分发单元2912的入口函数。对于ARM64系统，通过msr指令修改寄存器vbar_el1(vector baseaddress register el1)实现。

需要说明的是，一段程序(一个功能单元或模块)的“入口函数”就是指该程序(或该功能单元或模块)运行时候最开始调用的函数。“中断处理的入口函数”指的是vCPU被中断请求打断后执行的第一条指令所在的函数。例如，vCPU被中断请求打断后，需要执行的第一条指令是中断分发单元2912的指令，那么中断处理的入口函数就应该设置为中断分发单元2912的入口函数。

在完成客户中断管理单元291的初始化后，客户操作系统进入后一阶段的初始化过程(S613和S613-d)，直到客户操作系统的初始化全部完成，进而客户操作系统进入到应用(或业务)可运行的状态。之后，应用可以在客户操作系统上部署，并且应用可以通过中断分发单元2912提供的接口进行ISR的注册(S614和S614-d)。ISR注册时，中断分发单元2912通过配置通道33通知中断配置单元2811，此后vCPU陷出，然后中断配置单元2811修改中断向量表31，从而将注册信息填写到中断向量表31中，之后vCPU马上再陷入。

本领域技术人员应理解的是，在虚拟化设备中，虚拟机中各个单元的功能可以理解为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中该IRQID对应的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将查询获得的ISRADDR返回给中断分发单元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所属的VMID和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的vCPUID对应的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(可选的，还可以包括IRQID)，注入之后该中转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表项用以确认vCPUB是否在位。

如果确定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携带IRQID，也可以同时携带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 (18)

1.一种虚拟化设备，其特征在于：所述虚拟化设备包括硬件层、宿主机和虚拟计算机，所述虚拟计算机内包含有服务于该虚拟计算机的虚拟处理器，其中，

所述宿主机用于配置所述虚拟计算机的虚拟处理器能够从所述硬件层接收中断请求；

所述虚拟计算机用于从所述硬件层接收中断请求，根据信息确定所述接收到的中断请求的处理主体；当所述接收到的中断请求的处理主体包括所述虚拟计算机的当前虚拟处理器时，所述虚拟计算机根据所述信息调用与所述接收到的中断请求对应的中断服务程序以处理所述中断请求，所述信息中包括所述中断请求、所述处理主体以及所述中断服务程序的对应关系；

所述硬件层包括中断控制器，

所述中断控制器用于根据中断亲缘性发送中断请求给对应的物理处理器，其中，所述中断亲缘性包含中断请求和物理处理器的对应关系；

所述虚拟计算机在从所述硬件层接收中断请求方面具体用于从所述中断控制器接收所述中断请求；

所述宿主机还用于配置所述中断控制器中的中断亲缘性，使得一个中断请求能够被发送到该中断请求的处理主体所包括的虚拟处理器上；

所述宿主机在配置所述中断控制器中的中断亲缘性方面具体用于：在换入一个虚拟处理器之后且该虚拟处理器陷入之前，将将要运行被换入的所述虚拟处理器的物理处理器与处理主体包括该虚拟处理器的所有中断请求在所述中断亲缘性中建立对应关系。

2.根据权利要求1所述的虚拟化设备，其特征在于，

所述虚拟计算机还用于当所述接收到的中断请求的处理主体为其他虚拟处理器时，从所述其他虚拟处理器中确定目标虚拟处理器，并在所述当前虚拟处理器和所述宿主机都可以访问的存储区域内记录所述中断请求的标识，所述其他虚拟处理器不包括所述虚拟计算机的所述当前虚拟处理器；

所述宿主机还用于在换入所述目标虚拟处理器之后根据所述存储区域内记录的标识向所述目标虚拟处理器发送中断请求，以便于所述目标虚拟处理器陷入之后处理所述中断请求。

3.根据权利要求2所述的虚拟化设备，其特征在于，

所述宿主机还用于设置中断请求的优先级，并将所述优先级记录在所述宿主机和所述虚拟计算机均可以访问的存储区域；

所述虚拟计算机在从所述其他虚拟处理器中确定目标虚拟处理器方面具体用于：根据所述接收到的中断请求的优先级和虚拟处理器的优先级确定所述目标虚拟处理器，其中，所述虚拟处理器的优先级存储在所有虚拟处理器均可以访问的存储区域。

4.根据权利要求3所述的虚拟化设备，其特征在于，

所述虚拟计算机在根据所述接收到的中断请求的优先级和虚拟处理器的优先级确定所述目标虚拟处理器方面具体用于：

根据所述接收到的中断请求的标识在所述宿主机和所述虚拟计算机均可以访问的所述存储区域内查找以获取所述接收到的中断请求的优先级，比较所述接收到的中断请求的优先级与在位的所有虚拟处理器的优先级；若所述所有在位的虚拟处理器的优先级均高于或等于所述接收到的中断请求的优先级，则确定可以处理所述接收到的中断请求的所有虚拟处理器为所述目标虚拟处理器；

若存在一个或多个在位的虚拟处理器的优先级低于所述接收到的中断请求的优先级，则确定可以处理所述接收到的中断请求的所有虚拟处理器中优先级最高的虚拟处理器为所述目标虚拟处理器。

5.根据权利要求4所述的虚拟化设备，其特征在于，若存在一个或多个在位的虚拟处理器的优先级低于所述接收到的中断请求的优先级，

所述虚拟计算机还用于：确定所述在位的所有虚拟处理器中优先级最低的虚拟处理器为中转虚拟处理器，并发送IPI中断请求给所述中转虚拟处理器，所述IPI中断请求中携带所述目标虚拟处理器的标识，以便于所述中转虚拟处理器根据所述IPI中断请求陷出；

所述宿主机还用于在所述中转虚拟处理器陷出之后换入所述目标虚拟处理器。

6.根据权利要求2所述的虚拟化设备，其特征在于，当所述接收到的中断请求的处理主体为所述其他虚拟处理器时，

所述虚拟计算机还用于：将所述目标虚拟处理器的标识发送给宿主机并陷出，所述目标虚拟处理器为所述处理主体中的任意一个虚拟处理器或优先级最高的虚拟处理器；

所述宿主机还用于：将所述虚拟计算机的所述当前虚拟处理器换出并根据所述目标虚拟处理器的标识换入所述目标虚拟处理器。

7.一种中断请求的处理方法，其特征在于，所述方法应用于虚拟化设备，所述方法包括：

处理器在宿主模式时配置寄存器以使所述处理器在运行有虚拟处理器且所述虚拟处理器运行于客户模式时能够从所述虚拟化设备的其他硬件接收中断请求；

所述处理器在客户模式时执行如下操作：

所述处理器从所述其他硬件接收中断请求；

所述处理器根据信息确定所述接收到的中断请求的处理主体；当所述接收到的中断请求的处理主体包括所述处理器上当前运行的虚拟处理器时，所述处理器根据所述信息调用与所述接收到的中断请求对应的中断服务程序以处理所述中断请求，所述信息中包括所述中断请求、所述处理主体以及所述中断服务程序的对应关系；

还包括：所述处理器在宿主模式时配置所述虚拟化设备的中断控制器的中断亲缘性，使得一个中断请求能够被发送到该中断请求的处理主体所包括的虚拟处理器上，所述中断亲缘性包含中断请求的标识和处理器的标识的对应关系；

相应的，所述处理器从硬件接收中断请求包括：所述处理器接收所述中断控制器根据所述中断亲缘性向所述处理器发送的所述中断请求；

所述处理器在宿主模式配置中断控制器的中断亲缘性包括：所述处理器在宿主模式换入一个虚拟处理器之后将所述处理器与处理主体包括所述换入的虚拟处理器的所有中断请求在所述中断亲缘性中建立对应关系。

8.根据权利要求7所述的方法，其特征在于，还包括：

当所述接收到的中断请求的处理主体为其他虚拟处理器时，所述处理器在客户模式从所述其他虚拟处理器中确定目标虚拟处理器，并在所述处理器在客户模式和宿主模式都可以访问的存储区域内记录所述中断请求的标识，所述其他虚拟处理器不包括所述处理器上当前运行的虚拟处理器；

所述处理器在宿主模式时在换入所述目标虚拟处理器之后且所述目标虚拟处理器陷入之前根据所述存储区域内记录的标识向所述目标虚拟处理器发送中断请求，以便于所述目标虚拟处理器陷入之后处理所述中断请求。

9.根据权利要求8所述的方法，其特征在于，还包括：

所述处理器在宿主模式时设置所述中断请求的优先级，并将所述优先级记录在所述处理器在宿主模式和客户模式时均可以访问的存储区域；

所述处理器在客户模式时从所述其他虚拟处理器中确定目标虚拟处理器包括：

所述处理器根据所述接收到的中断请求的优先级和虚拟处理器的优先级确定所述目标虚拟处理器，其中，所述虚拟处理器的优先级存储在所有虚拟处理器均可以访问的存储区域。

10.根据权利要求8所述的方法，其特征在于，当所述接收到的中断请求的处理主体为所述其他虚拟处理器时，所述方法还包括：所述处理器在客户模式将所述目标虚拟处理器的标识反向注入，之后所述处理器离开客户模式进入宿主模式，其中所述目标虚拟处理器为所述其他虚拟处理器中的任意一个虚拟处理器或优先级最高的虚拟处理器；所述处理器在宿主模式将所述处理器上的虚拟处理器换出并根据所述目标虚拟处理器的标识换入所述目标虚拟处理器。

11.根据权利要求7-10任意一项所述的方法，其特征在于，还包括：

所述处理器在宿主模式修改所述信息以增加中断请求的标识、中断请求的处理主体和中断服务程序的对应关系，其中，所述信息存储在所述处理器在宿主模式和客户模式时均可以访问的存储区域内；

所述处理器在客户模式根据所述信息确定所述接收到的中断请求的处理主体以及所述中断服务程序，包括：

所述处理器访问所述信息，根据所述接收到的中断请求中携带的标识确定所述中断请求的处理主体和所述中断请求对应的中断服务程序。

12.一种虚拟化设备，其特征在于，包括处理器和存储器，所述存储器用于存储计算机可读指令，所述处理器用于读取所述计算机可读指令并实现如权利要求7-11任意一项所述的方法。

13.一种可读存储介质，其特征在于，用于存储计算机可读指令，当所述计算机可读指令被处理器读取时促使所述处理器实现如权利要求7-11任意一项所述的方法。

14.一种IPI中断请求的处理方法，其特征在于，包括：

源虚拟处理器根据信息确定目的虚拟处理器所运行的物理处理器，其中所述信息记录在所述源虚拟处理器可以访问的存储区域内，所述信息中包括指示所述目的虚拟处理器所运行的物理处理器的信息；

所述源虚拟处理器操作中断控制器向所述目的虚拟处理器所运行的所述物理处理器发送IPI中断请求；

其中，所述源虚拟处理器由宿主机配置中断控制器操作模式，使得所述源虚拟处理器可以在不陷出的前提下操作所述中断控制器向所述目的虚拟处理器所运行的所述物理处理器发送所述IPI中断请求。

15.根据权利要求14所述的方法，其特征在于，所述IPI中断请求中携带其他中断请求的标识或者所述IPI中断请求中携带其他中断请求的标识和虚拟处理器的标识，所述方法还包括：

所述目的虚拟处理器确定所述IPI中断请求中没有携带虚拟处理器的标识或确定所述IPI中断请求中携带的所述虚拟处理器的标识与所述目的虚拟处理器的标识一致，则调用所述其他中断请求的标识对应的中断服务程序，以处理所述其他中断请求。

16.根据权利要求14所述的方法，其特征在于，所述IPI中断请求中携带虚拟处理器的标识，所述方法还包括：

所述目的虚拟处理器确定所述IPI中断请求中携带的所述虚拟处理器的标识与所述目的虚拟处理器的标识不一致，则向所述宿主机发送所述虚拟处理器的标识并陷出，以便于所述宿主机将所述虚拟处理器的标识所指示的虚拟处理器换入。

17.根据权利要求14-16任意一项所述的方法，其特征在于，所述源虚拟处理器在确定所述目的虚拟处理器在位时才发送所述IPI中断请求，

其中，所述源虚拟处理器确定所述目的虚拟处理器在位包括：

所述源虚拟处理器查询所述信息以确定所述目的虚拟处理器是否在位，所述信息中还包括指示所述目的虚拟处理器是否在位的信息。

18.一种虚拟化设备，其特征在于，所述虚拟化设备包括源虚拟处理器和目的虚拟处理器，所述源虚拟处理器和所述目的虚拟处理器服务于同一个或不同的虚拟计算机，所述虚拟化设备还包括计算机程序，所述计算机程序的执行促使所述源虚拟处理器和所述目的虚拟处理器实现如权利要求14-17任意一项所述的方法。

Images