Chinaunix

标题: 《Interrupt in Linux（硬件篇）》（1楼有更新 2008.5.3） [打印本页]

作者: zx_wing 时间: 2008-04-27 20:47
标题: 《Interrupt in Linux（硬件篇）》（1楼有更新 2008.5.3）
前段时间讨论了中断，写了篇文章，大家帮忙看看。把文章中错误和问题都发到这个帖子里，大家讨论一下，争取把不清楚的地方都搞清楚。
水平有限，写的不好，将就看吧

:" />:" />:" />:" />:" />:" />

内容提要
第一章：介绍了PIC和APIC系统的基本架构，提供了了解现代中断系统构成的基本知识。
第二章：论述了Linux如何探测中断硬件，以及如何初始化它们。
第三章：补充了一些中断系统的硬件知识，没有它们你也应该能读懂前两章的内容。
文中用大量“题外话”介绍了中断相关的知识和原理，它们大部分是笔者感兴趣的，例如“Remote IRR的作用”、“Edge中断的共享与丢失”、“伪中断产生的原因”等。以“笔者”开头的文字，是作者自己对一些问题的看法，其中有很多不能解决的疑问，如果你知道答案，希望能通过 xing5820@163.com告诉我，让我及时更新相关内容。同时，非常欢迎指出文中的错误之处。
此文虽取名为“硬件篇”，但不代表就有一个“软件篇”存在。虽然目前内核使用了Generic Interrupt Layer，但这只是对原__do_IRQ()路径的封装，ULK3的内容完全适用于当前内核中断系统，软件相关内容可以参考此书。

al老大帮忙把目录加上了

:" />:" />:" />:" />:" />:" />

多谢大家顶帖

但我更希望大家看了后多提一点问题或多指出一些文中的错误。
不要怕问的问题简单，或者太异想天开。发文章的目的就是希望能借此和大家讨论把很多不清楚的地方搞清楚。
dengcainiao 兄弟就问了我很多问题，给了我不少启发让我纠正文中的错误。一个人能想到的东西毕竟有限，希望能集思广益。
比如dengcainiao 兄弟问我

就是为什么level触发不像edge触发一样也让io apic在CPU处理中断的时候也可以发送新的中断信息到LOCAL APIC呢？

复制代码

我原先想是电路实现保证的，后来又想想这样实现有什么好处，得出的结论是：

在一个中断在处理过程中，让同一类型的中断发送到LAPIC是种落后的机制。
因为中断只是要通知CPU该为设备服务了，驱动程序完全可以一次处理设备发生的多个中断。
例如：
设备发生了第一次中断A，CPU开始处理 ---->在CPU执行设备的中断处理函数前第二次中断发生了 ---> IOAPIC阻止该中断到达CPU ---->CPU执行中断处理函数，该函数发现设备有两次中断，一次处理掉 ---->设备拉低中断线
这样，就避免多打断CPU一次。更为先进的APIC，例如IA64平台的SAPIC，就有中断批处理的功能，减少因每次中断而引起的上下文切换开销。也是类似道理。

复制代码

欢迎类似的问题

内容补充：

1、bluesky_jxc老大：对于PIC，IMR即使置位，IRR也会设置的。IMR不影响IRR，只是不允许对应IRR参与中断优先级仲裁。
作者理解：在内核邮件列表也看到有人说道：对于edge中断，即使mask了也会pending住，在unmask的时候发送给CPU。应该就是bluesky_jxc说的这个机制了。该机制保证了edge触发中断不会在mask的时候丢失。
对于APIC情况下的edge中断，操作系统应该不会在处理中断的时候mask它（至少linux没有），最大程度避免了丢失中断的情况。

2、此文中中断初始化的路径只适用于系统使用MP spec的情况，惭愧，现在才发现把ACPI的初始化路径写掉了

Revision History

日期
版本
描述

2008.5.3
1.1
Ÿ 根据 albcamus 同学的建议，修改了文中多处错误
Ÿ 根据Bluesky_jxc同学的补充，修改了edge中断共享与丢失的内容
Ÿ Bluesky_jxc同学补充了PIRQ Table章节

2008.4.27
1.0
最初发表版本

