《Interrupt in Linux（硬件篇）》（1楼有更新 2008.5.3）

minifish

牛蛙的超牛作品，顶！
顺便问一个弱智问题：
你说的那个IMR置位的情况下，仍然会IRR有效，是从哪里看到的？
还有对于Edge中断，IO-APIC和Local APIC各自会pending一个，这个是从哪里看到的？

flw2

支持！打印出来了

albcamus

原帖由 zx_wing 于 2008-4-30 11:47 发表
PS:我要到版务去申请能不能给论坛加一个像邮件那种，一回复自动在头上加“>>”的功能，自己打太麻烦了。

firefox有个插件，叫it's all text!，可以在文本输入框的右下角浮现一个「edit」图标，用自己喜欢的编辑器编辑，我用gvim。

不过这个插件还是不爽，我喜欢可以指定命令的，那样就可以指定为konsole -e vim来编辑了^_^

zx_wing

老大看的真仔细，感动！

>> APIC Bus 已经不存在,系统的前端总线代替了它。
>>APIC Bus已经不存在了， 取而代之的是， LAPIC之间、LAPIC和IOAPIC之间的通信，通过前端总线来传递。
同意，马上修改

>>  当 IOAPIC 某个管脚接收到中断信号后,会根据该管脚对应的 RTE,格式化出一条中
>>  断消息,发送给某个 CPU 的 LAPIC。

>>严谨起见，「发送给某个CPU」应改为「发送给某个或某些CPU」
同意，马上修改


>> X86 spec 说 4bit 的 LAPIC ID 可 以 表 示 15 个 CPU , 还 有 一 个 哪 儿 去 了 ? 我 想 是 留 给
>>IOAPIC 了。

>>对Pentium和P6家族CPU来说， APIC ID == 0x0f是广播ID，即匹配所有的LAPICs。

惭愧，马上修改。


>>         IOAPIC2 有 16 个管脚,GSI base 为 24,GSI 范围为[24,39],依次类推。

>>这里应该是IOAPIC1吧？
对，马上改


>>     笔者:每个 CPU 都用同样的物理地址访问自己的 LAPIC。这说明除了 x86 平台的 port
>>I/O 具有 64K 独立的物理地址空间外,LAPIC 也拥有独立的物理地址。我能想到的理由是
>>防止 CPU 访问不属于自己的 LAPIC。


>>不同意这种观点。 CPU以I/O指令访问IO ports，无论如何，是要走总线的； 而访问自己的LAPIC，
>>无论如何，都不需要走总线，而是由CPU(BIU单元?)和LAPIC以及链结它们的硬件(不管是什么)来保证的。
这个需不需要走总线还真不好说。从实现上来说，它可以发到总线上，最后访问到自己。也可以不发到总线上。
就像self IPI一样，实现可以广播到总线再发给自己，也可以不广播。取决于具体实现。
这个地方主要是想强调LAPIC 地址和IO地址一样属于独立地址空间。



>>      该表用于重载 MADT 表头中的 LAPIC 地址,整个 MADT 表中只应该包含一个 LAPIC
>>address override entry。

>>建议补充一句(我觉得不补充很多人会糊涂):
>>之所以提供LAPIC address override entry，是因为在x86-64 CPU上物理抵制是64位的，
>>因此原来的4字节--也就是32位--的LAPIC物理地址是无效的，因此用这样一个override机制来提供一个8字节
>>的LAPIC物理地址。
>>FIXME: 为什么IO-APIC不需要提供address override entry？ 64位机器上的IOAPIC地址也是32位的？
说实话，我还真没想到重载地址是为了32bit到64bit平台。但是为啥64bit平台上不能用32bit地址？是不是因为相对于CPU的物理地址空间，LAPIC地址需要在一个相对固定的地方？

>>            笔者:从 Linux 的注释来看,TPR 将一直为 0。X86 spec 有这么一段话:
“ 对 于 使 用 lowest priority delivery mode 发 送 中 断 , 却 又 不 更 新 TPR 的
OS,芯片组将记忆 TPR 并将同一中断发送给同样的 CPU 处理。这将引起性
能损失”。

>>Mark一下，我也注意到了这句话，似乎Andi Kleen曾经在lkml上解释过，明天找找
好的，等待结果哈：）


bluesky_jxc同学在帮我补充PIRQ table的内容，我先把这些修改加上去，加上版本号。等他写完了，一并更新发上来。
PS:我要到版务去申请能不能给论坛加一个像邮件那种，一回复自动在头上加“>>”的功能，自己打太麻烦了。

albcamus

原帖由 zx_wing 于 2008-4-29 11:53 发表

好建议。我也打算更新后在里面加Revision History，但第一版从哪个版本号开始呢

从哪个版本号开始，你说了算丫

还有，如果能加上参考文献就更好了^_^     这将是一份被广泛引用的文档

albcamus

