专栏首页分布式系统进阶Linux中断一网打尽(1) —— 中断及其初始化

Linux中断一网打尽(1) —— 中断及其初始化

[toc]

Linux中断一网打尽 —— 中断及其初始化

前情提要

通过本文您可以了解到如下内容:

  • Linux 中断是什么,如何分类,能干什么?
  • Linux 中断在计算机启动各阶段是如何初始化的?
中断是什么

既然叫中断, 那我们首先就会想到这个中断是中断谁?想一想计算机最核心的部分是什么?没错, CPU, 计算机上绝大部分的计算都在CPU中完成,因此这个中断也就是中断CPU当前的运行,让CPU转而先处理这个引起中断的事件,通常来说这个中断的事件比较紧急,处理完毕后再继续执行之前被中断的task。比如,我们敲击键盘,CPU就必须立即响应这个操作,不然我们打字就全变成了慢动作~。说白了中断其实就是一种主动通知机制,如果中断源不主动通知,那想知道其发生了什么事情,只能一次次地轮询了,白白耗费CPU。

中断的分类

大的方向上一般分为两大类:同步中断和异步中断,按Intel的说法,将异步中断称为中断,将同步中断称为异常。

异步中断

主要是指由CPU以外的硬件产生的中断,比如鼠标,键盘等。它的特点是相对CPU来说随时随机发生,事先完全没有预兆,不可预期的。异步中断发生时,CPU基本上都正在执行某条指令。

异步中断可分为可屏蔽和不可屏蔽两种,字如其义不用多解释。

同步中断

主要是指由CPU在执行命令过程中产生的异常,它一定是在CPU执行完一条命令后才会发出,产生于CPU内部。按其被CPU处理后返回位置的不同,我们将同步中断分为故障(fault), 陷阱(trap)和终止(abort)三类。我们通过一个表格来作下对比区分:

异步中断分类

特点

处理完毕后的返回位置

例子

故障(fault)

潜在可能恢复的错误

重新执行引起此故障的指令

缺页中断

陷阱(trap)

为了实现某种功能有意而为之发生的错误

执行引发当前陷阱的指令的下一条指令

系统调用

终止(abort)

不可恢复的错误

没有返回,进程将被终止

两点说明:

  • 处理完毕后的返回位置:发生异常时,CPU最终会进入到相应的异常处理程序中(简单说就是CPU需要执行一次跳转)在执行具体操作前会设置好的异常处理完成后跳转回的CS:IP, 即代码段寄存器和程序指针寄存器,不同类型的异常其设置的CS:IP不同而已;
  • 有些分类方法还会有一种叫可编程异常的,比如说把系统调用算作这一类,也可以。但是如果按处理完毕后的返回位置来说系统调用是可以归入陷阱这一类的。
硬件中断的管理模型

我们都知道CPU上只有有限多的脚针,负责与外部通讯,比如有数据线,地址线等,也有中断线,但一般只有两条NMI(不可屏蔽中断线)和INTR(可屏蔽中断线), 新的CPU有LINT0和LINT1脚针。那您会问了,电脑上有那么多外设,CPU就这两根线,怎么接收这么多外设的中断信号呢?确实,因此CPU找了一个管理这些众多中断的代理人——中断控制器。

就目前我们使用的SMP多核架构里,我们经常使用高级可编程中断控制器APIC, 老式的 8259A 可编程中断控制器大家有兴趣可自行搜索。

APIC分为两部分,IO APIC和Local APIC,从名字上我们就可略知一二。

  • IO APIC: 用来连接各种外设的硬件控制器,接收其发送的中断请求信号,然后将其传送到Local APIC, 这个IO APIC一般会封装在主板南板芯片上;
  • Local APIC: 基本上集成在了CPU里, 向CPU通知中断发生。
  • 放张网上的图:

ioapic.jpg

中断的初始化
Linux 启动流程

中断的初始化是穿插在Linux本身启动和初始化过程中的,因此我们在这里简要说一下Linux本身的初始化。

  • 64位Linux启动大的方向上需要经过 实模式 -> 保护模式 -> 长模式 第三种模式的转换;
  • 电源接通,CPU启动并重置各寄存器后运行于实模式下,CS:IP加载存储于ROM中的一跳转指令,跳转到BIOS中;
  • BIOS启动,硬件自测,读取MRB;
  • BIOS运行第一阶段引导程序,第一阶段引导程序运行第二阶段引导程序,通常是 grub;
  • Grub开始引导内核运行;
  • 相关初始化后进行保护模式,再进入长模式,内核解压缩;
  • 体系无关初始化部分;
  • 体系相关初始化部分;

