对中断的一点思考

对中断的一点思考

杨小华（normalnotebook@126.com）

    对于X86的单处理器机器，一般采用可编程中断控制器8259A做为中断控制电路。传统的PIC（Programmable Interrupt Controller）是由两片8259A风格的外部芯片以“级联”的方式连接在一起。每个芯片可处理多达8个不同的IRQ输入线。因为从PIC的INT输出线连接到主PIC的IRQ2引脚，所以可用IRQ线的个数限制为15，如图1所示。

图 1  8259A级联原理图（此图摘自《Linux内核完全注释》）

    “中断屏蔽寄存器”（Interrupt Mask Register，简称IMR）用于屏蔽8259A的中断信号输入，每一位对应一个输入。当IMR中的bit[i](0≤i≤7)位被置1时，相对应的中断信号输入线IRi上的中断信号将被8259A所屏蔽，也即IRi被禁止。     当外设产生中断信号时（由低到高的跳变信号，80x86系统中的8259A是边缘触发的，Edge Triggered），中断信号被输入到“中断请求寄存器”（Interrupt Request Register，简称IRR），并同时看看IMR中的相应位是否已被设置。如果没有被设置，则IRR中的相应位被设置为1，表示外设产生一个中断请求，等待CPU服务。 然后，8259A的优先级仲裁部分从IRR中选出一个优先级最高中断请求。优先级仲裁之后，8259A就通过其INT引脚向CPU发出中断信号，以通知CPU有外设请求中断服务。CPU在其当前指令执行完后就通过他的INTA引脚给8259A发出中断应答信号，以告诉8259A，CPU已经检测到有中断信号产生。     8259A在收到CPU的INTA信号后，将优先级最高的那个中断请求在ISR寄存器（In－Service Register，简称ISR）中对应的bit置1，表示该中断请求已得到CPU的服务，同时IRR寄存器中的相应位被清零重置。     然后，CPU再向8259A发出一个INTA脉冲信号，8259A在收到CPU的第二个INTA信号后，将中断请求对应的中断向量放到数据总线上，以供CPU读取。CPU读到中断向量后，就可以装入执行相应的中断处理程序。     如果8259A工作在AEOI（Auto End Of Interrupt，简称AEOI）模式下，则当他收到CPU的第二个INTA信号时，它就自动重置ISR寄存器中的相应位。否则，ISR寄存器中的相应位就一直保持为1，直到8259A显示地收到来自于CPU的EOI命令。 打住，各位看官读到这里，能回答如下问题吗？ 1．    在执行中断处理程序时，中断一直是关闭着的吗？ 2．    在执行中断处理程序时，本条中断线上的中断是否会被屏蔽？ 3．    如果该条中断线被屏蔽了，那么是否一直要到该中断返回（即执行iter指令）时才开启？ 4．    禁止中断后，异常还会执行吗？timer还会被执行吗？     如果不能回答这些问题，请继续欣赏。如果你能回答，请关闭本文档，努力工作吧，或拿起一本英语书看看，这年头不好混，多看看英语吧 ！:）     当中断发生，CPU在穿越中断门时会关闭本处理器上所有的中断。此时中断执行路线是：common_interrupt->do_IRQ()->__do_IRQ()->handle_IRQ_event()->具体的中断处理程序。大家都知道中断类型包括三种：