没看完，也没看仔细，等抽时间细看。  AFAICT， 这份文档的深度、广度以及历史追溯上，是至少我前所未见的。


一些商榷的地方（边看边发）
-------------------------
P9:

>> APIC Bus 已经不存在,系统的前端总线代替了它。
APIC Bus已经不存在了， 取而代之的是， LAPIC之间、LAPIC和IOAPIC之间的通信，通过前端总线来传递。


P10:

>>  当 IOAPIC 某个管脚接收到中断信号后,会根据该管脚对应的 RTE,格式化出一条中
>>  断消息,发送给某个 CPU 的 LAPIC。

严谨起见，「发送给某个CPU」应改为「发送给某个或某些CPU」


P13:
>> X86 spec 说 4bit 的 LAPIC ID 可 以 表 示 15 个 CPU , 还 有 一 个 哪 儿 去 了 ? 我 想 是 留 给
IOAPIC 了。

对Pentium和P6家族CPU来说， APIC ID == 0x0f是广播ID，即匹配所有的LAPICs。

手册卷III，8.6.2.1 Physical Destination Mode节说：
For the P6 family and Pentium processors, a single destination is specified in physical
destination mode with a local APIC ID of 0H through 0EH, allowing up to 15 local
APICs to be addressed on the APIC bus. A broadcast to all local APICs is specified with
0FH.

P19:

>>         IOAPIC2 有 16 个管脚,GSI base 为 24,GSI 范围为[24,39],依次类推。

这里应该是IOAPIC1吧？

P25:
>>     笔者:每个 CPU 都用同样的物理地址访问自己的 LAPIC。这说明除了 x86 平台的 port
I/O 具有 64K 独立的物理地址空间外,LAPIC 也拥有独立的物理地址。我能想到的理由是
防止 CPU 访问不属于自己的 LAPIC。


不同意这种观点。 CPU以I/O指令访问IO ports，无论如何，是要走总线的； 而访问自己的LAPIC，
无论如何，都不需要走总线，而是由CPU(BIU单元?)和LAPIC以及链结它们的硬件(不管是什么)来保证的。

当然，我这也是猜测^_^


P26:
>>      该表用于重载 MADT 表头中的 LAPIC 地址,整个 MADT 表中只应该包含一个 LAPIC
address override entry。

建议补充一句(我觉得不补充很多人会糊涂):
之所以提供LAPIC address override entry，是因为在x86-64 CPU上物理抵制是64位的，
因此原来的4字节--也就是32位--的LAPIC物理地址是无效的，因此用这样一个override机制来提供一个8字节
的LAPIC物理地址。

FIXME: 为什么IO-APIC不需要提供address override entry？ 64位机器上的IOAPIC地址也是32位的？


P29:
>>            笔者:从 Linux 的注释来看,TPR 将一直为 0。X86 spec 有这么一段话:
“ 对 于 使 用 lowest priority delivery mode 发 送 中 断 , 却 又 不 更 新 TPR 的
OS,芯片组将记忆 TPR 并将同一中断发送给同样的 CPU 处理。这将引起性
能损失”。

Mark一下，我也注意到了这句话，似乎Andi Kleen曾经在lkml上解释过，明天找找

bluesky_jxc

看贴不仔细哈。

谁说只有一个handler？

我的意思是，“很多”设备共享中断，“很多”handler，但是每次“只有一个”设备发送中断的情形！

zx_wing

晕，bluesky_jxc你想叉啦，这里讲的中断批处理和中断共享的chain没啥关系。
其次中断共享每次遍历链表，也要链表里有多个handler时才会嘛，如果没共享不是还是只有一个handler。
dengcain的理解是对的哈
PS：windows如何做的？我买了那本书却一直还没看到中断那章。但我这里有篇微软的文章，从中看出windows用的也是类似的方式。
这篇文章讲中断共享的害处，写的非常好，推荐
http://www.microsoft.com/taiwan/whdc/archive/apic.mspx

[ 本帖最后由 zx_wing 于 2008-4-29 12:06 编辑 ]

bluesky_jxc

我们说的应该不是一个东西

你说的是类似网络驱动中NAPI的工作方式，例如Gbit 的网卡等，因为相对这种产生中断的速度，中断切换的开销就很大了，因此有一种叫做“半轮询”的机制来减轻这种问题，可能就是你说的，一次中断切换处理很多isr。

我说的是指对共享isr的处理，在遍历action链表的时候，是“只要遇到一个合适的isr”就返回呢，还是“不管发生什么情形，都遍历整个isr链表”。

不是说一个东西，讨论不出来啥新鲜玩意儿

zx_wing

原帖由 albcamus 于 2008-4-29 09:36 发表


应该给文档标上版本， 例如v0.9.1之类， 并且第一页加上Revision History. ^_^

好建议。我也打算更新后在里面加Revision History，但第一版从哪个版本号开始呢