总结了一张图,仅供参考:

linux启动流程.png

中断描述符表

外设千万种,CPU统统不知道。所有的中断到了CPU这里就只是一个中断号,然后初始化阶段设置好中断号到中断处理程序的对应关系,CPU获取到一个中断号后,查到对应的中断处理程序调用就好了。

这两者的对应关系最后会抽象成了中断向量表, 现在叫 IDT中断描述符表。

中断的第一次初始化

实模式下的初始化

  • 上面那张Linux启动流程图如果你仔细看的话会发现在BIOS程序加载运行时,在实模式下也有一个BIOS的中断向量表,这个中断向量表提供了一些类似于BIOS的系统调用一样的方法。比如Linux在初始化时需要获取物理内存的详情,就 是调用了BIOS的相应中断来获取的。见下图:

选区_035.png

中断的第二次初始化
  • 在进入到保护模式后,会全新初始化一个空的中断描述符表 IDT, 供 kernel 使用;
  • Linux Kernel提供256个大小的中断描述符表
#define IDT_ENTRIES           256

gate_desc idt_table[IDT_ENTRIES] __page_aligned_bss;
 
中断的第三次初始化
  • 在进入到长模式后,在x86_64_start_kernel先初始化前32个异常类型的中断(即上面定义的 idt_table 的前32项);
void __init idt_setup_early_handler(void)
{
  int i;

  for (i = 0; i < NUM_EXCEPTION_VECTORS; i++)
      set_intr_gate(i, early_idt_handler_array[i]);

  load_idt(&idt_descr);
}

其中 early_idt_handler_array这个数组放置了32个异常类型的中断处理程序,我们先看一下它的定义:

const char early_idt_handler_array[32][9];

二维数组,每一个early_idt_handler_array[i]有9个字节。 这个 early_idt_handler_array的初始化很有意思,它用AT&T的汇编代码完成,在文件arch/x86/kernel/head_64.S中:

ENTRY(early_idt_handler_array)
  i = 0
  .rept NUM_EXCEPTION_VECTORS
  .if ((EXCEPTION_ERRCODE_MASK >> i) & 1) == 0
      UNWIND_HINT_IRET_REGS
      pushq $0    # Dummy error code, to make stack frame uniform
  .else
      UNWIND_HINT_IRET_REGS offset=8
  .endif
  pushq $i        # 72(%rsp) Vector number
  jmp early_idt_handler_common
  UNWIND_HINT_IRET_REGS
  i = i + 1
  .fill early_idt_handler_array + i*EARLY_IDT_HANDLER_SIZE - ., 1, 0xcc
  .endr
  UNWIND_HINT_IRET_REGS offset=16
END(early_idt_handler_array)

这段汇编循环遍历32次来初始化每一个early_idt_handler_array[i], 也就是填充它的9个字节:其中2个字节是压栈错误码指令,2个字节是压栈向量号指令,余下的5个字节是函数跳转指令(jmp early_idt_handler_common)。由此我们可以看出,这前32个异常类型的中断处理函数最终都会调用到early_idt_handler_common, 这个函数这里就不贴它的代码了,我们说下它的大致流程:

a. 先将各寄存器的值压栈保存;
b. 如果是 缺页异常,就调用 `early_make_patable`; 
c. 如果是 其他异常,就调用 `early_fixup_exception`; 
 
  • 体系结构相关的中断初始化 这也是一次部分初始化,它发生在 start_kernelsetup_arch中,即发生在 Linux 启动流程中的体系结构初始化部分。这部分实际上是更新上面已初始化的32个异常类中的X86_TRAP_DB(1号, 用于debug)和X86_TRAP_BP(3号, 用于debug时的断点);
static const __initconst struct idt_data early_idts[] = {
  INTG(X86_TRAP_DB,       debug),
  SYSG(X86_TRAP_BP,       int3),
};

void __init idt_setup_early_traps(void)
{
  idt_setup_from_table(idt_table, early_idts, ARRAY_SIZE(early_idts),
               true);
  load_idt(&idt_descr);
}

