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

bluesky_jxc

我們說的應(yīng)該不是一個(gè)東西

你說的是類似網(wǎng)絡(luò)驅(qū)動(dòng)中NAPI的工作方式，例如Gbit 的網(wǎng)卡等，因?yàn)橄鄬?duì)這種產(chǎn)生中斷的速度，中斷切換的開銷就很大了，因此有一種叫做“半輪詢”的機(jī)制來減輕這種問題，可能就是你說的，一次中斷切換處理很多isr。

我說的是指對(duì)共享isr的處理，在遍歷action鏈表的時(shí)候，是“只要遇到一個(gè)合適的isr”就返回呢，還是“不管發(fā)生什么情形，都遍歷整個(gè)isr鏈表”。

不是說一個(gè)東西，討論不出來啥新鮮玩意兒

zx_wing

暈，bluesky_jxc你想叉啦，這里講的中斷批處理和中斷共享的chain沒啥關(guān)系。
其次中斷共享每次遍歷鏈表，也要鏈表里有多個(gè)handler時(shí)才會(huì)嘛，如果沒共享不是還是只有一個(gè)handler。
dengcain的理解是對(duì)的哈
PS：windows如何做的？我買了那本書卻一直還沒看到中斷那章。但我這里有篇微軟的文章，從中看出windows用的也是類似的方式。
這篇文章講中斷共享的害處，寫的非常好，推薦
http://www.microsoft.com/taiwan/whdc/archive/apic.mspx

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

bluesky_jxc

看貼不仔細(xì)哈。

誰說只有一個(gè)handler？

我的意思是，“很多”設(shè)備共享中斷，“很多”handler，但是每次“只有一個(gè)”設(shè)備發(fā)送中斷的情形！

albcamus

沒看完，也沒看仔細(xì)，等抽時(shí)間細(xì)看。  AFAICT， 這份文檔的深度、廣度以及歷史追溯上，是至少我前所未見的。


一些商榷的地方（邊看邊發(fā)）
-------------------------
P9:

>> APIC Bus 已經(jīng)不存在,系統(tǒng)的前端總線代替了它。
APIC Bus已經(jīng)不存在了， 取而代之的是， LAPIC之間、LAPIC和IOAPIC之間的通信，通過前端總線來傳遞。


P10:

>>  當(dāng) IOAPIC 某個(gè)管腳接收到中斷信號(hào)后,會(huì)根據(jù)該管腳對(duì)應(yīng)的 RTE,格式化出一條中
>>  斷消息,發(fā)送給某個(gè) CPU 的 LAPIC。

嚴(yán)謹(jǐn)起見，「發(fā)送給某個(gè)CPU」應(yīng)改為「發(fā)送給某個(gè)或某些CPU」


P13:
>> X86 spec 說 4bit 的 LAPIC ID 可 以 表 示 15 個(gè) CPU , 還 有 一 個(gè) 哪 兒 去 了 ? 我 想 是 留 給
IOAPIC 了。

對(duì)Pentium和P6家族CPU來說， APIC ID == 0x0f是廣播ID，即匹配所有的LAPICs。

手冊(cè)卷III，8.6.2.1 Physical Destination Mode節(jié)說：
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 個(gè)管腳,GSI base 為 24,GSI 范圍為[24,39],依次類推。

這里應(yīng)該是IOAPIC1吧？

P25:
>>     筆者:每個(gè) CPU 都用同樣的物理地址訪問自己的 LAPIC。這說明除了 x86 平臺(tái)的 port
I/O 具有 64K 獨(dú)立的物理地址空間外,LAPIC 也擁有獨(dú)立的物理地址。我能想到的理由是
防止 CPU 訪問不屬于自己的 LAPIC。


不同意這種觀點(diǎn)。 CPU以I/O指令訪問IO ports，無論如何，是要走總線的； 而訪問自己的LAPIC，
無論如何，都不需要走總線，而是由CPU(BIU單元?)和LAPIC以及鏈結(jié)它們的硬件(不管是什么)來保證的。

