免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: zx_wing

《Interrupt in Linux(硬件篇)》(1楼有更新 2008.5.3) [复制链接]

论坛徽章:
0
发表于 2008-05-03 09:08 |显示全部楼层
牛蛙的超牛作品,顶!
顺便问一个弱智问题:
你说的那个IMR置位的情况下,仍然会IRR有效,是从哪里看到的?
还有对于Edge中断,IO-APIC和Local APIC各自会pending一个,这个是从哪里看到的?

论坛徽章:
0
发表于 2008-05-01 16:16 |显示全部楼层
支持!打印出来了

论坛徽章:
0
发表于 2008-04-30 13:37 |显示全部楼层
原帖由 zx_wing 于 2008-4-30 11:47 发表
PS:我要到版务去申请能不能给论坛加一个像邮件那种,一回复自动在头上加“>>”的功能,自己打太麻烦了。


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

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

论坛徽章:
0
发表于 2008-04-30 11:47 |显示全部楼层
老大看的真仔细,感动!

>> 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:我要到版务去申请能不能给论坛加一个像邮件那种,一回复自动在头上加“>>”的功能,自己打太麻烦了。

论坛徽章:
0
发表于 2008-04-30 11:07 |显示全部楼层
原帖由 zx_wing 于 2008-4-29 11:53 发表

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


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

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

论坛徽章:
0
发表于 2008-04-30 10:22 |显示全部楼层
没看完,也没看仔细,等抽时间细看。  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上解释过,明天找找

论坛徽章:
0
发表于 2008-04-29 15:21 |显示全部楼层

回复 #52 zx_wing 的帖子

看贴不仔细哈。

谁说只有一个handler?

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

论坛徽章:
0
发表于 2008-04-29 12:04 |显示全部楼层
晕,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 编辑 ]

论坛徽章:
0
发表于 2008-04-29 11:54 |显示全部楼层

回复 #49 dengcainiao 的帖子

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

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

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

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

论坛徽章:
0
发表于 2008-04-29 11:53 |显示全部楼层
原帖由 albcamus 于 2008-4-29 09:36 发表


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

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

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP