linux 中断管理机制

中断的概念

中断是指在CPU正常运行期间，由于内外部事件或由程序预先安排的事件引起的 CPU 暂时停止正在运行的程序，转而为该内部或外部事件或预先安排的事件服务的程序中去，服务完毕后再返回去继续运行被暂时中断的程序。Linux中通常分为外部中断（又叫硬件中断）和内部中断（又叫异常）。

软件对硬件进行配置后，软件期望等待硬件的某种状态（比如，收到了数据），这里有两种方式，一种是轮询（polling）： CPU 不断的去读硬件状态。另一种是当硬件完成某种事件后，给 CPU 一个中断，让 CPU 停下手上的事情，去处理这个中断。很显然，中断的交互方式提高了系统的吞吐。

当 CPU 收到一个中断（IRQ）的时候，会去执行该中断对应的处理函数（ISR）。普通情况下，会有一个中断向量表，向量表中定义了 CPU 对应的每一个外设资源的中断处理程序的入口，当发生对应的中断的时候， CPU 直接跳转到这个入口执行程序。也就是中断上下文。（注意：中断上下文中，不可阻塞睡眠）。

Linux 中断 top/bottom

玩过 MCU 的人都知道，中断服务程序的设计最好是快速完成任务并退出，因为此刻系统处于被中断中。但是在 ISR 中又有一些必须完成的事情，比如：清中断标志，读/写数据，寄存器操作等。

在 Linux 中，同样也是这个要求，希望尽快的完成 ISR。但事与愿违，有些 ISR 中任务繁重，会消耗很多时间，导致响应速度变差。Linux 中针对这种情况，将中断分为了两部分：

上半部（top half）：收到一个中断，立即执行，有严格的时间限制，只做一些必要的工作，比如：应答，复位等。这些工作都是在所有中断被禁止的情况下完成的。
底半部（bottom half）：能够被推迟到后面完成的任务会在底半部进行。在适合的时机，下半部会被开中断执行。（具体的机制在接下来章节分析（软中断、tasklet、工作队列））。

中断处理程序

驱动程序可以使用接口：

static inline int __must_check request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,const char *name, void *dev)

像系统申请注册一个中断处理程序。其中的参数：

参数含义

irq 表了该中断的中断号，一般 CPU 的中断号都会事先定义好。

handler 中断发生后的 ISR

flags 中断标志( IRQF_DISABLED / IRQFSAMPLE_RANDOM / IRQF_TIMER / IRQF_SHARED)

name 中断相关的设备 ASCII 文本，例如 "keyboard"，这些名字会在 /proc/irq 和 /proc/interrupts 文件使用

dev 用于共享中断线，传递驱动程序的设备结构。非共享类型的中断，直接设置成为 NULL

中断标志 flag 的含义：

标志含义

IRQF_DISABLED 设置这个标志的话，意味着内核在处理这个 ISR 期间，要禁止其他中断（多数情况不使用这个）

IRQFSAMPLE_RANDOM 表明这个设备产生的中断对内核熵池有贡献

IRQF_TIMER 为系统定时器准备的标志

IRQF_SHARED 表明多个中断处理程序之间共享中断线。同一个给定的线上注册每个处理程序，必须设置这个

调用 request_irq 成功执行返回 0。常见错误是 -EBUSY，表示给定的中断线已经在使用（或者没有指定 IRQF_SHARED）

注意：request_irq 函数可能引起睡眠，所以不允许在中断上下文或者不允许睡眠的代码中调用。

释放中断：

const void *free_irq(unsigned int irq, void *dev_id) //用于释放中断处理函数。

注意：Linux 中的中断处理程序是无须重入的。当给定的中断处理程序正在执行的时候，其中断线在所有的处理器上都会被屏蔽掉，以防在同一个中断线上又接收到另一个新的中断。通常情况下，除了该中断的其他中断都是打开的，也就是说其他的中断线上的重点都能够被处理，但是当前的中断线总是被禁止的，故，同一个中断处理程序是绝对不会被自己嵌套的，另外ARM上也不支持中断优先级，也就是没有使用FIQ，因此ARM不支持中断嵌套。