[ 本帖最后由 zx_wing 于 2008-5-3 18:39 编辑 ]

interrupt in linux-1.1.pdf

924.66 KB, 下载次数: 8424

作者: zx_wing 时间: 2008-04-27 20:51
搞了两个小时都没找到一个好的word转pdf的软件。
用的公司的机器，不能安盗版，最后还是用openoffice转的，可惜格式乱了，目录没了。大家只有凑合着看

作者: duanius 时间: 2008-04-27 20:51
牛蛙的大作。。。下下来拜读一下。。如果看的懂的话

作者: scutan 时间: 2008-04-27 21:40
顶一个，拜读大作。

作者: zx_wing 时间: 2008-04-27 21:52
我想把文章贴到blog里好被google检索，但怎么把图弄进去呢？
哪位老大有经验？

作者: crspo 时间: 2008-04-27 22:51
顶，看这种文档会节省很多时间

作者: kissGNU 时间: 2008-04-28 00:06
很好的总结，可以再一次学习一下，多谢了

作者: Roemer 时间: 2008-04-28 02:13
有空学习一下

作者: lyl19 时间: 2008-04-28 08:34
顶，好好学习下

作者: hongmy525 时间: 2008-04-28 08:49
非常感谢，下下来读读
前阵子看中断有点点迷糊~

作者: dengcainiao 时间: 2008-04-28 09:27
标题: 呵呵，终于发出来了啊~~~
好好学习一下~~：）

作者: albcamus 时间: 2008-04-28 09:45

原帖由 zx_wing 于 2008-4-27 20:51 发表
搞了两个小时都没找到一个好的word转pdf的软件。
用的公司的机器，不能安盗版，最后还是用openoffice转的，可惜格式乱了，目录没了。大家只有凑合着看

可以用cute pdf

作者: qps104 时间: 2008-04-28 09:50
来的很及时,正好学习下这方面

作者: albcamus 时间: 2008-04-28 09:53
老大，这个文档还是想办法转成有标签的PDF吧，你要是有困难的话，发给我我帮忙转。

辛苦你一个，幸福我们大家啊：）

作者: zx_wing 时间: 2008-04-28 11:39

原帖由 albcamus 于 2008-4-28 09:53 发表
老大，这个文档还是想办法转成有标签的PDF吧，你要是有困难的话，发给我我帮忙转。

辛苦你一个，幸福我们大家啊：）

好的，我msn你
转了你帮我把这个帖子里的换掉

作者: albcamus 时间: 2008-04-28 13:14

原帖由 zx_wing 于 2008-4-28 11:39 发表

好的，我msn你
转了你帮我把这个帖子里的换掉

已经转好上传。 2.1.2.1节的阴影部分有一点没处理好，暂时没找到方法，不过加上Tab可漂亮很多了^_^

作者: albcamus 时间: 2008-04-28 13:43
看了几页，牛的一塌胡涂。。。

作者: zhzhl555 时间: 2008-04-28 13:50
多谢lz这么费心。大好人啊

作者: sardinescn 时间: 2008-04-28 13:50
浏览了一下，这个是一定要顶的。

作者: zx_wing 时间: 2008-04-28 14:09
多谢大家顶帖

就是为什么level触发不像edge触发一样也让io apic在CPU处理中断的时候也可以发送新的中断信息到LOCAL APIC呢？

我原先想是电路实现保证的，后来又想想这样实现有什么好处，得出的结论是：

在一个中断在处理过程中，让同一类型的中断发送到LAPIC是种落后的机制。
因为中断只是要通知CPU该为设备服务了，驱动程序完全可以一次处理设备发生的多个中断。
例如：
设备发生了第一次中断A，CPU开始处理 ---->在CPU执行设备的中断处理函数前第二次中断发生了 ---> IOAPIC阻止该中断到达CPU ---->CPU执行中断处理函数，该函数发现设备有两次中断，一次处理掉 ---->设备拉低中断线

这样，就避免多打断CPU一次。更为先进的APIC，例如IA64平台的SAPIC，就有中断批处理的功能，减少因每次中断而引起的上下文切换开销。也是类似道理。

欢迎类似的问题

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

