跟distributor連接的部分就不說了。Cpu_active是指示cluster或core的狀態，可以用于idle管理。ppi_id用于多核設計時，區分每個redistributor。PPIs就是PPI中斷線

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

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

stream協議接口由于是雙向，所以是兩組信號

redistributor到CPU的信號

CPU到redistributor的信號

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

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

GIC-600的ITS組件

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

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

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

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

當外設寫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上。同理，對于并發程序也是有好處的。