表 1中断类型标志位及其含义表

    如果相应的中断处理程序在注册时，即调用request_irq（）函数进行中断处理程序注册时，会传递这三种中类型中的一个或数个。如果没有指定SA_INTERRUPT该类型。则在handle_IRQ_event（）函数中会第一次开中断；如果指定了该参数，则会在关闭中断的情况下执行中断处理程序。 fastcall int handle_IRQ_event(unsigned int irq, struct pt_regs *regs,                 struct irqaction *action) {     int ret, retval = 0, status = 0;     if (!(action->flags & SA_INTERRUPT))         local_irq_enable();    ……//调用中断处理程序        local_irq_disable();     return retval; }     如果此时开中断了，本条IRQ线上的中断也打开了吗？我要告诉你的是，在执行到这里的时候，本条线上的中断已经被屏蔽了，但也不是问题3中所说的一直到iret时才打开。 fastcall unsigned int __do_IRQ(unsigned int irq, struct pt_regs *regs) {     irq_desc_t *desc = irq_desc + irq;     ……     desc->handler->ack(irq);     ……     action_ret = handle_IRQ_event(irq, regs, desc->action);     ……     desc->handler->end(irq);     …… } desc->handler->ack(irq);最终会调用mask_and_ack_8259A()(为什么会调用该函数，请查看源代码或相关书籍)。mask_and_ack_8259A的功能是：因为中断处理器在将中断请求“上报”到CPU后，期待CPU给它一个确认（ACK），也就是给8259A芯片一个应答信号，表示“我已经在处理”，应答时应该遵循这样的顺序：首先，屏蔽相应的IRQ；然后，发送EOI（End of Interrupt）命令。此外，如果IRQ来自于从8259A，还必须先向从 8259A发送EOI命令，再向主8259A发送EOI命令。如果IRQ来自于主 8259A，则仅仅向主8259A发送EOI命令就可以了。当一个中断服务结束后，CPU可利用中断结束命令EOI通知8259A，以便复位ISR中的相应位。因此当调用handle_IRQ_event（）时，即使开中断，该条中断线的中断也是关闭的。一直到调用desc->handler->end(irq);时才清除中断屏蔽。     细心的读者可能还有一个问题，为什么在handle_IRQ_event（）返回时，还要关闭本地所有的中断(即代码中的local_irq_disable();)。因为在中断返回时，将会进行退栈清理性的工作，如果此时响应中断，鬼知道后果是什么？嘿嘿， Linus Torvalds肯定知道结果。因为他比鬼还厉害 :）     虽然，中断关闭了，但异常并没有关闭。关中断只是关掉了外部中断，cli只是设置EFLAGS寄存器的IF位，如果该位被清除，则表示CPU会禁止外部中断传递信号给INTR引脚，但对于CPU内部异常和不可屏蔽中断（NMI）并不起作用。由于timer是外部中断，所以在禁中断后，timer中断将不在起作用，一直到开中断。 1.    如果在desc->handler->ack(irq);和desc->handler->end(irq);之间，该条中断线上再次发生中断，该中断是否会被丢失？ 2.    在中断处理快结束时，会执行软中断。可在执行do_softirq()时，又会执行 if (in_interrupt())         return;     难道软中断不在中断中吗？岂不是执行到这里都返回了？ 如果你又知道这些问题的答案，那我只能自认倒霉了，难道你就是传说中的hacker!!!:). 对于第一个问题，我也不能给出明确的答案。我只是把所收集的资料写出来。至于对不对，有大家自己去判断。 中断不会丢失，会被挂起（pending），保存在IPR（Interrupt Pending Register）中，等到中断允许位打开后再执行相应的中断处理程序。（但我查了8259A的寄存器，好像没有这个寄存器。）     在《源代码情景分析》一书中p216第10行提到：“这样，就把本来可能发生在同一通道（甚至可能来自同一中断源）的中断嵌套化解为一个循环”。本人认为这种嵌套仅仅针对的是SMP的情况。因为对单CPU来说，ack操作已经将本条中断线给屏蔽了，根本不可能再响应了。     如果哪位这里有比较好的权威性的答案，请记得发封邮件给我，先谢过了。     在do_IRQ()中，将会调用irq_enter（）()和irq_exit（）两个函数。 fastcall unsigned int do_IRQ(struct pt_regs *regs) {        ……     irq_enter();     ……     __do_IRQ(irq, regs);     ……     irq_exit();     …… }     在执行irq_enter（）时，将会调用(preempt_count() += HARDIRQ_OFFSET)；在执行irq_exit（）函数时，又会： void irq_exit(void) {     preempt_count()-= IRQ_EXIT_OFFSET;// # define IRQ_EXIT_OFFSET  HARDIRQ_OFFSET     if (!in_interrupt() && local_softirq_pending())         do_softirq();     preempt_enable_no_resched(); }     而in_interrupt()函数只是对preempt_count的某些位进行测试。所以在执行do_softirq（）时，preempt_count经过一次加减运算后，将值还原了。所以只要不是中断嵌套的话，in_interrupt()会为假。所以执行到这里时，根本不会返回，除非中断嵌套。     我们也该休息一下了，广告之后马上回来，进入下一个环节－－有关调度的问题。     我曾经在一个培训资料上看到如下的结论： 实时应用中，中断的发生不但要求迅速的中断服务，还要求迅速的调度有关的进程进入运行，在用户空间中对事件处理。 可是，如果这样的中断发生在内核时，本次中断返回是不会引起调度的，而要到最初使CPU从用户空间进入内核的那次系统调用或中断（或异常）返回时才会发生调度。倘若内核中的这段代码恰好需要较长时间来完成的话，或者连续又发生几次中断的话，就可能将调度过分的推迟。     当中断发生在内核时，本次中断返回时是有可能引起调度的，原因是，只要need_resched被置位并且preempt_count＝0，如果这这两个条件都满足，那么就会发生schedule（）操作， 我认为写这段话的作者，当时可能研究的是2.4的内核，因为那时的内核是不可抢占的。当返回到用户态时，只需要对need_resched进行检查。     另外一个问题：     当idle运行时，发生外部中断A，中断处理程序A将一个进程P1唤醒，并设置了调度标志need_resched，在中断处理程序A还没有结束前，又有一高优先级的外部中断B发生，响应B，当中断处理程序B结束后，内核进行调度，选择中断A所唤醒的进程P1运行，此后，产生许多可运行的进程，致使idle不能很快再运行。这不就存在着很大的问题，甚者会导致该条线上的中断永远都不能响应。     的确不错，当调用wake_up_process（）时，如果被唤醒进程的优先级比当前进程的优先级高，那么将设置need_resched位。但这个问题忽略了一个很重要的问题，那就是中断B返回时，当返回内核态时（我想不可能返回到用户态吧），将会对need_resched和preempt_count进行检查，如果这两者都满足，才会进行调度。从上面分析可知，当发生中断嵌套时，preempt_count此时等于一个很大的值，虽然B在执行时，preempt_count经过一次加和减的操作，但A还是将该值设置成禁止抢占的，所以中断B返回时，根本不可能发生调度，而是会执行中断上下文A。 说明：有些结论来自论坛上网友的回答，向他们表示感谢。 友情鸣谢： [1] www.linuxforum.net [2] Daniel P.Bovel & Marco Cesati 《深入理解Linux内核》 中国电力出版社，2004 [3] 毛德操，胡希明  《Linux内核源代码情景分析》 浙江大学出版社，2001 [4] Robert Love 《Linux内核设计与实现》 机械工业出版社 ，2004