GIC内存地址禁止EL0访问的原因（0x9600000e 异常）
将GIC的内存地址配置为EL0不可访问，是ARM架构为了隔离用户态与内核态、确保系统安全与稳定所做出的基本设计。其根本原因在于权限分离和中断系统的安全模型。你遇到的0x9600000e异常，正是硬件在严格执行这条“隔离红线”。
🔒 为什么GIC内存地址要禁止EL0访问？
保护敏感的中断系统：GIC是系统的核心组件，直接管理所有中断的接收、优先级和分发。普通用户程序（EL0）如果能够直接操作它，可能通过恶意篡改GIC配置来屏蔽中断、提升自身权限，或引发严重的中断风暴，导致系统完全瘫痪。
遵循ARM的权限分离原则：ARM架构严格划分了EL0（非特权模式，运行应用程序）和EL1（特权模式，运行操作系统内核）。内核态负责管理包括中断在内的所有硬件资源，用户态程序必须通过“系统调用”这个唯一的、受监管的通道向内核请求服务。
🔍 异常0x9600000e的拆解与分析
当用户程序（EL0）尝试读写被设为EL0不可访问的GIC内存地址时，硬件会立即阻止这次越权访问，并触发一个“数据中止（Data Abort）”同步异常。这个异常会被路由到更高特权级的EL1，由内核的异常处理程序接手处理。
你所见到的异常值0x9600000e，可以拆解为两个关键部分：
高16位
0x9600：代表这是一个在EL0发生的同步数据中止（Data Abort）异常。其值模式0x960000xx明确指示了这一点。ARM架构中EC字段的值0b100101（即0x25）就表示此类异常。低8位
0x0e（对应二进制的0b001110）：这是数据故障状态码（DFSC），它精确指出了异常的根本原因。根据ARM架构手册的定义，0b001110（0x0e）的含义是“权限故障，级别 2”（Permission fault, level 2）。它明确告诉内核，异常源于内存的权限问题，而不是地址未映射之类的其他问题。
因此，0x9600000e这个值实际上是在向内核报告：“在用户态执行时，因访问权限不足而触发了数据中止”。这与你通过页表为EL0取消GIC访问权限的操作是完全吻合的。
💡 扩展：GIC的“后门”——系统寄存器接口
不过，ARM架构也考虑到了性能优化的需求，为GICv3提供了一个“系统寄存器接口”作为MMIO的替代。通过ICC_SRE_EL1寄存器可以启用它。
这个接口允许在特定条件下，从EL1甚至EL0访问GIC的CPU接口。例如，为了优化虚拟化场景下对GIC的访问性能，ICC_SRE_EL1寄存器提供了一个精确的控制位，可以用来选择EL0或EL1使用哪个接口（系统寄存器或MMIO）。
即使开启了系统寄存器接口，在标准的Linux内核配置中，也会通过SCTLR_EL1等系统寄存器的控制位，将关键的GIC系统寄存器访问权限严格限制在EL1。EL0访问这些特殊寄存器依然会触发未定义指令异常，这是一道更深层次的硬件防线。
📝 总结
权限是硬性规定：GIC的MMIO地址在页表中被标记为“EL0不可访问”，这是ARM架构强制要求的安全隔离基础。
异常是精确反馈：
0x9600000e这个异常值，是硬件对“EL0程序越权访问了没有权限的内存区域”这一事件的精确报告。安全是架构底线：这个机制确保了中断系统的安全、稳定运行，也维持了ARM权限模型的一致性。
因此，将GIC内存地址配置为EL0不可读写是安全稳定的基石。你所遇到的异常，是系统成功防御了一次非法的用户态访问。如果你希望实现用户态直接操作某些外设，需要检查该外设对应的内存区域属性是否允许EL0访问，而非修改GIC。