Linux中断虚拟化之二

[[437706]]

 PIC虚拟化

计算机系统有很多的外设需要服务，显然，CPU采用轮询的方式逐个询问外设是否需要服务，是非常浪费CPU的计算的，尤其是对那些并不是频繁需要服务的设备。因此，计算机科学家们设计了外设主动向CPU发起服务请求的方式，这种方式就是中断。采用中断方式后，在没有外设请求时，CPU就可以继续其他计算任务，而不是进行很多不必要的轮询，极大地提高了系统的吞吐[1] 在每个指令周期结束后，如果CPU关中断标识(IF)没有被设置，那么其会去检查是否有中断请求，如果有中断请求，则运行对应的中断服务程序，然后返回被中断的计算任务继续执行。

CPU不可能为每个硬件都设计专门的管脚接收中断，管脚数量的限制、电路的复杂度、灵活度等方方面面都不现实，因此，需要设计一个专门管理中断的单元。由中断管理单元接受来自外围设备的请求，确定请求的优先级，并向CPU发出中断。1981年IBM推出的第1代个人电脑PC/XT使用了一个独立的8259A作为中断控制器，自此，8259A就成为了单核时代中断芯片事实上的标准。因为可以通过软件编程对其进行控制，比如当管脚收到设备信号时，可以编程控制其发出的中断向量号，因此，中断控制器又称为可编程中断控制器(programmable interrupt controller)，简称PIC。单片8259A可以连接8个外设的中断信号线，可以多片级联支持更多外设。

8259A和CPU的连接如图5所示。

图5 8259A和CPU连接

片选和地址译码器相连，当CPU准备访问8259A前，需要向地址总线发送8259A对应的地址，经过译码器后，译码器发现是8259A对应的地址，因此会拉低与8259A的CS连接的管脚的电平，从而选中8259A，通知8259A，CPU准备与其交换数据了。

8259A的D0~7管脚与CPU的数据总线相连。从CPU向8259A发送ICW和OCW，从8259A向CPU传送8259A的状态以及中断向量号，都是通过数据总线传递的。

当CPU向8259A发送ICW、OCW时，当把数据送上数据总线后，需要通知8259A读数据，CPU通过拉低WR管脚的电平的方式通知8259A，当8259A的WR管脚收到低电平后，读取数据总线的数据。类似的，CPU准备好读取8259A的状态时，拉低RD管脚通知8259A。

8259A和CPU之间的中断信号的通知使用专用的连线，8259A的管脚INTR(interrupt request)和INTA(interrupt acknowledge)分别与处理器的INTR和INTA管脚相连。8259A通过管脚INTR向CPU发送中断请求，CPU通过管脚INTA向PIC发送中断确认，告诉PIC其收到中断并且开始处理了。8259A与CPU之间的具体中断过程如下：

1)8259A的IR0~7管脚高电平有效，所以当中断源请求服务时，拉高连接IR0~7的管脚，产生中断请求。

2)8259A需要将这些信号记录下来，因此其内部有个寄存器IRR(Interrupt Request Register)，负责记录这个中断请求，针对这个例子，IRR的bit 0将被设置为1。

3)有的时候，我们会屏蔽掉某个设备的中断。换句话说，就是的当这个中断源向8259A发送信号后，8259A并不将这个中断信号发送给CPU。读者不要将屏蔽和CPU通过cli命令关中断混淆，CPU关中断时，中断还会发送给CPU，只是在关中断期间CPU不处理中断。8259A中的寄存器IMR(Interrupt Mask Register)负责记录某个中断源是否被屏蔽，比如0号中断源被设备了屏蔽，那么IMR的bit 0将被设置。那么这个IMR是谁设置的呢?当然是CPU中的操作系统。因此这一步，8259A将会检查收到的中断请求是否被屏蔽。

4)在某一个时刻，可能有多个中断请求，或者是之前存在IRR中的中断并没有被处理，8259A中积累了一些中断。某一个时刻，8259A只能向CPU发送一个中断请求，因此，当存在多个中断请求时，8259A需要判断一下中断优先级，这个单元叫做priority resolver，priority resolver将在IRR中选出优先级最高的中断。