當(dāng)然，我這也是猜測^_^


P26:
>>      該表用于重載 MADT 表頭中的 LAPIC 地址,整個(gè) MADT 表中只應(yīng)該包含一個(gè) LAPIC
address override entry。

建議補(bǔ)充一句(我覺得不補(bǔ)充很多人會(huì)糊涂):
之所以提供LAPIC address override entry，是因?yàn)樵趚86-64 CPU上物理抵制是64位的，
因此原來的4字節(jié)--也就是32位--的LAPIC物理地址是無效的，因此用這樣一個(gè)override機(jī)制來提供一個(gè)8字節(jié)
的LAPIC物理地址。

FIXME: 為什么IO-APIC不需要提供address override entry？ 64位機(jī)器上的IOAPIC地址也是32位的？


P29:
>>            筆者:從 Linux 的注釋來看,TPR 將一直為 0。X86 spec 有這么一段話:
“ 對(duì) 于 使 用 lowest priority delivery mode 發(fā) 送 中 斷 , 卻 又 不 更 新 TPR 的
OS,芯片組將記憶 TPR 并將同一中斷發(fā)送給同樣的 CPU 處理。這將引起性
能損失”。

Mark一下，我也注意到了這句話，似乎Andi Kleen曾經(jīng)在lkml上解釋過，明天找找

albcamus

原帖由 zx_wing 于 2008-4-29 11:53 發(fā)表

好建議。我也打算更新后在里面加Revision History，但第一版從哪個(gè)版本號(hào)開始呢

從哪個(gè)版本號(hào)開始，你說了算丫

還有，如果能加上參考文獻(xiàn)就更好了^_^     這將是一份被廣泛引用的文檔

zx_wing

老大看的真仔細(xì)，感動(dòng)！

>> APIC Bus 已經(jīng)不存在,系統(tǒng)的前端總線代替了它。
>>APIC Bus已經(jīng)不存在了， 取而代之的是， LAPIC之間、LAPIC和IOAPIC之間的通信，通過前端總線來傳遞。
同意，馬上修改

>>  當(dāng) IOAPIC 某個(gè)管腳接收到中斷信號(hào)后,會(huì)根據(jù)該管腳對(duì)應(yīng)的 RTE,格式化出一條中
>>  斷消息,發(fā)送給某個(gè) CPU 的 LAPIC。

>>嚴(yán)謹(jǐn)起見，「發(fā)送給某個(gè)CPU」應(yīng)改為「發(fā)送給某個(gè)或某些CPU」
同意，馬上修改


>> X86 spec 說 4bit 的 LAPIC ID 可 以 表 示 15 個(gè) CPU , 還 有 一 個(gè) 哪 兒 去 了 ? 我 想 是 留 給
>>IOAPIC 了。

>>對(duì)Pentium和P6家族CPU來說， APIC ID == 0x0f是廣播ID，即匹配所有的LAPICs。

慚愧，馬上修改。


>>         IOAPIC2 有 16 個(gè)管腳,GSI base 為 24,GSI 范圍為[24,39],依次類推。

>>這里應(yīng)該是IOAPIC1吧？
對(duì)，馬上改


>>     筆者:每個(gè) CPU 都用同樣的物理地址訪問自己的 LAPIC。這說明除了 x86 平臺(tái)的 port
>>I/O 具有 64K 獨(dú)立的物理地址空間外,LAPIC 也擁有獨(dú)立的物理地址。我能想到的理由是
>>防止 CPU 訪問不屬于自己的 LAPIC。


>>不同意這種觀點(diǎn)。 CPU以I/O指令訪問IO ports，無論如何，是要走總線的； 而訪問自己的LAPIC，
>>無論如何，都不需要走總線，而是由CPU(BIU單元?)和LAPIC以及鏈結(jié)它們的硬件(不管是什么)來保證的。
這個(gè)需不需要走總線還真不好說。從實(shí)現(xiàn)上來說，它可以發(fā)到總線上，最后訪問到自己。也可以不發(fā)到總線上。
就像self IPI一樣，實(shí)現(xiàn)可以廣播到總線再發(fā)給自己，也可以不廣播。取決于具體實(shí)現(xiàn)。
這個(gè)地方主要是想強(qiáng)調(diào)LAPIC 地址和IO地址一樣屬于獨(dú)立地址空間。