中断上下文

与进程上下文不一样，内核执行中断服务程序的时候，处于中断上下文。中断处理程序并没有自己的独立的栈，而是使用了内核栈，其大小一般是有限制的（32bit 机器 8KB）。所以其必须短小精悍。同时中断服务程序是打断了正常的程序流程，这一点上也必须保证快速的执行。同时中断上下文中是不允许睡眠，阻塞的。

中断上下文不能睡眠的原因是：

1、中断处理的时候,不应该发生进程切换，因为在中断context中，唯一能打断当前中断handler的只有更高优先级的中断，它不会被进程打断，如果在中断context中休眠，则没有办法唤醒它，因为所有的wake_up_xxx都是针对某个进程而言的，而在中断context中，没有进程的概念，没有一个task_struct（这点对于softirq和tasklet一样），因此真的休眠了，比如调用了会导致block的例程，内核几乎肯定会死。

2、schedule()在切换进程时，保存当前的进程上下文（CPU寄存器的值、进程的状态以及堆栈中的内容），以便以后恢复此进程运行。中断发生后，内核会先保存当前被中断的进程上下文（在调用中断处理程序后恢复）；但在中断处理程序里，CPU寄存器的值肯定已经变化了吧（最重要的程序计数器PC、堆栈SP等），如果此时因为睡眠或阻塞操作调用了schedule()，则保存的进程上下文就不是当前的进程context了.所以不可以在中断处理程序中调用schedule()。

3、内核中schedule()函数本身在进来的时候判断是否处于中断上下文:

if(unlikely(in_interrupt()))

BUG();

因此，强行调用schedule()的结果就是内核BUG。

4、中断handler会使用被中断的进程内核堆栈，但不会对它有任何影响，因为handler使用完后会完全清除它使用的那部分堆栈，恢复被中断前的原貌。

5、处于中断context时候，内核是不可抢占的。因此，如果休眠，则内核一定挂起

中断处理流程

发生中断时，CPU执行异常向量vector_irq的代码，即异常向量表中的中断异常的代码，它是一个跳转指令，跳去执行真正的中断处理程序，在vector_irq里面，最终会调用中断处理的总入口函数。

对于 ARM64 处理器的异常级别 1、 2 和 3，每个异常级别都有自己的异常向量表，异常向量表的起始虚拟地址存放在寄存器 VBAR_ELn（向量基准地址寄存器， Vector Based Address Register）中。每个异常向量表有 16 项，分为 4 组，每组 4 项，每项的长度是 128 字节（可以存放32 条指令）。异常级别 n 的异常向量表所示。

异常级别 n 的异常向量表

地址异常类型说明

VBAR_ELn + 0x000 同步异常当前异常级别生成的异常，使用异常

级别0的栈指针寄存器SP_EL0

0x080 中断
0x100 快速中断
0x180 系统错误
0x200 同步异常当前异常级别生成的异常，使用当前

异常级别的栈指针寄存器SP_ELn

0x280 中断
0x300 快速中断
0x380 系统错误
0x400 同步异常 64位应用程序在异常级别（ n-1）生

成的异常

0x480 中断
0x500 快速中断
0x580 系统错误
0x600 同步异常 32位应用程序在异常级别（ n-1）生

成的异常

0x680 中断
0x700 快速中断
0x780 系统错误

ARM64 架构内核定义的异常向量表如下:

这部分内容在《Linux应用层和内核交互》中系统调用章节讲过，这里只列出与中断有关的内容;

arch/arm64/kernel/entry.S:

* Exception vectors.

.pushsection ".entry.text", "ax"

.align 11

ENTRY(vectors)

kernel_ventry 1, sync_invalid //异常级别1生成的同步异常，使用栈指针寄存器SP_EL0

kernel_ventry 1, irq_invalid //异常级别1生成的中断，使用栈指针寄存器SP_EL0

