Arm GIC-v3中断原理及验证（通过kvm-unit-tests）

一、参考连接

gic-v3相关原理可参考https://zhuanlan.zhihu.com/p/520133301

本文主要通过开源测试工具kvm-unit-tests，针对GIC的中断进行一系列验证，这样可以直入中断底层，熟悉整个原理。

kvm-unit-tests官网为kvm-unit-tests / KVM-Unit-Tests · GitLab

armv8寄存器介绍官网为Documentation – Arm Developer

二、中断验证

        GIC的中断主要为四类，即SGI（IPI）、PPI、SPI、LPI，本文主要针对这四类进行验证。具体原理将在验证中随意阐述。总体来看kvm-unit-tests源码的理解难度要低于kernel源码，所以方便引用，其实底层逻辑其实是一样的。

        GIC总计结构：

        GIC中断分布：

中断类型	中断号	说明
SGI	0 - 15
PPI	16 – 31
SPI	32 - 1019
特殊中断号	1020 - 1023
保留中断号	1024 - 1055
扩展PPI	1056 -1119	GICv3.1版本后才支持
保留中断号	1120 - 4095
扩展SPI	4096 - 5119	GICv3.1版本后才支持
保留中断号	5120 - 8191
LPI	8192 -	最大支持的中断号由实现确定

        先来整体看下一个机器中断的整体分布，我是在VM中：

        再来看个kvm-unit-tests的整体测试吧，就当留个印象。

2.1 SGI（software generated interrupt）（IPI）[0-15] 中断验证

       该类型中断并没有实际的物理连线，而是由软件通过写寄存器方式触发，它只支持边沿触发。通常用于处理器之间的通信，如linux内核电源管理模块中调用的ipi中断就是通过SGI实现的。

        IPI即核间中断，arm的叫sgi。

        kvm-unit-tests（本文以后简称k-u-t）中正好有专门的SGI检测项，可以通过总体测试然后log输出，也可以单独加参数测试验证：

2.1.1中断发送

发送中断的本质其实，从软件层面来讲，其实就是写寄存器。发送SGI中断的步骤归纳如下：

1. 通过GICR_ISENABLER0寄存器设置中断使能
2. 通过GICR_IPRIORITYR<n>设置优先级
3. 写寄存器 GICD_SGI1R
4. 写寄存器 ICC_SGI1R_EL1

kut中关于发送sgi中断的函数是lib/arm/gic-v3.c中的gicv3_ipi_send_mask()函数（可类比kernel-5.10中的gic_ipi_send_mask函数），

再看下写入到寄存器ICC_SGI1R_EL1中的值，以及spec中规定的ICC_SGI1R_EL1各字段含义：

嗯，只能说是一模一样。所以这就是软件层面发送sgi中断的最终操作，剩下的就是硬件层面的事了。

类比kernel-5.10中sgi中断发送代码的调用路径是：

        gic_ipi_send_mask-->gic_send_sgi-->gic_write_sgi1r

其实除了逻辑更复杂了，整体框架都一样。

2.1.2中断接收处理

接收中断的处理函数是arm/gic.c中的irq_handler()，这个函数基本上总结了所以中断handler的模板：

所以中断处理的一般步骤就是：

1. 读取iar寄存器，获取到描述irq的结构体irq_data;
2. 通过irq_data获取到irq_num；
3. 具体的中断处理；
4. 回写eoi寄存器，中断结束。

kut因为只是模拟测试，所以中断handler比较简单，具体的sgi中断处理只是简单的记录信息，如ack[cpuid]++;表示本cpu接收到了中断。

2.1.3kut中sgi测试总体逻辑

由于讲述中断，所以直接开讲的中断发送以及中断处理，其实是倒叙看源码了。正序应该是类似gdb似的从头开始。kut中每个test-case都有一个main函数，当我们独立测试某一项时，如测试gic的sgi中断，当我们命令行输入-append ipi时，就已经进入到sgi测试的主入口了，程序逻辑依次是：

至此，SGI中断的逻辑以及原理差不多可以了，反正就是触发SGI中断就写ICC_SGI1R_EL1寄存器，接收中断handler就是按标准步骤操作寄存器：读取iar，获取irq，逻辑处理，回写eoi。