5)选出最高优先级的中断后，8259A拉高管脚INTR的电平，向CPU发出信号。

6)当CPU执行完当前指令周期后，其将检查寄存器FLAGS的中断使能位IF(Interrupt enable flag)，如果允许中断，那么将检查INTR是否有中断，如果有中断，那么将通过管脚INTR通知8259A处理器将开始处理中断。

7)8259A收到CPU发来的INTA信号后，将置位最高优先级的中断在ISR(In-Service Register)中对应的位，并清空IRR中对应的位。

8)通常，x86 CPU会发送第2次INTA，在收到第2次INTA后，8259A会将中断向量号(vector)送上数据总线D0~D7。

9)如果8259A设置为AEOI(Automatic End Of Interrupt)模式，那么8259A复位ISR中对应的bit，否则ISR中对应的bit一直保持到收到系统的中断服务程序发来的EOI命令。

我们知道，中断服务程序保存在一个数组中，数组中的每一项对应一个中断服务程序。在实模式下，这个数组称为IVT(interrupt vector table);在保护模式下，这个数组称为IDT(Interrupt descriptor table)。

这个数组中保存的服务程序，并不是全部都是外部中断，还有处理CPU内部异常的以及软中断服务程序。x86CPU前32个中断号(0-31)留给处理器异常的，比如第0个中断号，是处理器出现除0(Divide by Zero)异常的，不能被占用。因此，假设我们计划IVT数组中第32个元素存放管脚IR0对应的ISR，那么我们初始化8259A时，通过ICW，设置起始的irq base为32，那么当8259A发出管脚IR0的中断请求时，则发出的值是32，管脚IR1对应的是33，依此类推。这个32、33就是所谓的中断向量(vector)。换句话说，中断向量就是中断服务程序在IVT/IDT中的索引。下面就是设置irq_base的代码，在初始化时，通过第2个初始化命令字(ICW2)设置：

commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/i8259.c 
static void pic_ioport_write(void *opaque, u32addr, u32 val) 
{ 
  … 
    switch(s->init_state) { 
    … 
    case 1: 
      s->irq_base = val & 0xf8; 
    … 
    } 
} 

后来，随着APIC和MSI的出现，中断向量设置的更为灵活，可以为每个PCI设置其中断向量，这个中断向量存储在PCI设备的配置空间中。

内核中抽象了一个结构体kvm_kpic_state来记录每个8259A的状态：

commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
struct kvm_kpic_state { 
  u8last_irr;  /* edge detection */ 
  u8 irr;  /* interrupt request register */ 
  u8imr;   /* interrupt mask register */ 
  u8isr;   /* interrupt service register */ 
  … 
}; 
  
struct kvm_pic { 
  structkvm_kpic_state pics[2]; /* 0 is master pic, 1 is slave pic*/ 
 irq_request_func *irq_request; 
  void*irq_request_opaque; 
  intoutput;   /* intr from master PIC */ 
  structkvm_io_device dev; 
}; 

1片8259A只能连接最多8个外设，如果需要支持更多外设，需要多片8259A级联。在结构体kvm_pic中，我们看到有2片8259A：pic[0]和pic[1]。KVM定义了结构体kvm_kpic_state记录8259A的状态，其中包括我们之前提到的IRR、IMR、ISR等等。

1 虚拟设备向PIC发送中断请求

如同物理外设请求中断时拉高与8259A连接的管脚的电压，虚拟设备请求中断的方式是通过一个API告诉虚拟的8259A芯片中断请求，以kvmtool中的virtio blk虚拟设备为例：

commit 4155ba8cda055b7831489e4c4a412b073493115b 
kvm: Fix virtio block device support some more 
kvmtool.git/blk-virtio.c 
static bool blk_virtio_out(…) 
{ 
  … 
  caseVIRTIO_PCI_QUEUE_NOTIFY: { 
    … 
    while(queue->vring.avail->idx != queue->last_avail_idx) { 
      if(!blk_virtio_read(self, queue)) 
       return false; 
    } 
   kvm__irq_line(self, VIRTIO_BLK_IRQ, 1); 
  
    break; 
  } 
  … 
} 