debugint3这两个汇编实现的中断处理程序这里我们就不详述了。

  • 更新 X86_TRAP_PF 缺页异常的中断处理程序
void __init idt_setup_early_pf(void)
{
  idt_setup_from_table(idt_table, early_pf_idts,
               ARRAY_SIZE(early_pf_idts), true);
}

static const __initconst struct idt_data early_pf_idts[] = {
  INTG(X86_TRAP_PF,       page_fault),
};
 
  • trap_init中调用 idt_setup_traps更新部分异常的中断处理程序:
void __init idt_setup_traps(void)
{
  idt_setup_from_table(idt_table, def_idts, ARRAY_SIZE(def_idts), true);
}

static const __initconst struct idt_data def_idts[] = {
  INTG(X86_TRAP_DE,       divide_error),
  INTG(X86_TRAP_NMI,      nmi),
  INTG(X86_TRAP_BR,       bounds),
  INTG(X86_TRAP_UD,       invalid_op),
  INTG(X86_TRAP_NM,       device_not_available),
  INTG(X86_TRAP_OLD_MF,       coprocessor_segment_overrun),
  INTG(X86_TRAP_TS,       invalid_TSS),
  INTG(X86_TRAP_NP,       segment_not_present),
  INTG(X86_TRAP_SS,       stack_segment),
  INTG(X86_TRAP_GP,       general_protection),
  INTG(X86_TRAP_SPURIOUS,     spurious_interrupt_bug),
  INTG(X86_TRAP_MF,       coprocessor_error),
  INTG(X86_TRAP_AC,       alignment_check),
  INTG(X86_TRAP_XF,       simd_coprocessor_error),

#ifdef CONFIG_X86_32
  TSKG(X86_TRAP_DF,       GDT_ENTRY_DOUBLEFAULT_TSS),
#else
  INTG(X86_TRAP_DF,       double_fault),
#endif
  INTG(X86_TRAP_DB,       debug),

#ifdef CONFIG_X86_MCE
  INTG(X86_TRAP_MC,       &machine_check),
#endif

  SYSG(X86_TRAP_OF,       overflow),
#if defined(CONFIG_IA32_EMULATION)
  SYSG(IA32_SYSCALL_VECTOR,   entry_INT80_compat),
#elif defined(CONFIG_X86_32)
  SYSG(IA32_SYSCALL_VECTOR,   entry_INT80_32),
#endif
};
 
  • trap_init中调用 idt_setup_ist_traps更新部分异常的中断处理程序, 看到这里您可能问,上面不是调用了idt_setup_traps,怎么这时又调用idt_setup_ist_traps? 这两者有什么区别?说起来话有点长,我们尽量从流程上给大家讲清楚,但不深入到具体的细节。

1.想说明这个问题,我们先来讲下栈这个东西: a. 首先每个进程都有自己的用户态栈,对应进程虚拟地址空间内的stack部分,用于进程在用户态变量申请,函数调用等操作; b. 除了用户态栈,每个进程在创建时(内核对应创建 task_struct结构)同时会创建对应的内核栈,这里进程由用户态进入到内核态执行函数时,相应的所用的栈也会切换到内核栈; c. 如果内核进入到中断处理程序,早期的kernel针对中断处理程序的执行会使用当前中断task的内核栈,这里有存在一定的问题,存在栈溢出的风险。举个例子,如果在中断处理程序里又发生了异常中断,此时会触发double fault,但其在处理过程中依然要使用当前task的内核栈,并且当前task内核栈已满,double fault无法被正确处理。为了解决这样的内部,linux kernel引出了独立的内核栈,针对SMP系统,它还是pre-cpu的。我们来看一下其初始化:

void irq_ctx_init(int cpu)
{
   union irq_ctx *irqctx;

   if (hardirq_ctx[cpu])
       return;

    // 硬中断独立栈
   irqctx = (union irq_ctx *)&hardirq_stack[cpu * THREAD_SIZE];
   irqctx->tinfo.task      = NULL;
   irqctx->tinfo.cpu       = cpu;
   irqctx->tinfo.preempt_count = HARDIRQ_OFFSET;
   irqctx->tinfo.addr_limit    = MAKE_MM_SEG(0);

   hardirq_ctx[cpu] = irqctx;

    //软中断独立栈
   irqctx = (union irq_ctx *)&softirq_stack[cpu * THREAD_SIZE];
   irqctx->tinfo.task      = NULL;
   irqctx->tinfo.cpu       = cpu;
   irqctx->tinfo.preempt_count = 0;
   irqctx->tinfo.addr_limit    = MAKE_MM_SEG(0);

   softirq_ctx[cpu] = irqctx;

   printk("CPU %u irqstacks, hard=%p soft=%p\n",
       cpu, hardirq_ctx[cpu], softirq_ctx[cpu]);
}