作者: bluesky_jxc 时间: 2008-04-28 14:17
标题: 回复 #20 zx_wing 的帖子
对于PIC，IMR即使置位，IRR也会设置的。IMR不影响IRR，只是不允许对应IRR参与中断优先级仲裁。

作者: zx_wing 时间: 2008-04-28 14:21

原帖由 bluesky_jxc 于 2008-4-28 14:17 发表
对于PIC，IMR即使置位，IRR也会设置的。IMR不影响IRR，只是不允许对应IRR参与中断优先级仲裁。

IRR是指PIC的IRR吗？
看来我看的还是不仔细啊，内核邮件列表有人说对于edge中断，即使mask掉，也会被pending住，在unmask的时候发给CPU。看来就是这个机制保证ISA接PIC不丢中断了。
补充的好，又搞清楚一个问题。不知道APIC有这个功能不，我当时找了找，没找到。

作者: bluesky_jxc 时间: 2008-04-28 14:42
标题: 回复 #22 zx_wing 的帖子
我问过haitao同学，他问过老大，但是老大也说记不清楚了，一般说来，APIC并不会mask edge中断。（有待考证）

RemoteIRR的作用就是防止interrupt storm，而edge不会有这个问题，所以不需要RemoteIRR。

但是，我想不通的是，remoteIRR如果对Edge起作用会有什么问题，如果能够起作用，那么mask edge中断就不会有问题了，你的文章也没有提到这个问题。

另外，文章缺PIRTable。这个很重要的，因为MPTable是需要操作系统切换到SMP才会起作用（描述PCI如何连接到IOAPIC），众所周知，SMP之前，操作系统是UP状态，因此需要知道PCI是如何连接到ISA中断的（否者你怎么读硬盘？因为硬盘也是接在PCI总线下游的南桥上的IDE接口上的）。

在ACPI中解决了这个问题，它提了一个SCI中断（没记错名字吧？），规定该中断时level的，因此可以被pci使用。因此就至少有一个中断可用了。

有时间加上吧，如果你没有时间，把word传给我，我来补充

作者: bluesky_jxc 时间: 2008-04-28 14:44
标题: 回复 #23 bluesky_jxc 的帖子
哦，有个笔误，IDE接口可以不用PCI中断，但是SATA是需要的。

作者: bluesky_jxc 时间: 2008-04-28 14:54
标题: 回复 #22 zx_wing 的帖子
另外还有一个问题，你说APIC ID 4 bit，最多15个，另一个给IOAPIC。
我想知道广播是怎么实现的？难道有另外的线来实现？

作者: zx_wing 时间: 2008-04-28 15:07
标题: 回复 #23 bluesky_jxc 的帖子
>>我问过haitao同学，他问过老大，但是老大也说记不清楚了，一般说来，APIC并不会mask edge中断。（有待考证）
老大就是老大啊，刚才我仔细看了linux处理edge的部分，确实APIC情况不会去mask edge中断。

>>RemoteIRR的作用就是防止interrupt storm，而edge不会有这个问题，所以不需要RemoteIRR。
有道理，防止中断风暴的同时有保证不掉中断。

>>但是，我想不通的是，remoteIRR如果对Edge起作用会有什么问题，如果能够起作用，那么mask edge中断就不会有问题了，你的文章也没有提到这个问题。
呵呵，这个就是设计电路的人考虑的问题了。我想提到啊，但我不知道怎么设计这个电路。你必须有个部件可以把edge触发的中断hold住，在适当的时候在re-trigger吧。我数电知识还给老师好多年了。

>>另外，文章缺PIRTable。这个很重要的，因为MPTable是需要操作系统切换到SMP才会起作用（描述PCI如何连接到IOAPIC），众所周知，SMP之前，操作系统是UP状态，因此需要知道PCI是如何连接到ISA中断的（否者你怎么读硬盘？因为硬盘也是接在PCI总线下游的南桥上的IDE接口上的）。
你说的微软定的那个PIRQ table spec吗？因为这个不是硬件规范，只是从操作系统看PCI中断的连接法。我没看，你帮忙补充吧。

