level, edge, cli, disable_irq, PIT， LAPIC Timer ... 一次讨论个清楚吧！

motalelf

2.6.24中我找了找,这种延迟mask的机制,没有找到.

这个版本刚开始看,还不大熟悉,没找到不一定没有.不过我觉得这种逻辑应该是正确的,理由就是18楼说的:  kernel并不是怕mask期间,丢一两个中断;而是怕mask期间,中断全都丢了,还无法判断是否应REPLAY一次,由此导致的设备再也不中断.



至于do_IRQ中的ack和end,我怀疑是不是只是传统的叫法.

在PIC的时期,中断处理开始,需要马上mask并发出EOI;中断处理结束,需要unmask中断线. 主要为了实现一种无优先级模型.所以需要这两步,对应的就起了这么两个名字,ack和end.

在有了APIC后,很多情况已经不再需要ack和end这两步. 而且有的版本也确实这么做的,ack和end之中,有一个为空.  

代码把irq的处理过程写为: 先ack,再处理,最后end. 只是为了通过修改ack和end指针,能够适应所有情况,并不是因为ack和end肯定代表着什么.

motalelf

IRQ_REPLAY和IRQ_PENDING的配合使用主要是为了处理lost interrput，也就是当一个CPU在处理某类型的中断，另一个CPU屏蔽了该中断。当处理中断的的CPU遇到IRQ_DISABLE标志从而导致应答中断但还没处理就返回

我到是觉得这种情况很好避免,只要IRQ_INPROGRESS的CPU,一直判断是否有IRQ_PENDING,而不判断IRQ_DISABLE就好了.

而diasble_irq的CPU,可以选择是否等待IRQ_INPROGRESS消失后再返回, 既是否disable_irq_sync.  

只为这个,似乎用不了采取IRQ_REPLAY这么一种麻烦的手段. 为什么不这样做呢?


目前只发现这样一段代码,不过并不能代表一般情况:

1. static void
   
2. iosapic_ack_edge_irq (unsigned int irq)
   
3. {
   
4.         irq_desc_t *idesc = irq_desc + irq;
   
5. 
   
6.         move_native_irq(irq);
   
7.         /*
   
8.          * Once we have recorded IRQ_PENDING already, we can mask the
   
9.          * interrupt for real. This prevents IRQ storms from unhandled
   
10.          * devices.
    
11.          */
    
12.         if ((idesc->status & (IRQ_PENDING|IRQ_DISABLED)) ==
    
13.             (IRQ_PENDING|IRQ_DISABLED))
    
14.                 mask_irq(irq);
    
15. }

复制代码

[ 本帖最后由 motalelf 于 2008-3-28 23:52 编辑 ]

bluesky_jxc

我怎么记得MSI可以选择电平或者边缘触发呢？
翻翻书去

bluesky_jxc

我没有明白一点，在什么情况下edge中断会丢失？

对于工作正常的设备，一般在CPU没有处理完前面一个中断之前是不会继续发送下一个中断的。
（我知道timer会这样，至少在虚拟机里出现，所以导致时间会漂移）

对于PIC，相信不会吧(IRR保证)。
对于APIC，只要IOAPIC接受了这个硬件中断，并转发到对应的Local APIC，那么这个中断就不会丢失，因为APIC之间的消息肯定会有自己的重传/应答机制保证，如果这么容易丢失，那APIC还混啥。

只要硬件保证中断不丢失（只要保证有一个不丢失），那么中断系统就能正常工作（right？）。

我想只有一种情况会这样，就是你说的硬件禁止中断，也就是IOAPIC不响应设备的中断。这种情况会出现么？在什么情况下出现呢？

zx_wing

原帖由 motalelf 于 2008-3-28 22:50 发表
2.6.24中我找了找,这种延迟mask的机制,没有找到.