kernel_ventry 1, fiq_invalid //异常级别1生成的快速中断，使用栈指针寄存器SP_EL0

kernel_ventry 1, error_invalid //异常级别1生成的系统错误，使用栈指针寄存器SP_EL0

kernel_ventry 1, sync //异常级别1生成的同步异常，使用栈指针寄存器SP_EL1

kernel_ventry 1, irq //异常级别1生成的中断，使用栈指针寄存器SP_EL1

kernel_ventry 1, fiq_invalid //异常级别1生成的快速中断，使用栈指针寄存器SP_EL1

kernel_ventry 1, error_invalid //异常级别1生成的系统错误，使用栈指针寄存器SP_EL1

kernel_ventry 0, sync //64位应用程序在异常级别0生成的同步异常

kernel_ventry 0, irq // 64位应用程序在异常级别0生成的中断

kernel_ventry 0, fiq_invalid // 64位应用程序在异常级别0生成的快速中断

kernel_ventry 0, error_invalid //64位应用程序在异常级别0生成的系统错误

#ifdef CONFIG_COMPAT

kernel_ventry 0, sync_compat, 32 //32位应用程序在异常级别0生成的同步异常

kernel_ventry 0, irq_compat, 32 // 32位应用程序在异常级别0生成的中断

kernel_ventry 0, fiq_invalid_compat, 32 // 32位应用程序在异常级别0生成的快速中断

kernel_ventry 0, error_invalid_compat, 32 // 32位应用程序在异常级别0生成的系统错误

#else

kernel_ventry 0, sync_invalid, 32 //32位应用程序在异常级别0生成的同步异常

kernel_ventry 0, irq_invalid, 32 // 32位应用程序在异常级别0生成的中断

kernel_ventry 0, fiq_invalid, 32 // 32位应用程序在异常级别0生成的快速中断

kernel_ventry 0, error_invalid, 32 // 32位应用程序在异常级别0生成的系统错误

#endif

END(vectors)

kernel_ventry是一个宏，参数是跳转标号，即异常处理程序的标号，宏的定义如下(/arch/arm64/kernel/entry.S)：

.macro kernel_ventry, el, label, regsize = 64

.align 7

sub sp, sp, #S_FRAME_SIZE // 将sp预留一个fram_size，这个size 就是struct pt_regs的大小

#ifdef CONFIG_VMAP_STACK

....这里省略掉检查栈溢出的代码

#endif

b el\()\el\()_\label // 跳转到对应级别的异常处理函数， kernel_entry 1, irq为el1_irq

.endm

" .align 7"表示把下一条指令的地址对齐到 2^7，即对齐到 128；对于向量表vectors中的kernel_ventry 1, irq , 则 b el\()\el\()_\label跳转到el1_irq函数。其中1表示的是从哪个异常模式产生的，比如是User->kernel就是0， kernel->kernel就是1.

每个CPU 在初始化是，都会设置中断向量地址。

arch/arm64/kernel/head.S

__primary_switched:

adrp x4, init_thread_union

add sp, x4, #THREAD_SIZE

adr_l x5, init_task

msr sp_el0, x5 // Save thread_info

adr_l x8, vectors // load VBAR_EL1 with virtual

msr vbar_el1, x8 // vector table address

isb