可以看到还特别贴心地为softirq也开辟了单独的栈。

2.在x86_64位系统中,还引入了一种新的栈配置:IST(Interrupt Stack Table)。目前Linux kernel中每个cpu最多支持7个IST,可以通过tss.ist[]来访问。

3.现在我们再来看idt_setup_ist_traps,其实就是重新初始化一个异常处理,让这些异常处理使用IST作为中断栈。

void __init idt_setup_ist_traps(void)
{
 idt_setup_from_table(idt_table, ist_idts, ARRAY_SIZE(ist_idts), true);
}

static const __initconst struct idt_data ist_idts[] = {
 ISTG(X86_TRAP_DB,   debug,      IST_INDEX_DB),
 ISTG(X86_TRAP_NMI,  nmi,        IST_INDEX_NMI),
 ISTG(X86_TRAP_DF,   double_fault,   IST_INDEX_DF),
#ifdef CONFIG_X86_MCE
 ISTG(X86_TRAP_MC,   &machine_check, IST_INDEX_MCE),
#endif
};

#define ISTG(_vector, _addr, _ist)           \
 G(_vector, _addr, _ist + 1, GATE_INTERRUPT, DPL0, __KERNEL_CS)

其中 IST_INDEX_DB IST_INDEX_NMI IST_INDEX_DF IST_INDEX_MCE就是要使用的ist[]的索引。

  • 剩下的最后一部分就是硬件中断的初始化了,它同样在start_kernel中执行:
early_irq_init();
init_IRQ();

这部分具体细节我们在Linux中断一网打尽(2) - IDT及中断处理的实现介绍。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Linux中断 - IDT

    中断描述符表简单来说说是定义了发生中断/异常时,CPU按这张表中定义的行为来处理对应的中断/异常。

    扫帚的影子
  • ReplicaManager源码解析2-LeaderAndIsr 请求响应

    其中最主要的操作调用ReplicaManager.becomeLeaderOrFollower来初始化Partition

    扫帚的影子
  • Kafka中的消息操作的层级调用关系Kafka源码分析-汇总

    扫帚的影子
  • 斯坦福开发新算法CheXNet,能比放射科医生更好地发现肺炎

    在人工智能可以比人类做得更好的清单上,现在可以加上“诊断出危险的肺部疾病”这一事项了。斯坦福大学的研究人员在arXiv发表了一篇新的论文,解释了他们开发的卷积神...

    AiTechYun
  • 腾讯还会给机会上车吗?

    腾讯 2019 年报已经出了,在主营上,19 年比 18 年多了一个收入板块—金融科技及企业服务。这块业务简单理解一下,应该是把 微信支付、腾讯云、企业微信等 ...

    villainhr
  • 如何在EHAB(EntLib)中定义”细粒度”异常策略?

    为了解决EntLib的EHAB(Exception Handling Application Block)只能在异常类型级别控制异常处理策略的局限,我在很久之前...

    蒋金楠
  • 用这个Sketch插件,N多图层命名瞬间搞定

    批量重命名永远是设计师心中的痛,比如说图层里N多的未命名,看起来是不是很闹心?就像这样:

    用户5009027
  • JSONObject 的使用

    直接构建即直接实例化一个 JSONObject 对象,而后调用其 put() 方法,将数据写入。put() 方法的第一个参数为 key 值,必须为 String...

    希希里之海
  • 微信小程序Ⅲ [页面标题设置]

    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u011415782/article/de...

    泥豆芽儿 MT
  • 原生workman实现消息推送

    共享单车关闭后,会通过设置的url,进行回调,发送数据。那么相对于共享单车关锁来说,回调给url的数据,对于客户端来说是异步操作,那么如何使回调变成同步操作,客...

    北溟有鱼QAQ

扫码关注云+社区

领取腾讯云代金券