接下來該看redistributor了。

圖1 GIC-600 redistributor

跟distributor連接的部分就不說了。Cpu\_active是指示cluster或core的狀態，可以用于idle管理。ppi\_id用于多核設計時，區分每個redistributor。PPIs就是PPI中斷線，在GIC-600是這么描述PPI的：

圖2 PPI描述

從上面可以看出來，所謂的“私有”是說這些中斷信號是core專有的。對于PPI，ARMv8定義了三種規格，8，12和16。所以對于不同的core來說，可能PPI數量不一樣。

圖3Generic timer

上面是ARMv8-A的架構spec里，關于timer的圖。我們可以看到，core的timer會發PPI，而中斷控制器返回FIQ或者IRQ給core。細心的同學可能會問了，在redistributor上面沒有FIQ和IRQ的信號啊？其實在第一篇文章里就說了，在現有的GICv3架構下，關于中斷FIQ和IRQ，以及系統寄存器等放在了cluster/core端，對外留出了一組接口，叫cpu interface（在GICv2中實現在中斷控制器這一側），也就是圖1中最下面的接口。其實這是一組簡化的AXI4-Stream。

圖4 GIC stream協議接口

由于是雙向，所以是兩組信號

圖5redistributor到CPU的信號

圖6 CPU到redistributor的信號

既然是簡化的總線協議，為了更便于CPU和redistributor通信，ARM又規定了具體的數據包格式。下圖是CPU端發出的命令格式，具體的解釋請查閱GICv3的文檔，此處就不過多的貼圖了。

圖7 CPU interface命令

至此，就剩下最復雜的ITS了，這一部分是為了實現基于消息的中斷。前面介紹過，LPI是一種基于消息的中斷。也就是中斷信息不在通過中斷線進行傳遞。ITS就是要將接收到的LPI中斷進行解析。

圖8 GIC-600的ITS組件

既然是信息中斷，就一定要有區分這些中斷的方法，這樣才能找到合適的中斷處理對策。所以這里有兩個概念。

EventID，用來表示外設發送中斷的事件類型

DeviceID，用來表示哪一個外設發起LPI

而ITS需要將外設發送的DeviceID，eventID，通過一系列查表，得到LPI的中斷號，再使用LPI中斷號查表得到該中斷的目標CPU。為此，ITS需要維護幾張表，分別是device table，interrupt translation tableh和collection。

圖9 ITS表

當外設寫GITS\_TRANSLATER寄存器，產生了LPI。這時ITS首先要拿著DeviceID，從device table中選擇索引為DeviceID的表項。從該表項中，得到interrupt translation table的位置；然后再根據EventID，從interrupt translation table中選擇索引為EventID的表項。得到中斷號，以及中斷所屬的collection號；最后，使用collection號，從collection table中，選擇索引為collection號的表項。得到redistributor的映射信息，最后根據collection表項的映射信息，將中斷信息路由發送給對應的redistributor。

最后，提一句，GICv3中開始支持親和性路由（affinity routing）。請原諒我偷點懶，直接把文檔中的部分貼出來：

這里要解釋一下什么是親和性，我最初接觸這個概念的時候簡直是一頭霧水，直到有一天看操作系統相關的書才明白是咋回事（忽略我的無知吧~~）。CPU親和性是一種調度屬性(scheduler property)，Linux調度器會根據affinity的設置讓指定的進程運行在"綁定"的CPU上，而不會在別的CPU上運行。其中有一個好處是，可以提高cache的命中率。當一個進程在某個CPU上運行時，會在該CPU的緩存中維護許多狀態。下次該進程在相同的CPU上運行時，由于緩存中的數據而執行的更快。

因此，多處理器的調度器應該考慮這種親和性，盡可能的進程保持在同一個CPU上。同理，對于并發程序也是有好處的。感慨一下，做CPU設計，到了最后肯定要與操作系統相愛相殺，哈哈哈~~~

審核編輯：劉清