这个版本刚开始看,还不大熟悉,没找到不一定没有.不过我觉得这种逻辑应该是正确的,理由就是18楼说的:  kernel并不是怕mask期间,丢一两个中断;而是怕mask期间 ...

在说这个问题之前，有一点先要搞清楚，就是什么设备用edge触发。
我知道ISA设备和timer都是edge触发，对于ISA设备的处理我还不清楚。

zx_wing

原帖由 motalelf 于 2008-3-28 23:50 发表


我到是觉得这种情况很好避免,只要IRQ_INPROGRESS的CPU,一直判断是否有IRQ_PENDING,而不判断IRQ_DISABLE就好了.

而diasble_irq的CPU,可以选择是否等待IRQ_INPROGRESS消失后再返回, 既是否disable_irq_sy ...

不，它形容还不是这种情况。这个掉中断的情况是这样的。
CPU1处理中断1，假设刚通过interrtupt gate到entry.s里的汇编部分，这个时候CPU2把中断1屏蔽掉了，那么该中断的IRQ_DISABLE写上。那么CPU1处理中断1时只会应答中断和设置PENDING就返回，中断就掉了。
而不是说CPU1已经在中断处理的do....while()循环中时，该中断才被屏蔽的。

zx_wing

原帖由 bluesky_jxc 于 2008-3-29 12:10 发表
我没有明白一点，在什么情况下edge中断会丢失？

对于工作正常的设备，一般在CPU没有处理完前面一个中断之前是不会继续发送下一个中断的。
（我知道timer会这样，至少在虚拟机里出现，所以导致时间会漂移）
...

>>对于APIC，只要IOAPIC接受了这个硬件中断，并转发到对应的Local APIC，那么这个中断就不会丢失，因为APIC之间的消息肯定会有自己的重传/应答机制保证，如果这么容易丢失，那APIC还混啥。
这个问题很有道理，你有没有兴趣调查一下MSI是如何保证消息不掉的？APIC BUS我们就不管了，那已经过时了，现在的x86都用MSI了

对于edge触发的中断，还是那句话，不要脱离设备来空谈有什么机制来保证。对于这个问题我现在还不太清楚，我还不知道对于ISA设备linux如何处理的，等我搞清楚再来讨论。

bluesky_jxc

我同意你的观点，就是不同设备需要不同考虑。

比如timer，你在设计的时候就需要考虑掉中断的情形。如果硬件都没有办法来保证不掉中断，那么不管软件怎么搞，都白搭。所以在设计硬件的时候应该就会考虑进去的。

另外问一下motalelf，IOAPIC禁止中断是物理屏蔽中断线？能详细讲讲么，或者给出这种芯片的说明文档也行。

bluesky_jxc

>>这个问题很有道理，你有没有兴趣调查一下MSI是如何保证消息不掉的？APIC BUS我们就不管>>了，那已经过时了，现在的x86都用MSI了

MSI不就是一个memory 写么。
在PCI里，PCI-PCI桥的作用就体现出来了，PCI桥里面有写buffer，而且PCI总线里也有Retry机制。当target不能接受更多memory写操作后，它会发起一个retry信号。PCI的这套协议保证了写不会丢失，这个很关键，因为写操作和读操作不一样，读必须是同步的，而写则是异步的，如果写丢了，那就再也找不回来了。

PCI里面还有一个生产者/消费者模型，保证读和写操作的一致性。

albcamus

原帖由 zx_wing 于 2008-3-28 12:16 发表
最近正在认真学习这个部分，al老大就发起话题了，正好也讨论一下

1 ）level 和 edge这两种类型的中断， 谁能简要的说一下区别？   

   附加疑问： 为什么MSI中断被当成edge中断？

区别嘛，汗 ...

老大，是不是IO-APIC不需要ACK？ 我看ioapic_chip的ack和eoi方法是：

ack_ioapic_irq
ack_ioapic_quirk_irq


quirk是不是只是处理有BUG的硬件？