当Guest内核的块设备驱动发出I/O通知VIRTIO_PCI_QUEUE_NOTIFY时，将触发CPU从Guest模式切换到Host模式，KVM中的块模拟设备开始I/O操作，比如访问保存Guest文件系统的镜像文件。virtio blk这个提交，块设备的I/O处理是同步的，也就是说，一直要等到文件操作完成，才会向Guest发送中断，返回Guest。当然同步阻塞在这里是不合理的，而是应该马上返回Guest，这样Guest可以执行其他的任务，虚拟设备完成I/O操作后，再通知Guest，这是kvmtool初期的实现，后来已经改进为异步的方式。代码中在一个while循环处理完设备驱动的I/O请求后，调用了函数kvm__irq_line，irq_line对应8259A的管脚IR0~7，其代码如下：

commit 4155ba8cda055b7831489e4c4a412b073493115b 
kvm: Fix virtio block device support some more 
kvmtool.git/kvm.c 
void kvm__irq_line(struct kvm *self, int irq, intlevel) 
{ 
  structkvm_irq_level irq_level; 
  
  irq_level= (struct kvm_irq_level) { 
    { 
     .irq    = irq, 
    }, 
   .level    = level, 
  }; 
  
  if(ioctl(self->vm_fd, KVM_IRQ_LINE, &irq_level) < 0) 
   die_perror("KVM_IRQ_LINE failed"); 
} 
函数kvm__irq_line将irq number和管脚电平信息，这里是1，表示拉高电平了，封装到结构体kvm_irq_level中，传递给内核中的KVM模块： 
commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/kvm_main.c 
static long kvm_vm_ioctl(…) 
{ 
  … 
  caseKVM_IRQ_LINE: { 
    … 
        kvm_pic_set_irq(pic_irqchip(kvm), 
         irq_event.irq, 
         irq_event.level); 
    … 
    break; 
  } 
  … 
} 

KVM模块将kvmtool中组织的中断信息从用户空间复制到内核空间中，然后调用虚拟8259A的模块中提供的API kvm_pic_set_irq，向8259A发出中断请求。

2 记录中断到IRR

中断处理需要一个过程，从外设发出请求，一直到ISR处理完成发出EOI。而且可能中断来了并不能马上处理，或者之前已经累加了一些中断，大家需要排队依次请求CPU处理，等等，因此，需要一些寄存器来记录这些状态。当外设中断请求到来时，8259A首先需要将他们记录下来，这个寄存器就是IRR(Interrupt Request Register)，8259A用他来记录有哪些pending的中断需要处理。

当KVM模块收到外设的请求，调用虚拟8259A的API kvm_pic_set_irq是，其第1件事就是将中断记录到IRR寄存器中：

commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/i8259.c 
void kvm_pic_set_irq(void *opaque, int irq, intlevel) 
{ 
  structkvm_pic *s = opaque; 
  
 pic_set_irq1(&s->pics[irq >> 3], irq & 7, level); 
  …… 
} 
  
static inline void pic_set_irq1(structkvm_kpic_state *s, 
int irq, int level) 
{ 
  int mask; 
  mask = 1<< irq; 
  if(s->elcr & mask) /* level triggered */ 
    … 
  else  /* edge triggered */ 
    if(level) { 
      if((s->last_irr & mask) == 0) 
       s->irr |= mask; 
     s->last_irr |= mask; 
    } else 
     s->last_irr &= ~mask; 
} 

信号有边缘触发和水平触发，在物理上可以理解为，8329A在前一个周期检测到管脚信号是0，当前周前检测到管脚信号是1，如果是上升沿触发模式，那么8259A就认为外设有请求了，这种触发模式就是边缘触发。对于水平触发，以高电平触发为例，当8259A检测到管脚处于高电平，则认为外设来请求了。

在虚拟8259A的结构体kvm_kpic_state中，寄存器elcr就是用来记录8259A被设置的触发模式的。参数level即相当于硬件层面的电信号，0表示低电平，1表示高电平。以边缘触发为例，当管脚收到一个低电平时，即level的值为0，代码进入else分支，结构体kvm_kpic_state中的字段last_irr中会清除该IRQ对应IRR的位，即相当于设置该中断管脚为低电平状态。当管脚收到高电平时，即level的值为1，代码进入if分支，此时8259A将判断之前该管脚的状态，也就是判断结构体kvm_kpic_state中的字段last_irr中该IRQ对应IRR的位，如果为低电平，那么则认为中断源有中断请求，将其记录到IRR中。当然，同时需要在字段last_irr记录下当前该管脚的状态。

3 设置中断标识

当8259A将中断请求记录到IRR中后，下一步就是开启一个中断评估(evaluate)过程了，包括中断是否被屏蔽，多个中断请求的优先级等等，最后将通过管脚INTA通知CPU处理外部中断。我们看到这里是8259A主动发起中断过程，但是虚拟中断有些不同，中断的发起的时机不再是虚拟中断芯片主动发起，而是在每次准备切入Guest时，KVM查询中断芯片，如果有pending的中断，则执行中断注入。模拟8259A在收到中断请求后，在记录到IRR后，设置一个变量，后面在切入Guest前KVM会查询这个变量：

commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/i8259.c 
void kvm_pic_set_irq(void *opaque, int irq, intlevel) 
{ 
  structkvm_pic *s = opaque; 
  
 pic_set_irq1(&s->pics[irq >> 3], irq & 7, level); 
 pic_update_irq(s); 
} 
  
static void pic_update_irq(struct kvm_pic *s) 
{ 
  … 
  irq =pic_get_irq(&s->pics[0]); 
  if (irq>= 0) 
   s->irq_request(s->irq_request_opaque, 1); 
  else 
   s->irq_request(s->irq_request_opaque, 0); 
} 
  
static void pic_irq_request(void *opaque, intlevel) 
{ 
  struct kvm*kvm = opaque; 
  
 pic_irqchip(kvm)->output = level; 
} 

在函数vmx_vcpu_run中，在准备切入Guest之前将调用函数vmx_intr_assist去检查虚拟中断芯片是否有等待处理的中断，相关代码如下：

commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/vmx.c 
static int vmx_vcpu_run(…) 
{ 
  … 
   vmx_intr_assist(vcpu); 
  … 
} 
  
static void vmx_intr_assist(struct kvm_vcpu*vcpu) 
{ 
  … 
  has_ext_irq= kvm_cpu_has_interrupt(vcpu); 
  … 
  if(!has_ext_irq) 
    return; 
 interrupt_window_open = 
   ((vmcs_readl(GUEST_RFLAGS) & X86_EFLAGS_IF) && 
    (vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) & 3) == 0); 
  if(interrupt_window_open) 
   vmx_inject_irq(vcpu, kvm_cpu_get_interrupt(vcpu)); 
  … 
} 

其中函数kvm_cpu_has_interrupt查询8259A设置的变量output:

commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/irq.c 
int kvm_cpu_has_interrupt(struct kvm_vcpu *v) 
{ 
  structkvm_pic *s = pic_irqchip(v->kvm); 
  
  if(s->output)  /* PIC */ 
    return1; 
  return 0; 
} 

如果有output设置了，就说明有外部中断等待处理，然后接着判断Guest是否可以被中断，包括Guest是否中断了，Guest是否正在执行一些不能被中断的指令，如果可以注入，则调用vmx_inject_irq完成中断的注入。其中，传递给函数vmx_inject_irq的第2个参数是函数kvm_cpu_get_interrupt返回的结果，该函数获取需要注入的中断，这个过程就是中断评估过程，我们下一节讨论。

4 中断评估

在上一节我们看到在执行注入前，vmx_inject_irq调用函数kvm_cpu_get_interrupt获取需要注入的中断。函数kvm_cpu_get_interrupt的核心逻辑就是中断评估(evaluate)，包括：这个pending的中断有没有被屏蔽?pending的中断的优先级是否比CPU正在处理的中断优先级高?代码如下：

commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/irq.c 
int kvm_cpu_get_interrupt(struct kvm_vcpu *v) 
{ 
  …… 
  vector =kvm_pic_read_irq(s); 
  if (vector!= -1) 
    returnvector; 
  … 
} 
  
linux.git/drivers/kvm/i8259.c 
int kvm_pic_read_irq(struct kvm_pic *s) 
{ 
  int irq,irq2, intno; 
  
  irq =pic_get_irq(&s->pics[0]); 
  if (irq>= 0) { 
    … 
      intno = s->pics[0].irq_base + irq; 
  } else { 
  … 
  returnintno; 
} 

kvm_pic_read_irq调用函数pic_get_irq获取评估后的中断，如上面黑体标识的，我们可以清楚的看到中断向量和中断管脚的关系，叠加了一个irq_base，这个irq_base就是通过初始化8259A时通过ICW设置的，完成从IRn到中断向量的转换。

一个中断芯片通常连接有多个外设，所以在某一个时刻，可能会有多个设备请求到来，这时就有一个优先处理哪个请求的问题，因此，中断就有了优先级的概念。以8259A为例，典型的有2种中断优先级模式：

1)固定优先级(Fixedpriority)，即优先级是固定的，从IR0到IR7依次降低，IR0的优先级永远最高，IR7的优先级永远最低。

2)循环优先级(rotatingpriority)，即当前处理完的IRn其优先级调整为最低，当前处理的优先级下个，即IRn+1，调整为优先级最高。比如，当前处理的中断是irq 2,那么紧接着irq3的优先级设置为是最高，然后依次是irq4、irq5、irq6、irq7、irq1、irq2、irq3。假设此时irq5和irq2同时来了中断，那么irq5显然会被优先处理。然后irq6被设置为优先级最高，接下来依次是irq7、irq1、irq2、irq3、irq4、irq5。

理解了循环优先级算法后，从8259A中获取最高优先级请求的代码就很容易理解了：

commit85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/i8259.c 
static int pic_get_irq(struct kvm_kpic_state *s) 
{ 
  int mask,cur_priority, priority; 
  
  mask =s->irr & ~s->imr; 
  priority =get_priority(s, mask); 
  if(priority == 8) 
    return-1; 
  … 
  mask =s->isr; 
  … 
 cur_priority = get_priority(s, mask); 
  if(priority < cur_priority) 
    /* 
     *higher priority found: an irq should be generated 
     */ 
    return(priority + s->priority_add) & 7; 
  else 
    return-1; 
} 
  
static inline int get_priority(structkvm_kpic_state *s, int mask) 
{ 
  intpriority; 
  if (mask== 0) 
    return8; 
  priority =0; 
  while((mask & (1 << ((priority + s->priority_add) & 7))) == 0) 
   priority++; 
  returnpriority; 
} 

函数pic_get_irq分成2部分，第1部分是从当前pending的中断中取得最高优先级的中断，当前之前需要滤掉被被屏蔽的中断。第2部分是获取正在被CPU处理的中断的优先级的中断的优先级，通过这里，读者更能具体的理解了8259A为什么需要这些寄存器记录中断的状态。然后比较2个中断的优先级，如果pending的优先级高，那么就通过拉低INTR管脚电压，向CPU发出中断请求。

再来看一下计算优先级的函数get_priority。其中变量priority_add记录的是当前最高优先级的管脚，所以逻辑上就是从当前最高的优先级管脚开始，从高向低依次检查是否有pending的中断。比如当前IR4最高，那么priority_add的值就是4。while循环，从管脚IR(4+0)开始，依次检查管脚IR(4+1)、IR(4+2)，依此类推。

5 中断ACK

在物理上，CPU在准备处理一个中断请求后，将通过管脚INTA向8259A发出确认脉冲。同样，软件模拟上，也需要类似处理。在完成中断评估后，准备注入Guest前，需要向虚拟8259A执行确认状态的操作，代码如下：

commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/i8259.c 
int kvm_pic_read_irq(struct kvm_pic *s) 
{ 
  int irq,irq2, intno; 
  
  irq =pic_get_irq(&s->pics[0]); 
  if (irq>= 0) { 
   pic_intack(&s->pics[0], irq); 
  … 
} 
  
static inline void pic_intack(structkvm_kpic_state *s, int irq) 
{ 
  if(s->auto_eoi) { 
    … 
  } else 
   s->isr |= (1 << irq); 
  /* 
   * Wedon't clear a level sensitive interrupt here 
   */ 
  if(!(s->elcr & (1 << irq))) 
   s->irr &= ~(1 << irq); 
} 

在中断评估中，在调用函数kvm_pic_read_irq获取评估的中断结果后，马上就调用函数pic_intack完成了中断确认的动作。在收到CPU发来的中断确认后，8259A需要更新自己的状态，包括，因为中断已经开始得到服务了，所以从IRR中清除等待服务请求。另外，需要设置ISR位，记录正在被服务的中断，但是这里稍微有一点点复杂。

设置ISR表示正在服务的位，表示处理器正在处理中断。设置ISR的一个典型作用是中断的作用是当ISR处理完中断，向8259A发送EOI时，8259A知道正在处理的IRn，比如说如果8259A使用的是循环优先级，那么需要最高优先级为当前处理的IRn的下一个。

如果8259A是AEOI模式，那么就无须设置ISR了，因为中断服务程序执行完毕后不会发送EOI命令。所以在AEOI模式下(上面代码的if分支)，需要将收到EOI时8259A需要处理的逻辑完成，这部分内容我们在下一节会讨论。

对于边缘触发的，进入到ISR阶段后，需要复位对于IRR。对于level trigger的，在收到中断请求后8259A处理，不过多讨论了，如果读者有兴趣，可以阅读函数pic_set_irq1中关于水平触发部分的逻辑。

6 关于EOI的处理

中断服务程序执行完成后，会向8259A发送EOI，告知8259A中断处理完成。8259A在收到这个EOI时，复位ISR，如果是采用的循环优先级，还需要设置变量priority_add，使其指向当前处理IRn的下一个：

commit85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/i8259.c 
static void pic_ioport_write(void *opaque, u32addr, u32 val) 
{ 
  … 
      case1: /* end of interrupt */ 
      case5: 
       priority = get_priority(s, s->isr); 
        if(priority != 8) { 
         irq = (priority + s->priority_add) & 7; 
         s->isr &= ~(1 << irq); 
          if(cmd == 5) 
           s->priority_add = (irq + 1) & 7; 
         pic_update_irq(s->pics_state); 
        } 
       break; 
  … 
} 

如果8259A被设置为AEOI模式，不会再收到后续中断服务程序的EOI命令，那么8259A在收到CPU的ACK后，就必须把收到EOI命令时执行的逻辑现在处理，前面看到AEOI模式不必设置ISR,所以这里也无需复位ISR，只需要调整变量priority_add，记录最高优先级位置即可：

commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
static inline void pic_intack(structkvm_kpic_state *s, int irq) 
{ 
  if(s->auto_eoi) { 
    if(s->rotate_on_auto_eoi) 
     s->priority_add = (irq + 1) & 7;    
  } else 
  … 
} 

7 中断注入

对于外部中断，每个CPU在指令周期结束后，将会去检查INTR是否有中断请求。那么对于处于Guest模式的CPU，其如何知道有中断请求呢?Intel在VMCS中设置了一个字段：VM-entry interruption-information，在VM entry时CPU将会检查这个字段，这个字段格式表3-1所示。

表3-1 VM-entry interruption-information格式(部分)

位	内容
7:0	中断或异常向量
10:8	中断类型: 0: External  interrupt 1: Reserved 2: Non-maskable  interrupt (NMI) 3: Hardware  exception 4: Software  interrupt 5: Privileged  software exception 6: Software  exception 7: Other event
31	是否有效[2]

在VM entry前，KVM模块检查虚拟8259A中如果有pending中断需要处理，则将需要处理的中断信息写入到VMCS中的这个字段VM-entry 

interruption-information: 
commit 85f455f7ddbed403b34b4d54b1eaf0e14126a126 
KVM: Add support for in-kernel PIC emulation 
linux.git/drivers/kvm/vmx.c 
static void vmx_inject_irq(struct kvm_vcpu *vcpu,int irq) 
{ 
  … 
 vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, 
      irq |INTR_TYPE_EXT_INTR | INTR_INFO_VALID_MASK); 
} 