>>      該表用于重載 MADT 表頭中的 LAPIC 地址,整個(gè) MADT 表中只應(yīng)該包含一個(gè) LAPIC
>>address override entry。

>>建議補(bǔ)充一句(我覺得不補(bǔ)充很多人會(huì)糊涂):
>>之所以提供LAPIC address override entry，是因?yàn)樵趚86-64 CPU上物理抵制是64位的，
>>因此原來的4字節(jié)--也就是32位--的LAPIC物理地址是無效的，因此用這樣一個(gè)override機(jī)制來提供一個(gè)8字節(jié)
>>的LAPIC物理地址。
>>FIXME: 為什么IO-APIC不需要提供address override entry？ 64位機(jī)器上的IOAPIC地址也是32位的？
說實(shí)話，我還真沒想到重載地址是為了32bit到64bit平臺(tái)。但是為啥64bit平臺(tái)上不能用32bit地址？是不是因?yàn)橄鄬?duì)于CPU的物理地址空間，LAPIC地址需要在一個(gè)相對(duì)固定的地方？

>>            筆者:從 Linux 的注釋來看,TPR 將一直為 0。X86 spec 有這么一段話:
“ 對(duì) 于 使 用 lowest priority delivery mode 發(fā) 送 中 斷 , 卻 又 不 更 新 TPR 的
OS,芯片組將記憶 TPR 并將同一中斷發(fā)送給同樣的 CPU 處理。這將引起性
能損失”。

>>Mark一下，我也注意到了這句話，似乎Andi Kleen曾經(jīng)在lkml上解釋過，明天找找
好的，等待結(jié)果哈：）


bluesky_jxc同學(xué)在幫我補(bǔ)充PIRQ table的內(nèi)容，我先把這些修改加上去，加上版本號(hào)。等他寫完了，一并更新發(fā)上來。
PS:我要到版務(wù)去申請(qǐng)能不能給論壇加一個(gè)像郵件那種，一回復(fù)自動(dòng)在頭上加“>>”的功能，自己打太麻煩了。

albcamus

原帖由 zx_wing 于 2008-4-30 11:47 發(fā)表
PS:我要到版務(wù)去申請(qǐng)能不能給論壇加一個(gè)像郵件那種，一回復(fù)自動(dòng)在頭上加“>>”的功能，自己打太麻煩了。

firefox有個(gè)插件，叫it's all text!，可以在文本輸入框的右下角浮現(xiàn)一個(gè)「edit」圖標(biāo)，用自己喜歡的編輯器編輯，我用gvim。

不過這個(gè)插件還是不爽，我喜歡可以指定命令的，那樣就可以指定為konsole -e vim來編輯了^_^

flw2

支持！打印出來了

minifish

牛蛙的超牛作品，頂！
順便問一個(gè)弱智問題：
你說的那個(gè)IMR置位的情況下，仍然會(huì)IRR有效，是從哪里看到的？
還有對(duì)于Edge中斷，IO-APIC和Local APIC各自會(huì)pending一個(gè)，這個(gè)是從哪里看到的？

bluesky_jxc

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中斷在下面情況下才會(huì)pending2個(gè)：
1.當(dāng)前某一個(gè)edge中斷在服務(wù)，這個(gè)時(shí)候IRR清空，ISR置位
2.還沒有服務(wù)完成（未寫EOI），同一個(gè)中斷發(fā)生，IRR置位

這個(gè)時(shí)候，IRR和ISR就同時(shí)置位。

在使用AEOI的時(shí)候也可能會(huì)出現(xiàn)這種情形，在第一個(gè)INTA和第二個(gè)INTA之間
如果有同類型的中斷發(fā)生，也會(huì)出現(xiàn)同時(shí)兩個(gè)寄存器置位。