自学内容网 自学内容网

Linux中断 -- 中断应答、嵌套、

接上文,本文继续介绍Linux软件部分逻辑。

参考内核版本:kernel-4.19

目录

1.中断信号在各级中断控制器中的应答

2.supports_deactivate_key意义

3.中断嵌套


1.中断信号在各级中断控制器中的应答

        本章主要从内核软件层面来看各中断控制器对中断信号处理&应答(关于硬件层面的处理硬件过程可以参考前文)。同样使用前文中GICv3 & PIO 中断控制器为硬件框架,介绍PIO接受到外部中断时软件层各控制器的应答(文中设定supports_deactivate_key 为false)。

        如下图触发中断(EL1 、SPI类型)后软件通过操作硬件中断控制器对中断应答操作(卷尺框图):

        #1.读取GICv3中断控制器的IAR(中断应答寄存器)获取GIC的硬件中断号

        #2.通过PIO中断控制器mask&ack对应中断;

        #3.通过PIO中断控制器unmask对应中断;

        #4.操作GICv3中断控制器EOI寄存器,标记该GIC中断为deactivted并回退GIC的中优先级

从 #2、#3代码上逻辑上看一推出:

        a.因在执行该中断的处理handle时,PIO中断控制器上mask该中断故认为该中断在该CPU不               能实现中断嵌套;

        b.对于GIC已经通过IAR寄存器响应了来自PIO的中断,则处理该中断的CPU不能相应低于PIO            中断优先级的中断;

2.supports_deactivate_key意义

        supports_deactivate_key 是用指示GIC采用 ICC_CTLR_ELn.EOImode的形式(mode0或者mode1),值为true时表示采用mode1即EOI寄存器被置位时只是回退到该中断处理的前的优先级、需要再操作DIR寄存器将当前中断状态切换到非激活状态,值为false时表示采用mode0即操作EOI寄存器就会完成优先级回退和切换该中断到非激活状态。GICv3的驱动代码可以明确体现上述逻辑:

static void gic_cpu_sys_reg_init(void)
{
    …

    if (static_branch_likely(&supports_deactivate_key)) {

        /*当supports_deactivate_key使能时配置为EOI为mode1形式*/
        gic_write_ctlr(ICC_CTLR_EL1_EOImode_drop);

    } else {

        /*当supports_deactivate_key使能时配置为EOI为mode0形式*/
        gic_write_ctlr(ICC_CTLR_EL1_EOImode_drop_dir);

    }

    …
}

        supports_deactivate_key的值与hyp mode(Arm的虚拟化模式),默认值为ture当判定hyp mode未使能时则设置该置为false。代码逻辑如下:

static int __init gic_init_bases(void __iomem *dist_base,
 struct redist_region *rdist_regs,
 u32 nr_redist_regions,
 u64 redist_stride,
 struct fwnode_handle *handle)
{
    …

    /*hyp mode未使能,设置supports_deactivate_key为false*/
    if (!is_hyp_mode_available())
        static_branch_disable(&supports_deactivate_key);

    /*supports_deactivate_key值为true时,表示EOL & Deactivate 分开处理*/
    if (static_branch_likely(&supports_deactivate_key))
        pr_info("GIC: Using split EOI/Deactivate mode\n");

    …
}
3.中断嵌套

         据说是从kernel-2.6.34开始不支持。其实内核中有很多代码都可以证明不支持中断嵌套处理逻辑,如下便是一例作证:

static int __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
{
    /*
*  request_irq() -> __setup_irq()
*  如下当irq设置 IRQ_NESTED_THREAD 支持嵌套中断属性时,如果注册的中断处理无thread_fn
    *  函数时支持返回中断注册EINVAL错误.
*  如果有注册thread_fn则将中断handle处理函数设置为irq_nested_primary_handler,
    *  因为irq_nested_primary_handler函数直接返回IRQ_NONE,则thread_fn也无法得到执行。
    *  故支持中断嵌套处理的函数不能得到处理,所以Linu内核不支持嵌套中断。
*/

/*
 * Check whether the interrupt nests into another interrupt
 * thread.
 */
nested = irq_settings_is_nested_thread(desc);
if (nested) {
if (!new->thread_fn) {
ret = -EINVAL;
goto out_mput;
}
/*
 * Replace the primary handler which was provided from
 * the driver for non nested interrupt handling by the
 * dummy function which warns when called.
 */
new->handler = irq_nested_primary_handler;
    ...
}

        另外从处理器硬件层面也限制了中断嵌套处理的可能。如下ARM异常处理的文档中描述:当处理器捕获到异常并进入异常处理状态时,该处理器的PSTATE.DAIF中断掩码被自动设置,也是说该处理不能再响应对应的异常处理。当完成异常处理时,系统通过调用eret指令完成PSTATE状态和被中断指令地址的恢复,即同时恢复了PSTATE.DAIF状态,可能把当前处理器从异常中断状态恢复出来。

        在系统进行IRQ异常处理的过程中,可能有局部使能或者关闭(local_irq_enable/local_irq_disable)当前CPU IRQ的行为,如:bottom half处理的softirq& tasklet处理过程,会使能当前CPU的IRQ但也会进行成对的关闭行为(这点符合局部对称的设计要要求);但因为softirq阶段有短暂的使能本地中断行为,所以在中断的bottom half阶段可能有高优先级的中断被路由到当前CPU导致中断嵌套。

        总结:当前内核不支持top half阶段的中断的嵌套,支持bottom half阶段的中断嵌套。


原文地址:https://blog.csdn.net/hello_yj/article/details/135467724

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!