stp xzr, x30, [sp, #-16]!

mov x29, sp

str_l x21, __fdt_pointer, x5 // Save FDT pointer

ldr_l x4, kimage_vaddr // Save the offset between

sub x4, x4, x0 // the kernel virtual and

str_l x4, kimage_voffset, x5 // physical mappings

// Clear BSS

adr_l x0, __bss_start

mov x1, xzr

adr_l x2, __bss_stop

sub x2, x2, x0

bl __pi_memset

dsb ishst // Make zero page visible to PTW

#ifdef CONFIG_KASAN

bl kasan_early_init

#endif

#ifdef CONFIG_RANDOMIZE_BASE

tst x23, ~(MIN_KIMG_ALIGN - 1) // already running randomized?

b.ne 0f

mov x0, x21 // pass FDT address in x0

bl kaslr_early_init // parse FDT for KASLR options

cbz x0, 0f // KASLR disabled? just proceed

orr x23, x23, x0 // record KASLR offset

ldp x29, x30, [sp], #16 // we must enable KASLR, return

ret // to __primary_switch()

#endif

add sp, sp, #16

mov x29, #0

mov x30, #0

b start_kernel

ENDPROC(__primary_switched)

__secondary_switched:

adr_l x5, vectors //设置中断向量地址

msr vbar_el1, x5

isb

adr_l x0, secondary_data

ldr x1, [x0, #CPU_BOOT_STACK] // get secondary_data.stack

mov sp, x1

ldr x2, [x0, #CPU_BOOT_TASK]

msr sp_el0, x2

mov x29, #0

mov x30, #0

b secondary_start_kernel

ENDPROC(__secondary_switched)

有中断产生时， GIC会向相应的CPU发出中断信号，CPU检测到中断信号，根据中断向量表，跳转到el1_irq。

arch/arm64/kernel/entry.S

el1_irq:

kernel_entry 1

enable_dbg

#ifdef CONFIG_TRACE_IRQFLAGS

bl trace_hardirqs_off

#endif

irq_handler

#ifdef CONFIG_PREEMPT

get_thread_info tsk

ldr w24, [tsk, #TI_PREEMPT] // get preempt count

cbnz w24, 1f // preempt count != 0

ldr x0, [tsk, #TI_FLAGS] // get flags

tbz x0, #TIF_NEED_RESCHED, 1f // needs rescheduling?

bl el1_preempt

#endif

#ifdef CONFIG_TRACE_IRQFLAGS

bl trace_hardirqs_on

#endif

kernel_exit 1

ENDPROC(el1_irq)

* Interrupt handling.

.macro irq_handler

#ifdef CONFIG_STRICT_MEMORY_RWX

ldr x1, =handle_arch_irq

ldr x1, [x1]

#else

ldr x1, handle_arch_irq

#endif

mov x0, sp

blr x1

.endm

.text

arch/arm64/kernel/irq.c

void __init set_handle_irq(void (*handle_irq)(struct pt_regs *))

{

if (handle_arch_irq)

return;

handle_arch_irq = handle_irq;

}

Gicv2中断控制器初始化时会调用set_handle_irq(gic_handle_irq);

dtb：

gic: interrupt-controller@1400000 {

compatible = "arm,gic-400";

#interrupt-cells = <3>;

interrupt-controller;

reg = <0x0 0x1401000 0 0x1000>, /* GICD */

<0x0 0x1402000 0 0x2000>, /* GICC */

<0x0 0x1404000 0 0x2000>, /* GICH */

<0x0 0x1406000 0 0x2000>; /* GICV */

interrupts = <1 9 0xf08>;

};

IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);

设置代码路径：gic_of_init()->__gic_init_bases()->set_handle_irq(gic_handle_irq);

static void __exception_irq_entry gic_handle_irq(struct pt_regs *regs)

{

u32 irqstat, irqnr;

struct gic_chip_data *gic = &gic_data[0];

void __iomem *cpu_base = gic_data_cpu_base(gic);

do {

irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK);

irqnr = irqstat & GICC_IAR_INT_ID_MASK;

if (likely(irqnr > 15 && irqnr < 1020)) {

if (static_key_true(&supports_deactivate))

writel_relaxed(irqstat, cpu_base + GIC_CPU_EOI);

isb();

handle_domain_irq(gic->domain, irqnr, regs); //调用相应的中断处理函数

continue;

}

if (irqnr < 16) {

writel_relaxed(irqstat, cpu_base + GIC_CPU_EOI);

if (static_key_true(&supports_deactivate))

writel_relaxed(irqstat, cpu_base + GIC_CPU_DEACTIVATE);

#ifdef CONFIG_SMP

* Ensure any shared data written by the CPU sending

* the IPI is read after we've read the ACK register

* on the GIC.

* Pairs with the write barrier in gic_raise_softirq

smp_rmb();

handle_IPI(irqnr, regs); //SMP 核间中断

#endif

continue;

}

break;

} while (1);

}

gic_handle_irq()->handle_domain_irq()->__handle_domain_irq()

static inline int handle_domain_irq(struct irq_domain *domain,

unsigned int hwirq, struct pt_regs *regs)

{

return __handle_domain_irq(domain, hwirq, true, regs);

}

/**

* __handle_domain_irq - Invoke the handler for a HW irq belonging to a domain

* @domain: The domain where to perform the lookup

* @hwirq: The HW irq number to convert to a logical one

* @lookup: Whether to perform the domain lookup or not

* @regs: Register file coming from the low-level handling code

* Returns: 0 on success, or -EINVAL if conversion has failed

int __handle_domain_irq(struct irq_domain *domain, unsigned int hwirq,

bool lookup, struct pt_regs *regs)

{

struct pt_regs *old_regs = set_irq_regs(regs);

unsigned int irq = hwirq;

int ret = 0;

irq_enter();

#ifdef CONFIG_IRQ_DOMAIN

if (lookup)

irq = irq_find_mapping(domain, hwirq);

#endif

* Some hardware gives randomly wrong interrupts. Rather

* than crashing, do something sensible.

if (unlikely(!irq || irq >= nr_irqs)) {

ack_bad_irq(irq);

ret = -EINVAL;

} else {

generic_handle_irq(irq);

}

irq_exit();

set_irq_regs(old_regs);

return ret;

}

这里请注意：

先调用了 irq_enter 标记进入了硬件中断：

irq_enter是更新一些系统的统计信息，同时在__irq_enter宏中禁止了进程的抢占。虽然在产生IRQ时，ARM会自动把CPSR中的I位置位，禁止新的IRQ请求，直到中断控制转到相应的流控层后才通过local_irq_enable()打开。那为何还要禁止抢占？这是因为要考虑中断嵌套的问题，一旦流控层或驱动程序主动通过local_irq_enable打开了IRQ，而此时该中断还没处理完成，新的irq请求到达，这时代码会再次进入irq_enter，在本次嵌套中断返回时，内核不希望进行抢占调度，而是要等到最外层的中断处理完成后才做出调度动作，所以才有了禁止抢占这一处理

再调用 generic_handle_irq()最后调用 irq_exit 删除进入硬件中断的标记。

gic_handle_irq()->handle_domain_irq()->__handle_domain_irq()->generic_handle_irq()

/**

* generic_handle_irq - Invoke the handler for a particular irq

* @irq: The irq number to handle

int generic_handle_irq(unsigned int irq)

{

struct irq_desc *desc = irq_to_desc(irq);

if (!desc)

return -EINVAL;

generic_handle_irq_desc(desc);

return 0;

}

首先在函数 irq_to_desc 中根据发生中断的中断号，去取出它的 irq_desc 中断描述结构，然后调用 generic_handle_irq_desc：

gic_handle_irq()->handle_domain_irq()->__handle_domain_irq()->generic_handle_irq()->generic_handle_irq_desc()

* Architectures call this to let the generic IRQ layer

* handle an interrupt.

static inline void generic_handle_irq_desc(struct irq_desc *desc)

{

desc->handle_irq(desc);

}

这里调用了 handle_irq 函数。所以，在上述流程中，还需要分析 irq_to_desc 流程：

struct irq_desc *irq_to_desc(unsigned int irq)

{

return (irq < NR_IRQS) ? irq_desc + irq : NULL;

}

NR_IRQS 是支持的总的中断个数，当然，irq 不能够大于这个数目。所以返回 irq_desc + irq。

irq_desc 是一个全局的数组：

struct irq_desc irq_desc[NR_IRQS] __cacheline_aligned_in_smp = {