对中断的一点思考

2019-04-15 14:24发布

对中断的一点思考
杨小华(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()->具体的中断处理程序。大家都知道中断类型包括三种:
标志
含义 SA_INTERRUPT 当该位被设置时,表明这是一个快速的中断处理程序。在本地处理器上,快速中断处理程序在禁止所有中断的情况下运行。除了时钟中断外,绝大多数中断都不使用该标志。 SA_SHIRQ
该位表示中断可以在设备之间共享。 SA_SAMPLE_RANDOM
该位指出产生的中断能对/dev/random设备和/dev/urandom设备使用的熵池有贡献。
表 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