>>在ACPI中解决了这个问题，它提了一个SCI中断（没记错名字吧？），规定该中断时level的，因此可以被pci使用。因此就至少有一个中断可用了。
我不知道SCI是如何用的，但它是system control interrupt啊，具体怎么用在PCI上我不知道。

发给你了，你帮忙补充一下。

作者: zx_wing 时间: 2008-04-28 15:09

原帖由 bluesky_jxc 于 2008-4-28 14:54 发表
另外还有一个问题，你说APIC ID 4 bit，最多15个，另一个给IOAPIC。
我想知道广播是怎么实现的？难道有另外的线来实现？

不用吧，IOAPIC不能接收中断消息，所以发给它也无所谓嘛

作者: bluesky_jxc 时间: 2008-04-28 15:12
标题: 回复 #25 bluesky_jxc 的帖子
ICR里面有个dest shorthand的位，用来表示是否是广播，是广播的话，ID区域就不再care了。

谢谢haitao热情赞助

作者: zx_wing 时间: 2008-04-28 15:16

原帖由 bluesky_jxc 于 2008-4-28 15:12 发表
ICR里面有个dest shorthand的位，用来表示是否是广播，是广播的话，ID区域就不再care了。

谢谢haitao热情赞助

大哥，那个是发IPI用的。
IOAPIC也要广播消息啊，所以只要它自己不能接收就可以了。
如果你问如何发广播消息，IPI可以用dest shorthand。但一个通用的方法是吧RTE的destination field中的APIC ID写成0xff。

作者: bluesky_jxc 时间: 2008-04-28 15:18
标题: 回复 #26 zx_wing 的帖子
>>呵呵，这个就是设计电路的人考虑的问题了。我想提到啊，但我不知道怎么设计这个电路。你必>>须有个部件可以把edge触发的中断hold住，在适当的时候在re-trigger吧。我数电知识还给老>>师好多年了。

remoteIRR不能做么？我想如果真有需求的话，这肯定不是实现的难题

作者: bluesky_jxc 时间: 2008-04-28 15:22
标题: 回复 #29 zx_wing 的帖子
一共才16个地址，如果15个被LAPIC用掉了，一个被IOAPIC用了，如何表示广播呢？我想错了，我一直以为会为广播保留地址：）

作者: wuzhao 时间: 2008-04-28 16:25
下了回头慢慢研究完了再请教~~~

作者: jiangqiangq 时间: 2008-04-28 16:59
好贴是要顶的！
顶！

作者: zx_wing 时间: 2008-04-28 17:12

原帖由 jiangqiangq 于 2008-4-28 16:59 发表
好贴是要顶的！
顶！

这个不会是yunhong老大吧

作者: dengcainiao 时间: 2008-04-28 17:57

原帖由 zx_wing 于 2008-4-28 14:21 发表

IRR是指PIC的IRR吗？
看来我看的还是不仔细啊，内核邮件列表有人说对于edge中断，即使mask掉，也会被pending住，在unmask的时候发给CPU。看来就是这个机制保证ISA接PIC不丢中断了。
补充的好，又搞清楚一个 ...

这个问题也是上次和你讨论的疑惑之一啊，貌似这样确实可以解决edge trigger的中断丢失问题。

作者: 20060106023940 时间: 2008-04-28 18:14

拜读一下

作者: rtcontrol 时间: 2008-04-28 18:38

这样，就避免多打断CPU一次。更为先进的APIC，例如IA64平台的SAPIC，就有中断批处理的功能，减少因每次中断而引起的上下文切换开销。也是类似道理。

中断批处理是不是中断计数？中断次数到一定数量才向cpu发起一次处理请求。

作者: zx_wing 时间: 2008-04-28 18:50

原帖由 rtcontrol 于 2008-4-28 18:38 发表

中断批处理是不是中断计数？中断次数到一定数量才向cpu发起一次处理请求。

不是。
SAPIC里面有个IVR寄存器，读它可以得到当前需要处理中断的vector，每处理完一个就写一个EOI，就像下面的伪代码表示的：

while ( (vec=read_IVR()) !=0 )
{
handle_interrupt(vec);
wirte_EOI(vec)
}

复制代码

