Armv8下request_irq注册成功但触发时提示Unexpected interrupt received问题求助

出现Unexpected interrupt received!警告的核心原因是Linux内核的GICv3中断处理逻辑未找到该中断对应的有效处理路径，具体可能由以下几点导致：

• 共享中断未指定触发类型：使用IRQF_SHARED标志时，必须明确指定中断触发类型（电平/边沿），否则内核无法正确匹配共享中断的处理函数，导致中断被判定为未处理。
• 中断处理函数返回值错误：如果irq_handler返回IRQ_NONE，内核会认为该中断不属于当前注册的处理函数，进而抛出警告。
• EL2中断注入参数不匹配：
  • 中断编号不对应：EL2注入的硬件中断编号与内核注册的逻辑中断编号不一致；
  • 中断分组配置错误：GICv3中若中断被设为Group0（归属EL2或安全EL1），非安全EL1的Linux内核无法处理；
  • 触发类型不匹配：EL2注入的中断触发方式与内核注册时的设置不一致。
• 中断未正确启用：即使调用了request_irq，若EL2未将该中断路由开放给EL1，或GIC寄存器中未启用该中断，内核仍无法处理。

针对上述原因，可按以下步骤排查修复：

1. 修正request_irq调用，补充触发类型
   使用IRQF_SHARED时必须指定触发类型，根据实际需求选择（如高电平触发）：

   err = request_irq(40, irq_handler, IRQF_SHARED | IRQF_TRIGGER_HIGH, "hvisor", &hvisor_misc_dev);
   

   可选触发类型包括IRQF_TRIGGER_RISING、IRQF_TRIGGER_FALLING、IRQF_TRIGGER_LOW等。

2. 检查中断处理函数的返回值
   确保处理完成后返回IRQ_HANDLED，仅当确认不是当前处理函数的中断时才返回IRQ_NONE：

   static irqreturn_t irq_handler(int irq, void *dev_id) {
       // 执行中断处理逻辑
       return IRQ_HANDLED;
   }
   

3. 验证EL2中断注入的正确性

   • 确认中断编号对应关系：GICv3中SPI中断的内核逻辑编号 = SPI硬件偏移 + 32（GIC_SPI_BASE），比如SPI硬件编号8对应内核irq 40，确保EL2注入的是该编号的SPI中断；
   • 将中断配置为Group1：在EL2中修改GICD_IGROUPR寄存器，将该中断的分组设为Group1，允许非安全EL1的Linux内核处理；
   • 确保注入的触发类型与内核注册时指定的一致。

4. 检查GIC中断启用状态

   • 通过cat /proc/interrupts查看irq 40的触发计数，确认是否有中断到达；
   • 调试查看GICD_ISENABLER寄存器，确认对应中断位已置位；若未置位，可手动通过enable_irq(40)强制启用。

内容的提问来源于stack exchange，提问作者Korwy Lee