ver0.1
前言
我们在观看很多的影视剧过程中，尤其是军旅体裁类型的布景中，经常会看见高级干部的办公桌上都会有几部电话机。这样的电话可不能小看，重要的事情尤其是突发和紧急的情况都要通过这几部电话第一时间通知给决策者。这几部电话，必须举报几个特点：及时性好、稳定性好、私密性好、传递的信息重要性高。
当然生活中的决策者一般都是重要组织的高级Leader，那些电话离我们普通人也很远。对于码农来说，计算机才是我们的世界。这个世界中也有一个地位无与伦比的决策者，SOC世界中的Leader，那就是CPU。那这个世界中的电话就是我们接下来要讨论的主题-GIC(通用中断控制器)。
研究GIC的目的还是为了研究虚拟化技术打下基础，中断的虚拟化也是虚拟化技术领域的重要基础之一，Hypervisor自己不想多干活就要好好的利用硬件提供的辅助能力。在ARM体系下，中断属于异常模型的范畴，所以大家在阅读本文之前，还是建议提前看看前序文章建立起对异常的基本感觉：
(1) [V-05] 虚拟化基础-异常模型(Exception)(AArch64)
正文
1.1 中断的背景
独木不成林，SOC的世界中不能只有CPU，还需要搭配各种各样的设备才能构成有价值的功能单元，必要的时候还需要通过接口扩展，链接进来更多的外部设备，如图1-1。
到这里，我们已经帮助CPU配置齐了一套设备，下一步就要考虑如何管理这些设备了。考虑下面一种场景，CPU分配了一块显存交给GPU去渲染，GPU接到指令后自然是不敢怠慢，加班加点的干活。当GPU完了CPU交办的渲染任务之后，自然是要向CPU复命的。那么问题来了，GPU要怎么通知CPU它已经干完活了呢？或者说，CPU要怎么知道GPU当前的渲染状态呢？你也许会说，CPU直接去问一下GPU不就行行了吗？事实上还真有这种方式，通过CPU主动查询的方式。GPU可以和CPU提前做好约定，例如在GPU的IO空间中分配一个寄存器，GPU可以在工作的过程中更新这个寄存器的状态，CPU可以在想要的时候不断的去读取GPU这个寄存器的状态。这样做法看似简单，实则一点也不难。只是这么个搞法会有一个效率的问题：
(1) CPU到底要啥时候去访问这个GPU的寄存器啊? 早了吧，GPU可能还没有干完活，CPU白跑一趟。晚了吧，GPU可能早就干完了，CPU白等了好长时间。
(2) 设个定时查询的机制，让CPU不断的轮询行不行呢？也不行的，因为同样会浪费很多CPU的时间片资源。就比如说，到底定时多长时间去轮询一次啊，这个值就不好确定。
似乎看上去CPU主动去查询的方式效率不高，处理不当会造成很大的CPU资源浪费。这个方向不行，就换一个方向考虑问题，让设备通知CPU就可以了。还是以GPU为例，CPU交办的任务是否完成了、完成的进度如何、实施的过程中是否有问题，只有GPU自己最了解情况，因此让GPU主动通知GPU是比较合理的处理方式了。这样CPU该干啥干啥，只是需要的时候由设备发起通知让CPU介入处理一下就可以了，双方都很满意。这种由设备主动发起通知CPU的行为就称为