当在处理一个中断时，其它中断可以pending住，处理完后通过读IVR处理下一个，直到完成。
这样，只用一次中断时的上下文切换，就可以处理接下来的所有中断。
而不用像x86一样，处理完一次后iret后，CPU又被中断，再处理 …… 节省上下文切换的开销。

作者: zx_wing 时间: 2008-04-28 18:50

原帖由 dengcainiao 于 2008-4-28 17:57 发表

这个问题也是上次和你讨论的疑惑之一啊，貌似这样确实可以解决edge trigger的中断丢失问题。

我已经在首页作为补充内容更新了，看来应该在标题上写出来。

作者: lbt5210 时间: 2008-04-28 19:48
仰慕啊！！！

作者: rtcontrol 时间: 2008-04-28 20:03
明白了中断批处理，有了中断批处理功能，系统的实时性又能提高一些，

作者: risepp 时间: 2008-04-28 20:39
谢谢楼主分享，学习中～～～

作者: bluesky_jxc 时间: 2008-04-29 08:48
标题: 回复 #41 rtcontrol 的帖子
ok, 我不得不说，it depends。。。

想象一下，如果每次检查都只有一个中断就绪，而action链表很长呢？
虽然每个isr会很快退出，但是从整体上面来讲，并不能说那种方法一定有优势

作者: albcamus 时间: 2008-04-29 09:36

原帖由 zx_wing 于 2008-4-28 18:50 发表

我已经在首页作为补充内容更新了，看来应该在标题上写出来。

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

作者: dengcainiao 时间: 2008-04-29 09:40

原帖由 bluesky_jxc 于 2008-4-29 08:48 发表
ok, 我不得不说，it depends。。。

想象一下，如果每次检查都只有一个中断就绪，而action链表很长呢？
虽然每个isr会很快退出，但是从整体上面来讲，并不能说那种方法一定有优势

没明白你的意思，能再详细解释一下吗？action链表的长短和中断批处理有什麽关系吗？如ZT_WING解释的那样似乎只节省了上下文切换的时间，遍历action链表即使是中断批处理不也是每次响应一个中断都要做一次吗？

作者: zhel1978 时间: 2008-04-29 09:42

学习学习

作者: bluesky_jxc 时间: 2008-04-29 10:44
标题: 回复 #45 dengcainiao 的帖子
linux设计成每次中断都遍历整个action链表，但是并不表示所有操作系统都会这么设计，比如windows就是只要有一个isr完成了就返回。

各自有各自的优势，没办法说这种“批处理”好还是“单处理”好。

作者: wylhistory 时间: 2008-04-29 11:02
没啥好说的，崇拜！！！

作者: dengcainiao 时间: 2008-04-29 11:19

原帖由 bluesky_jxc 于 2008-4-29 10:44 发表
linux设计成每次中断都遍历整个action链表，但是并不表示所有操作系统都会这么设计，比如windows就是只要有一个isr完成了就返回。

各自有各自的优势，没办法说这种“批处理”好还是“单处理”好。

我对中断批处理的理解很浅显，是刚才ZT_WING在回复其他朋友时候看到的。但是按照我的理解，中断批处理似乎是高级硬件平台提供的一种机制，可以让操作系统有办法在一次陷入中断上下文后处理所有中断服务直到没有新的设备请求中断服务再返回用户空间，该机制可以避免由于频繁产生中断引起频繁的上下文切换产生的开销。（我猜测zt_wing介绍的一个大概意思，应该还有一些机制来保证用户空间程序不会过分饥饿）
bluesky_jxc大侠，我还是想不明白这与LINUX实现的把所有共享中断向量的ISR串在action链表里有什么关系？？我感觉无论是哪种操作系统，其表示中断共享的数据结构设计成什么样子都可以从这种硬件机制中受益。不知道我对中断批处理的理解是否正确，请zt_wing再明确一下。也请bluesky_jxc再费心回答一下我的疑问。

作者: zx_wing 时间: 2008-04-29 11:53

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

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

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

作者: bluesky_jxc 时间: 2008-04-29 11:54
标题: 回复 #49 dengcainiao 的帖子
我们说的应该不是一个东西

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

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

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

作者: zx_wing 时间: 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 编辑 ]

