Interrupt in Linux（硬件篇）—— APIC2

1.2.2 LAPIC
收到来自IOAPIC的中断消息后，LAPIC会将该中断交由CPU处理。和IOAPIC比较，LAPIC具有更多的寄存器以及更复杂的机制。但对于处理来自IOAPIC的中断消息，最重要的寄存器还是IRR、ISR以及EOI。
图1-4显示了x86平台上，IRR和ISR的格式：
 
图1-4 IRR、ISR构成
与PIC中的IRR、ISR不同的是，LAPIC的ISR、IRR均为256bit寄存器，对应x86平台上的256个中断vector，其中0~15为架构预留。
u       IRR：功能和PIC的类似，代表LAPIC已接收中断，但还未交CPU处理。
u       ISR：功能和PIC类似，代表CPU已开始处理中断，但还未完成。与PIC有所不同的是，当CPU正在处理某中断时，同类型中断如果发生，相应的IRR bit会再次置一（PIC模式下，同类型的中断被屏蔽）；如果某中断被pending在IRR中，同类型的中断发生，则ISR中相应的bit被置一。这说明在APIC系统中，同一类型中断最多可以被计数两次（想不通什么意思？想不通就联想一下Linux可信信号）。超过两次时，不同架构处理不一样。对于Pentium系列CPU和P6架构，中断消息被LAPIC拒绝；对于Pentium4和Xeon系列，新来的中断和IRR中对应的bit重叠。
笔者：上图还有个TMR寄存器，即Trigger Mode Register，用于表示当前正在处理中断的触发模式。1为level，0为edge。对于level触发的中断，当软件写EOI时，会被广播到所有IOAPIC，消息中含有中断的vector，IOAPIC收到后检查自己的PRT表，把相应RTE的Remote IRR位清零。
对于IRR，x86 spec说：“当CPU准备处理中断时，IRR中最高优先级的bit被清零，ISR中对应bit被置一”。这样说不能算错，但至少不准确。根据《Multi-Processor Computer System With Interrupt Controllers Providing Remote Reading》一文中APIC的实现，只有对于edge触发的中断，ISR对应bit置一时IRR相应 bit才清零。对于level触发，IRR中的bit保留到软件写EOI，LAPIC收到IOAPIC发出的Level-deassert消息后才清零。
如果你仔细看了前面关于Remote IRR的介绍，此时一定会产生一个疑问。这里说同类型中断发生两次，会同时Pending在ISR和IRR的对应bit中。问题是，前面Remote IRR的异或逻辑保证了在写EOI前，新的中断不会发过来啊？呵呵，或许你想到答案了，这种pending两次的机制，只对edge触发中断有效。
与PIC一样，LAPIC同样需要软件写EOI来知会中断处理的完成，不同的是，LAPIC中的EOI是一个32bit寄