2.2 PPI（private peripheral interrupt）[16-31] 中断验证

       该类型中断是每个处理器私有的，即一个特定的中断只会被路由到特定的处理器上。且其同一个中断号在每个处理器上都可以有不同的中断，如对于一个拥有两个PE的smp系统，中断号16的PPI中断可以分别被注册为PE0和PE1的私有中断，它们可以被独立触发并被特定的PE独立处理.

        kut中没有显示测试ppi的用例，但其中有个timer的测试用例，通过/proc/interrupt可以看出，timer的中断其实就是ppi的中断，毕竟每个cpu都会独立收到timer。所以直接测试kut中的timer一项即可，其中的打印为我自己加的补丁，可以看到timer的irq正好属于[16-31]这个PPI区间。

2.2.1中断发送

发送PPI中断的步骤归纳如下

1. 通过GICR_ISENABLER0寄存器设置中断使能
2. 通过GICR_IPRIORITYR<n>设置优先级
3. 写相应的寄存器（如timer的）

同样的，timer也有一大堆寄存器来控制，包括使能ctl、读写比较值cval、读写时间值tval、读count等。发中断就是设置其中的寄存器，然后等待时间到时（硬件计数）就可以了。

kut中关于timer中断的发送主要为test_timer的子函数 ，分别为 test_timer_cval-->test_cval_10msec(测试compare val寄存器);  test_timer_pending(测试timer中断);  test_timer_tval(测试time val寄存器);

相比而言，timer的寄存器字段较为简单，都不用像sgi寄存器那样显示组装各个field。

2.2.2中断接收处理

timer的接收中断的处理函数是arm/timer.c中的irq_handler()，定睛一看 似曾相识，不用多讲了吧。

唯一的中断处理逻辑就是置位irq_received = true; 这不比看kernel那一坨代码简洁多了。

2.2.3kut中ppi测试总体逻辑

话不多说，直接看图。简洁，太简洁了。

但其实除此之外，还有init的一大段，这个是所有test-case共有的，算作整个kut的初始化吧，ptimer和vtimer的中断号也是在init时从fdt读出来确定的，一开始的入口是arm/cstart.S中：

其中有个setup基本就是在给main铺路了，包括设置内存分布，各类设备初始化，堆栈空间初始化等等，基本看函数名就不用再注释了。

其中timer的irq就在timer_save_state的子函数timer_save_state_fdt中从fdt读出来并设置好，本次实验中的irq打印也是在此插桩。

所以到此，PPI中断也基本讲完了。其实还是老一套，发中断就是写某个寄存器触发某个事件（timer就是写cntp_tval，别的就写对应的reg），中断处理还是四步走。只不过PPI是换成了私有的private的，各个cpu都整了一套。

2.3 SPI（shared peripheral interrupt）[32 - 1019] 中断验证

        SPI中断不与特定的cpu绑定，可以根据affinity配置被路由到任意cpu或一组特定的cpu上。如一般的外设中断都是通过SPI方式连接的。

        kut中并没有看到专门的测试spi中断的test-case，误打误撞却发现kut中有个RTC设备pl031设备用的就是SPI，其中断号34正好属于这个区间，有了前面timer分析的基础，看懂这个rtc设备的发送中断以及中断处理简直是降维打击，读者朋友们自行去看吧，实在不用分析了。

        其实验证SPI中断我本来是想用串口uart-pl01这个设备的，奈何kut中没有对串口进行单独的test-case，而只是把它当作了标准输出stdio，如果重新写一个testcase的话倒也可以（看以后有没有时间即兴趣了），只是为了测试SPI而加用例，好像不太符合kut的目的。

所以暂时用之前的模拟串口来看吧，反正也能看出uart0中断处理，任意敲击按键，就能发现uart0的中断数++。原理其实是一样的，就是没有显示的代码去一行行验证了。其中

console1：

console2：

2.4 LPI（Locality-specific Peripheral Interrupt）[8192 - 具体实现决定max] 中断验证

        该类型中断是一种基于消息的中断，外设不需要通过硬件中断线连接到GIC上， 而可以向特定地址写入消息来触发中断。典型的应用为PCIe的MSI和MSI-X中断。
　　LPI中断有一些其特有的属性，如只支持non secure group1分组、只支持边沿触发、可以选择使用或不使用ITS路由，以及没有active状态，也不需要显式的deactivation操作。

        kvm-unit-tests中正好有专门的LPI检测项，其实就是ITS那一大堆测试，我就拿其中的一个its-trigger来讲解吧。