作者: bluesky_jxc 时间: 2008-04-29 15:21
标题: 回复 #52 zx_wing 的帖子
看贴不仔细哈。

谁说只有一个handler？

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

作者: albcamus 时间: 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上解释过，明天找找

作者: albcamus 时间: 2008-04-30 11:07

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

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

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

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

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

作者: albcamus 时间: 2008-04-30 13:37

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

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

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

作者: flw2 时间: 2008-05-01 16:16
支持！打印出来了

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

作者: bluesky_jxc 时间: 2008-05-03 11:29
标题: 回复 #59 minifish 的帖子
copy from 8259 spec:
"Interrupt Request Register (IRR): 8-bit register which
contains the levels requesting an interrupt to be acknowledged.
The highest request level is reset from
the IRR when an interrupt is acknowledged. (Not affected
by IMR.)"

edge中断在下面情况下才会pending2个：
1.当前某一个edge中断在服务，这个时候IRR清空，ISR置位
2.还没有服务完成（未写EOI），同一个中断发生，IRR置位

这个时候，IRR和ISR就同时置位。

在使用AEOI的时候也可能会出现这种情形，在第一个INTA和第二个INTA之间
如果有同类型的中断发生，也会出现同时两个寄存器置位。

作者: zx_wing 时间: 2008-05-03 12:08

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

>>还有对于Edge中断，IO-APIC和Local APIC各自会pending一个，这个是从哪里看到的？
对于APIC，IRR和ISR都在LAPIC中，所以只会在LAPIC中pending。
见x86 spec 3A卷第八章8.8.4节

作者: jazy333 时间: 2008-05-04 12:58
您的PDF在我这里看都是倒影！！！

作者: zx_wing 时间: 2008-05-04 13:01
标题: 回复 #62 jazy333 的帖子
不会吧，我试了两个PDF reader都是对的。

作者: minifish 时间: 2008-05-05 08:59

原帖由 zx_wing 于 2008-5-3 12:08 发表

>>对于APIC，IRR和ISR都在LAPIC中，所以只会在LAPIC中pending。
>>见x86 spec 3A卷第八章8.8.4节

我第一次听anthony说的，我以为你知道来源的。

作者: minifish 时间: 2008-05-05 09:13

原帖由 bluesky_jxc 于 2008-5-3 11:29 发表
copy from 8259 spec:
"Interrupt Request Register (IRR): 8-bit register which
contains the levels requesting an interrupt to be acknowledged.
The highest request level is reset from
the IRR wh ...

多谢！
但是对于pending两个的说法，我还是有点不理解。
你说的这种情况，我觉得实际上是只pending了一个“待处理”中断，因为另一个已经在处理了。
From SDM 8.8.4:
IF more than one interrupt is generated with the same vector number, the local APIC can set the bit for the vector both in the IRR and ISR.
就是这句话说的不太清楚。
假设这样子，eflags.if=0
然后同样的vector来了三个中断，那么IRR和ISR是怎样的状态呢？
都是1，那么ISR的状态跟它本身代表的含义是不符的，或者这是一种特殊情况？

作者: wdkzdom 时间: 2008-05-05 11:06
顶了再看~~

作者: zx_wing 时间: 2008-05-05 12:30

原帖由 minifish 于 2008-5-5 09:13 发表

多谢！
但是对于pending两个的说法，我还是有点不理解。
你说的这种情况，我觉得实际上是只pending了一个“待处理”中断，因为另一个已经在处理了。
From SDM 8.8.4:
IF more than one interrupt is gene ...

对，ISR、IRR对应bit都为1。
不能光从名字上推断一个寄存器的功能，虽然大部分时间名字代表功能，但不一定能代表所有功能。

作者: nicsky 时间: 2008-05-05 15:23
顶一个....................................

作者: zx_wing 时间: 2008-05-05 20:04

原帖由 minifish 于 2008-5-5 08:59 发表

我第一次听anthony说的，我以为你知道来源的。

哎哟，还是熟人哦。
那你私下msn我就好了嘛，在这里challenge，说错很丢人

作者: SCvsCS 时间: 2008-05-06 13:15
我也看着全是倒影，centos5.1, 使用evince。
建议把word文档一起放上来，我用openoffice打开算了