前面我们看到，中断注入是在每次VM entry时，KVM模块检查8259A是否有pending的中断等待处理。这样就有可能给中断带来一定的延迟，典型如下面2类情况：

(1)CPU可能正处在Guest模式，那么就需要等待下一次VM exit 和VM entry。

(2)VCPU这个线程也许正在睡眠，比如Guest VCPU运行hlt指令时，就会切换回Host模式，线程挂起。

对于第1种情况，是多处理器系统下的一个典型情况，目标CPU的正在运行Guest。KVM需要想办法触发Guest发生一次VM exit，切换到Host。我们知道，当处于Guest模式的CPU收到外部中断时，会触发VM exit，由Host来处理这次中断。所以，KVM可以向目标CPU发送一个IPI中断，触发目标CPU发生一次VM exit。

对于第2种情况，首先需要唤醒睡眠的VCPU线程，使其进入CPU就绪队列，准备接受调度。对于多处理器系统，然后再向目标CPU发送一个“重新调度”的IPI中断，那么被唤醒的VCPU线程很快就会被调度，执行切入Guest的过程，从而完成中断注入。

所以当有中断请求时，虚拟中断芯片将主动“kick”一下目标CPU，这个“踢”的函数就是kvm_vcpu_kick：

commit b6958ce44a11a9e9425d2b67a653b1ca2a27796f 
KVM: Emulate hlt in the kernel 
linux.git/drivers/kvm/i8259.c 
static void pic_irq_request(void *opaque, intlevel) 
{ 
  … 
 pic_irqchip(kvm)->output = level; 
  if (vcpu) 
   kvm_vcpu_kick(vcpu); 
} 

如果虚拟CPU线程在睡眠，则“踢醒”他。如果目标CPU运行在Guest模式，则将其从Guest模式“踢”到Host模式，在VM entry时完成中断注入，kick的手段就是我们刚刚提到的IPI，代码如下：

commit b6958ce44a11a9e9425d2b67a653b1ca2a27796f 
KVM: Emulate hlt in the kernel 
linux.git/drivers/kvm/irq.c 
void kvm_vcpu_kick(struct kvm_vcpu *vcpu) 
{ 
  intipi_pcpu = vcpu->cpu; 
  
  if(waitqueue_active(&vcpu->wq)) { 
   wake_up_interruptible(&vcpu->wq); 
   ++vcpu->stat.halt_wakeup; 
  } 
  if(vcpu->guest_mode) 
   smp_call_function_single(ipi_pcpu, vcpu_kick_intr, 
vcpu, 0, 0); 
} 

如果VCPU线程睡眠在等待队列上，则唤醒使其进入CPU的就绪任务队列。如果是多CPU的情况且目标CPU处于Guest模式，则需要发送核间中断。如果目标CPU正在执行Guest，那么这个IPI中断将导致VM exit，从而在下一次进入Guest时，可以注入中断。

事实上，目标CPU无须执行任何callback,也无须等待IPI返回，所以也无须使用smp_call_function_single，而是直接发送一个请求目标CPU重新调度的IPI即可，因此后来直接调用了函数smp_send_reschedule。函数smp_send_reschedule简单直接，直接发送了一个RESCHEDULE的IPI：

commit 32f8840064d88cc3f6e85203aec7b6b57bebcb97 
KVM: use smp_send_reschedule in kvm_vcpu_kick 
linux.git/arch/x86/kvm/x86.c 
void kvm_vcpu_kick(struct kvm_vcpu *vcpu) 
{ 
  … 
     smp_send_reschedule(cpu); 
  … 
} 
  
linux.git/arch/x86/kernel/smp.c 
static void native_smp_send_reschedule(int cpu) 
{ 
  … 
 apic->send_IPI_mask(cpumask_of(cpu), RESCHEDULE_VECTOR); 
} 

本文转载自微信公众号「Linux阅码场」，可以通过以下二维码关注。转载本文请联系Linux阅码场公众号。