作者: 文艺复兴 时间: 2008-05-07 16:11
非常感谢楼主的辛勤劳动！！

作者: 孙辉也 时间: 2008-05-09 14:04
不错不错

顶一下呵呵希LZ再出精品阿

作者: Benson_linux 时间: 2008-05-09 16:53
下载了，不错的分享，谢谢

作者: augustusqing 时间: 2008-05-09 21:31
zx_wing大侠的文章，顶了再说。

作者: lingyb 时间: 2008-05-12 15:39
感谢楼主的分享

作者: tfjmych 时间: 2008-05-28 21:51
顶，好好学习下

作者: tfjmych 时间: 2008-05-28 21:51
不错不错

顶一下呵呵希LZ再出精品阿

作者: minifish 时间: 2008-05-30 10:08
问一个傻B的问题，为什么要把PCI的中断转成ISA中断？
PCI中断是active low, level triggered，ISA中断是edge triggered.
PIC是可以接受level中断的，只是要求active high
因为这个对PCI中断进行转换是必要的，但是把level转成edge就是在太奇怪了。

PCI 为啥要转 ISA 中断？这是很堂皇问题，毕竟，任何退步都是可耻的。但在计算机领域，兼容才是王道，才是市场。否则， Intel 就不会栽个跟头让 AMD 风光好几年 …… 我的废话好像有点多了。
话归正题，也是个很堂皇的答案， PIC 是为 ISA 设计的，不是为你 PCI 设计的。当然，你可以接 APIC ，不过在旧社会是没有它滴。旧社会， PCI 要接 PIC 。
ISA 中断和 PCI 中断最大的不同在哪儿？ ISA 是上升沿触发的（ low-to-high edge
sensitive ）， PCI 是低电平有效、电平触发的 (active low, level sensitive) 。（我们不要那么麻烦，
记住 ISA 是 edge 触发， PCI 是 level 触发就好了）。 PCI 要接 PIC ，就需要把 level 触发转换
成 edge 触发。本章介绍 PCI 中断转 ISA 中断协议，它是中断路由可以产生的基础（中断路
由见下一章）。

作者: zx_wing 时间: 2008-05-30 11:53

原帖由 minifish 于 2008-5-30 10:08 发表
问一个傻B的问题，为什么要把PCI的中断转成ISA中断？
PCI中断是active low, level triggered，ISA中断是edge triggered.
PIC是可以接受level中断的，只是要求active high
因为这个对PCI中断进行转换是必要的 ...

我想可能有两个方面的问题吧。第一是这篇文献很早，当时用的PIC还不是我们现在用的8259，能不能接收level中断还不清楚
第二是PCI转isa可能要和其它ISA中断共用一个管脚，如果一个是level一个是edge，是否edge的信号就湮没在level的电平中了呢？

作者: minifish 时间: 2008-05-30 16:26

原帖由 zx_wing 于 2008-5-30 11:53 发表

我想可能有两个方面的问题吧。第一是这篇文献很早，当时用的PIC还不是我们现在用的8259，能不能接收level中断还不清楚
第二是PCI转isa可能要和其它ISA中断共用一个管脚，如果一个是level一个是edge，是否edg ...

第一个应该很可能，建议文章里面提一下？会不会让大家都误认为现在的8259还是那样子。
第二个我觉得不可能，ISA的edge中断是不共享的，更不会跟PCI转过来的ISA中断共享了。

作者: zx_wing 时间: 2008-05-30 18:46

原帖由 minifish 于 2008-5-30 16:26 发表

第一个应该很可能，建议文章里面提一下？会不会让大家都误认为现在的8259还是那样子。
第二个我觉得不可能，ISA的edge中断是不共享的，更不会跟PCI转过来的ISA中断共享了。

第二个会哈，MP spec明确规定了中断路由ISA edge中断和PCI中断转edge中断共享的情况。
ISA中断能不能共享看设备实现，没有定论的哈

作者: minifish 时间: 2008-05-30 20:14

原帖由 zx_wing 于 2008-5-30 18:46 发表

第二个会哈，MP spec明确规定了中断路由ISA edge中断和PCI中断转edge中断共享的情况。
ISA中断能不能共享看设备实现，没有定论的哈

这样子啊，有空去看看，MP Spec没有过时吧？

作者: minifish 时间: 2008-05-30 20:38

原帖由 minifish 于 2008-5-30 20:14 发表

这样子啊，有空去看看，MP Spec没有过时吧？

wing兄

，在什么地方？没找到啊
另外，我知道edge中断可以共享，但是ISA毕竟不强制中断共享，那么你就不能假定他们可以共享。

作者: zx_wing 时间: 2008-05-30 20:50

原帖由 minifish 于 2008-5-30 20:38 发表

wing兄，在什么地方？没找到啊
另外，我知道edge中断可以共享，但是ISA毕竟不强制中断共享，那么你就不能假定他们可以共享。

MP spec附录D，D1.2，Fixed interrupt routing第一种情况

作者: minifish 时间: 2008-05-30 21:39

原帖由 zx_wing 于 2008-5-30 20:50 发表

MP spec附录D，D1.2，Fixed interrupt routing第一种情况

嗯，不是看到，还真是有点不能相信。
那么现在PCI-to-ISA 还在吗？

作者: zx_wing 时间: 2008-05-30 21:46

原帖由 minifish 于 2008-5-30 21:39 发表

嗯，不是看到，还真是有点不能相信。
那么现在PCI-to-ISA 还在吗？

这个就要问造板子的了。
你看有没有认识做BIOS的，他们对这个理解的清楚些。

作者: minifish 时间: 2008-05-30 21:59

原帖由 zx_wing 于 2008-5-30 21:46 发表

这个就要问造板子的了。
你看有没有认识做BIOS的，他们对这个理解的清楚些。

那个根据MP Spec，如果那个ISA设备不支持shared interrupt，哪该怎么办呢？

作者: zx_wing 时间: 2008-05-30 22:10

原帖由 minifish 于 2008-5-30 21:59 发表

那个根据MP Spec，如果那个ISA设备不支持shared interrupt，哪该怎么办呢？

这个问题我想过，也不知道。我在文章中也提到了，完全可以路由到一个没有ISA设备的管脚。这个完全是实现确定的

作者: incle 时间: 2008-06-05 16:26
先看再发表意见和问题.

作者: jn200002 时间: 2008-06-06 16:44
汗,名称能看懂,但是其他都甍的,下下来,有一天估计能看懂吧......

作者: albcamus 时间: 2008-06-06 17:07

原帖由 jn200002 于 2008-6-6 16:44 发表
汗,名称能看懂,但是其他都甍的,下下来,有一天估计能看懂吧......

x86就是这个德性，博大精深谈不上，就是跟软件工程师死嗑！慢慢嗑吧…

我得找个时间好好读一遍，这还一直没看呢

作者: gamania 时间: 2008-06-30 19:13
支持楼主，谢谢辛苦劳动

作者: eraser2008cn 时间: 2008-07-18 13:36
顶牛人一个!

作者: b0rder 时间: 2008-08-24 00:24
辛苦了。
拜读中。。。

作者: Kallawa 时间: 2008-08-27 00:27
thx

作者: Godbach 时间: 2008-08-27 09:40
谢谢zw_xing兄的好文章，下下来，拜读之。

作者: xtdumpling 时间: 2008-12-12 15:22
谢谢!!

作者: foxwolf 时间: 2008-12-17 17:29
好久没回CU了，好文大家共享。

作者: cwtkang 时间: 2009-05-21 15:20
我用加载内核模块的方法注册系统中断，但是我找到的资料都是Linux2.4下的，可我们的电脑现在都是Linux2.6的，根本就不能成功，哎～～～郁闷呀，大虾能给下指导么？

作者: xiangzhenlin 时间: 2009-07-28 10:19
楼主辛苦了哈，下来看看！

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)

日期	版本	描述
2008.5.3	1.1	Ÿ 根据 albcamus 同学的建议，修改了文中多处错误 Ÿ 根据Bluesky_jxc同学的补充，修改了edge中断共享与丢失的内容 Ÿ Bluesky_jxc同学补充了PIRQ Table章节
2008.4.27	1.0	最初发表版本