分类目录归档：读核笔记

读核笔记、进程管理

抢占(preemption)是如何发生的

2018/02/09 vmunix

进程切换有自愿(Voluntary)和强制(Involuntary)之分，在前文中详细解释了两者的不同，简单来说，自愿切换意味着进程需要等待某种资源，强制切换则与抢占(Preemption)有关。

抢占(Preemption)是指内核强行切换正在CPU上运行的进程，在抢占的过程中并不需要得到进程的配合，在随后的某个时刻被抢占的进程还可以恢复运行。发生抢占的原因主要有：进程的时间片用完了，或者优先级更高的进程来争夺CPU了。

抢占的过程分两步，第一步触发抢占，第二步执行抢占，这两步中间不一定是连续的，有些特殊情况下甚至会间隔相当长的时间：

触发抢占：给正在CPU上运行的当前进程设置一个请求重新调度的标志(TIF_NEED_RESCHED)，仅此而已，此时进程并没有切换。
执行抢占：在随后的某个时刻，内核会检查TIF_NEED_RESCHED标志并调用schedule()执行抢占。

抢占只在某些特定的时机发生，这是内核的代码决定的。

触发抢占的时机

每个进程都包含一个TIF_NEED_RESCHED标志，内核根据这个标志判断该进程是否应该被抢占，设置TIF_NEED_RESCHED标志就意味着触发抢占。

直接设置TIF_NEED_RESCHED标志的函数是 set_tsk_need_resched()；
触发抢占的函数是resched_task()。

TIF_NEED_RESCHED标志什么时候被设置呢？在以下时刻：

周期性的时钟中断

时钟中断处理函数会调用scheduler_tick()，这是调度器核心层(scheduler core)的函数，它通过调度类(scheduling class)的task_tick方法 检查进程的时间片是否耗尽，如果耗尽则触发抢占：

void scheduler_tick(void)
{
        ...
        curr->sched_class->task_tick(rq, curr, 0);
        ...
}

void scheduler_tick(void)

{

...

curr->sched_class->task_tick(rq, curr, 0);

...

}

Linux的进程调度是模块化的，不同的调度策略比如CFS、Real-Time被封装成不同的调度类，每个调度类都可以实现自己的task_tick方法，调度器核心层根据进程所属的调度类调用对应的方法，比如CFS对应的是task_tick_fair，Real-Time对应的是task_tick_rt，每个调度类对进程的时间片都有不同的定义。

唤醒进程的时候

当进程被唤醒的时候，如果优先级高于CPU上的当前进程，就会触发抢占。相应的内核代码中，try_to_wake_up()最终通过check_preempt_curr()检查是否触发抢占。

新进程创建的时候

如果新进程的优先级高于CPU上的当前进程，会触发抢占。相应的调度器核心层代码是sched_fork()，它再通过调度类的 task_fork方法触发抢占：

int sched_fork(unsigned long clone_flags, struct task_struct *p)
{
        ...
        if (p->sched_class->task_fork)
                p->sched_class->task_fork(p);
        ...
}

int sched_fork(unsigned long clone_flags, struct task_struct *p)

{

...

if (p->sched_class->task_fork)

p->sched_class->task_fork(p);

...

}

进程修改nice值的时候

如果进程修改nice值导致优先级高于CPU上的当前进程，也会触发抢占。内核代码参见 set_user_nice()。

进行负载均衡的时候

在多CPU的系统上，进程调度器尽量使各个CPU之间的负载保持均衡，而负载均衡操作可能会需要触发抢占。

不同的调度类有不同的负载均衡算法，涉及的核心代码也不一样，比如CFS类在load_balance()中触发抢占:

load_balance()
{
        ...
        move_tasks();
        ...
        resched_cpu();
        ...
}

load_balance()

{

...

move_tasks();

...

resched_cpu();

...

}

RT类的负载均衡基于overload，如果当前运行队列中的RT进程超过一个，就调用push_rt_task()把进程推给别的CPU，在这里会触发抢占。

执行抢占的时机

触发抢占通过设置进程的TIF_NEED_RESCHED标志告诉调度器需要进行抢占操作了，但是真正执行抢占还要等内核代码发现这个标志才行，而内核代码只在设定的几个点上检查TIF_NEED_RESCHED标志，这也就是执行抢占的时机。

抢占如果发生在进程处于用户态的时候，称为User Preemption（用户态抢占）；如果发生在进程处于内核态的时候，则称为Kernel Preemption（内核态抢占）。

执行User Preemption（用户态抢占）的时机

从系统调用(syscall)返回用户态时；

源文件：arch/x86/kernel/entry_64.S
sysret_careful:
        bt $TIF_NEED_RESCHED,%edx
        jnc sysret_signal
        TRACE_IRQS_ON
        ENABLE_INTERRUPTS(CLBR_NONE)
        pushq_cfi %rdi
        call schedule
        popq_cfi %rdi
        jmp sysret_check

源文件：arch/x86/kernel/entry_64.S

sysret_careful:

bt $TIF_NEED_RESCHED,%edx

jnc sysret_signal

TRACE_IRQS_ON

ENABLE_INTERRUPTS(CLBR_NONE)

pushq_cfi %rdi

call schedule

popq_cfi %rdi

jmp sysret_check

从中断返回用户态时。

retint_careful:
        CFI_RESTORE_STATE
        bt    $TIF_NEED_RESCHED,%edx
        jnc   retint_signal
        TRACE_IRQS_ON
        ENABLE_INTERRUPTS(CLBR_NONE)
        pushq_cfi %rdi
        call  schedule
        popq_cfi %rdi
        GET_THREAD_INFO(%rcx)
        DISABLE_INTERRUPTS(CLBR_NONE)
        TRACE_IRQS_OFF
        jmp retint_check

retint_careful:

CFI_RESTORE_STATE

bt $TIF_NEED_RESCHED,%edx

jnc retint_signal

TRACE_IRQS_ON

ENABLE_INTERRUPTS(CLBR_NONE)

pushq_cfi %rdi

call schedule

popq_cfi %rdi

GET_THREAD_INFO(%rcx)

DISABLE_INTERRUPTS(CLBR_NONE)

TRACE_IRQS_OFF

jmp retint_check

执行Kernel Preemption（内核态抢占）的时机

Linux在2.6版本之后就支持内核抢占了，但是请注意，具体取决于内核编译时的选项：

CONFIG_PREEMPT_NONE=y
不允许内核抢占。这是SLES的默认选项。
CONFIG_PREEMPT_VOLUNTARY=y
在一些耗时较长的内核代码中主动调用cond_resched()让出CPU。这是RHEL的默认选项。
CONFIG_PREEMPT=y
允许完全内核抢占。

在 CONFIG_PREEMPT=y 的前提下，内核态抢占的时机是：

中断处理程序返回内核空间之前会检查TIF_NEED_RESCHED标志，如果置位则调用preempt_schedule_irq()执行抢占。preempt_schedule_irq()是对schedule()的包装。

#ifdef CONFIG_PREEMPT
        /* Returning to kernel space. Check if we need preemption */
        /* rcx:  threadinfo. interrupts off. */
ENTRY(retint_kernel)
        cmpl $0,TI_preempt_count(%rcx)
        jnz  retint_restore_args
        bt  $TIF_NEED_RESCHED,TI_flags(%rcx)
        jnc  retint_restore_args
        bt   $9,EFLAGS-ARGOFFSET(%rsp)  /* interrupts off? */
        jnc  retint_restore_args
        call preempt_schedule_irq
        jmp exit_intr
#endif

#ifdef CONFIG_PREEMPT

/* Returning to kernel space. Check if we need preemption */

/* rcx: threadinfo. interrupts off. */

ENTRY(retint_kernel)

cmpl $0,TI_preempt_count(%rcx)

jnz retint_restore_args

bt $TIF_NEED_RESCHED,TI_flags(%rcx)

jnc retint_restore_args

bt $9,EFLAGS-ARGOFFSET(%rsp) /* interrupts off? */

jnc retint_restore_args

call preempt_schedule_irq

jmp exit_intr

#endif

当内核从non-preemptible（禁止抢占）状态变成preemptible（允许抢占）的时候；
在preempt_enable()中，会最终调用 preempt_schedule 来执行抢占。preempt_schedule()是对schedule()的包装。

读核笔记、进程管理

进程切换：自愿(voluntary)与强制(involuntary)

2018/02/02 vmunix

从进程的角度看，CPU是共享资源，由所有的进程按特定的策略轮番使用。一个进程离开CPU、另一个进程占据CPU的过程，称为进程切换(process switch)。进程切换是在内核中通过调用schedule()完成的。

发生进程切换的场景有以下三种：

进程运行不下去了：
比如因为要等待IO完成，或者等待某个资源、某个事件，典型的内核代码如下：

//把进程放进等待队列，把进程状态置为TASK_UNINTERRUPTIBLE prepare_to_wait(waitq, wait, TASK_UNINTERRUPTIBLE); //切换进程 schedule();

1
2
3
4

//把进程放进等待队列，把进程状态置为TASK_UNINTERRUPTIBLE
prepare_to_wait(waitq, wait, TASK_UNINTERRUPTIBLE);
//切换进程
schedule();
进程还在运行，但内核不让它继续使用CPU了：
比如进程的时间片用完了，或者优先级更高的进程来了，所以该进程必须把CPU的使用权交出来；
进程还可以运行，但它自己的算法决定主动交出CPU给别的进程：
用户程序可以通过系统调用sched_yield()来交出CPU，内核则可以通过函数cond_resched()或者yield()来做到。

进程切换分为自愿切换(Voluntary)和强制切换(Involuntary)，以上场景1属于自愿切换，场景2和3属于强制切换。如何分辨自愿切换和强制切换呢？

自愿切换发生的时候，进程不再处于运行状态，比如由于等待IO而阻塞(TASK_UNINTERRUPTIBLE)，或者因等待资源和特定事件而休眠(TASK_INTERRUPTIBLE)，又或者被debug/trace设置为TASK_STOPPED/TASK_TRACED状态；
强制切换发生的时候，进程仍然处于运行状态(TASK_RUNNING)，通常是由于被优先级更高的进程抢占(preempt)，或者进程的时间片用完了。

注：实际情况更复杂一些，由于Linux内核支持抢占，kernel preemption有可能发生在自愿切换的过程之中，比如进程正进入休眠，本来如果顺利完成的话就属于自愿切换，但休眠的过程并不是原子操作，进程状态先被置成TASK_INTERRUPTIBLE，然后进程切换，如果Kernel Preemption恰好发生在两者之间，那就打断了休眠过程，自愿切换尚未完成，转而进入了强制切换的过程（虽然是强制切换，但此时的进程状态已经不是运行状态了），下一次进程恢复运行之后会继续完成休眠的过程。所以判断进程切换属于自愿还是强制的算法要考虑进程在切换时是否正处于被抢占(preempt)的过程中，参见以下内核代码：

static void __sched __schedule(void)
{
        ...
        switch_count = &prev->nivcsw;//强制切换的次数
        if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {//进程处于非运行状态并且允许抢占
		...
                switch_count = &prev->nvcsw;//自愿切换的次数
        }

	...

        if (likely(prev != next)) {
                rq->nr_switches++;
                rq->curr = next;
                ++*switch_count;//进程切换次数累加

                context_switch(rq, prev, next); /* unlocks the rq */
                /*
                 * The context switch have flipped the stack from under us
                 * and restored the local variables which were saved when
                 * this task called schedule() in the past. prev == current
                 * is still correct, but it can be moved to another cpu/rq.
                 */
                cpu = smp_processor_id();
                rq = cpu_rq(cpu);
        } else
                raw_spin_unlock_irq(&rq->lock);

        ...
}

not_running && preemptive : voluntary

static void __sched __schedule(void)

{

...

switch_count = &prev->nivcsw;//强制切换的次数

if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {//进程处于非运行状态并且允许抢占

...

switch_count = &prev->nvcsw;//自愿切换的次数

}

...

if (likely(prev != next)) {

rq->nr_switches++;

rq->curr = next;

++*switch_count;//进程切换次数累加

context_switch(rq, prev, next); /* unlocks the rq */

* The context switch have flipped the stack from under us

* and restored the local variables which were saved when

* this task called schedule() in the past. prev == current

* is still correct, but it can be moved to another cpu/rq.

cpu = smp_processor_id();

rq = cpu_rq(cpu);

} else

raw_spin_unlock_irq(&rq->lock);

...

}

not_running && preemptive : voluntary

最后，澄清几个容易产生误解的场景：

进程可以通过调用sched_yield()主动交出CPU，这不是自愿切换，而是属于强制切换，因为进程仍然处于运行状态。
有时候内核代码会在耗时较长的循环体内通过调用 cond_resched()或yield() ，主动让出CPU，以免CPU被内核代码占据太久，给其它进程运行机会。这也属于强制切换，因为进程仍然处于运行状态。

进程自愿切换(Voluntary)和强制切换(Involuntary)的次数被统计在 /proc/<pid>/status 中，其中voluntary_ctxt_switches表示自愿切换的次数，nonvoluntary_ctxt_switches表示强制切换的次数，两者都是自进程启动以来的累计值。

# grep ctxt /proc/26995/status
voluntary_ctxt_switches:        79
nonvoluntary_ctxt_switches:     4

# grep ctxt /proc/26995/status

voluntary_ctxt_switches: 79

nonvoluntary_ctxt_switches: 4

也可以用 pidstat -w 命令查看进程切换的每秒统计值：

# pidstat -w 1
Linux 3.10.0-229.14.1.el7.x86_64 (bj71s060)     02/01/2018      _x86_64_       (2 CPU)

12:05:20 PM   UID       PID   cswch/s nvcswch/s  Command
12:05:21 PM     0      1299      0.94      0.00  httpd
12:05:21 PM     0     27687      0.94      0.00  pidstat

# pidstat -w 1

Linux 3.10.0-229.14.1.el7.x86_64 (bj71s060) 02/01/2018 _x86_64_ (2 CPU)

12:05:20 PM UID PID cswch/s nvcswch/s Command

12:05:21 PM 0 1299 0.94 0.00 httpd

12:05:21 PM 0 27687 0.94 0.00 pidstat

自愿切换和强制切换的统计值在实践中有什么意义呢？
大致而言，如果一个进程的自愿切换占多数，意味着它对CPU资源的需求不高。如果一个进程的强制切换占多数，意味着对它来说CPU资源可能是个瓶颈，这里需要排除进程频繁调用sched_yield()导致强制切换的情况。

网络、读核笔记

临时端口号(ephemeral port)的动态分配

2018/01/15 vmunix

网络端口号是如何分配的？除了给常用服务保留的Well-known Port numbers之外，给客户端的端口号通常是动态分配的，称为ephemeral port（临时端口），在Linux系统上临时端口号的取值范围是通过这个内核参数定义的：net.ipv4.ip_local_port_range (/proc/sys/net/ipv4/ip_local_port_range)，端口号动态分配时并不是从小到大依次选取的，而是按照特定的算法随机分配的。

临时端口号的分配发生在以下两处：
– bind()；
– connect()。

bind()通过inet_csk_get_port()获取端口号，利用了net_random()产生的随机数：

// SLES12 kernel 3.12.69-60.64.32:

0104 int inet_csk_get_port(struct sock *sk, unsigned short snum)
0105 {
0106         struct inet_hashinfo *hashinfo = sk->sk_prot->h.hashinfo;
0107         struct inet_bind_hashbucket *head;
0108         struct inet_bind_bucket *tb;
0109         int ret, attempts = 5;
0110         struct net *net = sock_net(sk);
0111         int smallest_size = -1, smallest_rover;
0112         kuid_t uid = sock_i_uid(sk);
0113 
0114         local_bh_disable();
0115         if (!snum) {
0116                 int remaining, rover, low, high;
0117 
0118 again:
0119                 inet_get_local_port_range(&low, &high);
0120                 remaining = (high - low) + 1;
0121                 smallest_rover = rover = net_random() % remaining + low;
0122 
0123                 smallest_size = -1;
0124                 do {
0125                         if (inet_is_reserved_local_port(rover))
0126                                 goto next_nolock;
...

// SLES12 kernel 3.12.69-60.64.32:

0104 int inet_csk_get_port(struct sock *sk, unsigned short snum)

0105 {

0106 struct inet_hashinfo *hashinfo = sk->sk_prot->h.hashinfo;

0107 struct inet_bind_hashbucket *head;

0108 struct inet_bind_bucket *tb;

0109 int ret, attempts = 5;

0110 struct net *net = sock_net(sk);

0111 int smallest_size = -1, smallest_rover;

0112 kuid_t uid = sock_i_uid(sk);

0113

0114 local_bh_disable();

0115 if (!snum) {

0116 int remaining, rover, low, high;

0117

0118 again:

0119 inet_get_local_port_range(&low, &high);

0120 remaining = (high - low) + 1;

0121 smallest_rover = rover = net_random() % remaining + low;

0122

0123 smallest_size = -1;

0124 do {

0125 if (inet_is_reserved_local_port(rover))

0126 goto next_nolock;

...

connect()通过inet_hash_connect()分配端口号。核心的代码是：
port = low + (i + offset) % remaining;
其中 offset 是随机数。

// SLES12 kernel 3.12.69-60.64.32:

0477 int __inet_hash_connect(struct inet_timewait_death_row *death_row,
0478                 struct sock *sk, u32 port_offset,
0479                 int (*check_established)(struct inet_timewait_death_row *,
0480                         struct sock *, __u16, struct inet_timewait_sock **),
0481                 int (*hash)(struct sock *sk, struct inet_timewait_sock *twp))
0482 {
0483         struct inet_hashinfo *hinfo = death_row->hashinfo;
0484         const unsigned short snum = inet_sk(sk)->inet_num;
0485         struct inet_bind_hashbucket *head;
0486         struct inet_bind_bucket *tb;
0487         int ret;
0488         struct net *net = sock_net(sk);
0489         int twrefcnt = 1;
0490 
0491         if (!snum) {
0492                 int i, remaining, low, high, port;
0493                 static u32 hint;
0494                 u32 offset = hint + port_offset;
0495                 struct inet_timewait_sock *tw = NULL;
0496 
0497                 inet_get_local_port_range(&low, &high);
0498                 remaining = (high - low) + 1;
0499 
0500                 local_bh_disable();
0501                 for (i = 1; i <= remaining; i++) {
0502                         port = low + (i + offset) % remaining;
0503                         if (inet_is_reserved_local_port(port))
0504                                 continue;
...

// SLES12 kernel 3.12.69-60.64.32:

0477 int __inet_hash_connect(struct inet_timewait_death_row *death_row,

0478 struct sock *sk, u32 port_offset,

0479 int (*check_established)(struct inet_timewait_death_row *,

0480 struct sock *, __u16, struct inet_timewait_sock **),

0481 int (*hash)(struct sock *sk, struct inet_timewait_sock *twp))

0482 {

0483 struct inet_hashinfo *hinfo = death_row->hashinfo;

0484 const unsigned short snum = inet_sk(sk)->inet_num;

0485 struct inet_bind_hashbucket *head;

0486 struct inet_bind_bucket *tb;

0487 int ret;

0488 struct net *net = sock_net(sk);

0489 int twrefcnt = 1;

0490

0491 if (!snum) {

0492 int i, remaining, low, high, port;

0493 static u32 hint;

0494 u32 offset = hint + port_offset;

0495 struct inet_timewait_sock *tw = NULL;

0496

0497 inet_get_local_port_range(&low, &high);

0498 remaining = (high - low) + 1;

0499

0500 local_bh_disable();

0501 for (i = 1; i <= remaining; i++) {

0502 port = low + (i + offset) % remaining;

0503 if (inet_is_reserved_local_port(port))

0504 continue;

...

为以上代码生成随机数port_offset的函数是：

0391 static inline u32 inet_sk_port_offset(const struct sock *sk)
0392 {
0393         const struct inet_sock *inet = inet_sk(sk);
0394         return secure_ipv4_port_ephemeral(inet->inet_rcv_saddr,
0395                                           inet->inet_daddr,
0396                                           inet->inet_dport);
0397 }

0391 static inline u32 inet_sk_port_offset(const struct sock *sk)

0392 {

0393 const struct inet_sock *inet = inet_sk(sk);

0394 return secure_ipv4_port_ephemeral(inet->inet_rcv_saddr,

0395 inet->inet_daddr,

0396 inet->inet_dport);

0397 }

综上，临时端口号是这样产生的：

生成一个随机数，利用随机数在ip_local_port_range范围内取值，如果取到的值在ip_local_reserved_ports范围内，那就再依次取下一个值，直到不在ip_local_reserved_ports范围内为止。

注：
/proc/sys/net/ipv4/ip_local_reserved_ports (net.ipv4.ip_local_reserved_ports) 是应用程序保留的端口号，不会参与内核动态分配。有些软件比如SAP通常会保留大量的端口号，如果导致剩下的临时端口数量太少的话，动态分配的随机算法往往会产生重复的端口号，造成新分配的端口号总是相同的现象。

crash分析、读核笔记

内核如何检测soft lockup与hard lockup？

2017/09/26 vmunix

所谓lockup，是指某段内核代码占着CPU不放。Lockup严重的情况下会导致整个系统失去响应。Lockup有几个特点：

首先只有内核代码才能引起lockup，因为用户代码是可以被抢占的，不可能形成lockup（只有一种情况例外，就是SCHED_FIFO优先级为99的实时进程即使在用户态也可能使[watchdog/x]内核线程抢不到CPU而形成soft lock，参见《Real-Time进程会导致系统Lockup吗？》）
其次内核代码必须处于禁止内核抢占的状态(preemption disabled)，因为Linux是可抢占式的内核，只在某些特定的代码区才禁止抢占，在这些代码区才有可能形成lockup。

Lockup分为两种：soft lockup 和 hard lockup，它们的区别是 hard lockup 发生在CPU屏蔽中断的情况下。

Soft lockup是指CPU被内核代码占据，以至于无法执行其它进程。检测soft lockup的原理是给每个CPU分配一个定时执行的内核线程[watchdog/x]，如果该线程在设定的期限内没有得到执行的话就意味着发生了soft lockup，[watchdog/x]是SCHED_FIFO实时进程，优先级为最高的99，拥有优先运行的特权。
Hard lockup比soft lockup更加严重，CPU不仅无法执行其它进程，而且不再响应中断。检测hard lockup的原理利用了PMU的NMI perf event，因为NMI中断是不可屏蔽的，在CPU不再响应中断的情况下仍然可以得到执行，它再去检查时钟中断的计数器hrtimer_interrupts是否在保持递增，如果停滞就意味着时钟中断未得到响应，也就是发生了hard lockup。

Linux kernel设计了一个检测lockup的机制，称为NMI Watchdog，是利用NMI中断实现的，用NMI是因为lockup有可能发生在中断被屏蔽的状态下，这时唯一能把CPU抢下来的方法就是通过NMI，因为NMI中断是不可屏蔽的。NMI Watchdog 中包含 soft lockup detector 和 hard lockup detector，2.6之后的内核的实现方法如下。

NMI Watchdog 的触发机制包括两部分：

一个高精度计时器(hrtimer)，对应的中断处理例程是kernel/watchdog.c: watchdog_timer_fn()，在该例程中：
- 要递增计数器hrtimer_interrupts，这个计数器供hard lockup detector用于判断CPU是否响应中断；
- 还要唤醒[watchdog/x]内核线程，该线程的任务是更新一个时间戳；
- soft lock detector检查时间戳，如果超过soft lockup threshold一直未更新，说明[watchdog/x]未得到运行机会，意味着CPU被霸占，也就是发生了soft lockup。
基于PMU的NMI perf event，当PMU的计数器溢出时会触发NMI中断，对应的中断处理例程是 kernel/watchdog.c: watchdog_overflow_callback()，hard lockup detector就在其中，它会检查上述hrtimer的中断次数(hrtimer_interrupts)是否在保持递增，如果停滞则表明hrtimer中断未得到响应，也就是发生了hard lockup。

hrtimer的周期是：softlockup_thresh/5。
注：

在2.6内核中：
softlockup_thresh的值等于内核参数kernel.watchdog_thresh，默认60秒；
而到3.10内核中：
内核参数kernel.watchdog_thresh名称未变，但含义变成了hard lockup threshold，默认10秒；
soft lockup threshold则等于（2*kernel.watchdog_thresh），即默认20秒。

NMI perf event是基于PMU的，触发周期（hard lockup threshold）在2.6内核里是固定的60秒，不可手工调整；在3.10内核里可以手工调整，因为直接对应着内核参数kernel.watchdog_thresh，默认值10秒。

检测到 lockup 之后怎么办？可以自动panic，也可输出条信息就算完了，这是可以通过内核参数来定义的：

kernel.softlockup_panic: 决定了检测到soft lockup时是否自动panic，缺省值是0；
kernel.nmi_watchdog: 定义是否开启nmi watchdog、以及hard lockup是否导致panic，该内核参数的格式是”=[panic,][nopanic,][num]”.
（注：最新的kernel引入了新的内核参数kernel.hardlockup_panic，可以通过检查是否存在 /proc/sys/kernel/hardlockup_panic来判断你的内核是否支持。）

参考资料：

Softlockup detector and hardlockup detector (aka nmi_watchdog)

kernel/watchdog.c:
设置PMU NMI perf event的代码 wachdog_nmi_enable()
响应NMI perf overflow中断的代码 watchdog_overflow_callback()
[watchdog/x]内核线程 watchdog()
响应hrtimer中断的代码 watchdog_timer_fn()

读核笔记、进程管理

Real-Time进程会导致系统lockup吗？

2017/09/26 vmunix

Linux kernel支持两种实时(real-time)调度策略(scheduling policy)：SCHED_FIFO和SCHED_RR，无论是哪一种，实时进程的优先级范围[0~99]都高于普通进程[100~139]，始终优先于普通进程得到运行。如果实时进程是CPU消耗型的，会不会导致其它进程得不到运行机会，造成系统lockup呢？

这实际上是两个问题，不能混为一谈，第一个问题是会不会造成系统lockup，第二个问题是会不会导致其它进程得不到运行机会。我们一个一个分别来谈。

实时进程会不会造成系统lockup？

Lockup分为soft lockup和hard lockup，我在《内核如何检测SOFT LOCKUP与HARD LOCKUP》一文中解释了Linux kernel检测lockup的原理。

Hard lockup发生在CPU中断被屏蔽的情况下，因为实时进程本身并不会屏蔽CPU中断，hrtimer时钟中断是可以得到响应的，所以不会导致hard lockup。

Soft lockup发生在内核线程[watchdog/x]得不到运行的情况下，理论上如果实时进程占着CPU不放，确实有可能导致[watchdog/x]得不到运行而发生soft lockup，然而这个可能性并不大，因为[watchdog/x]本身也是实时进程，调度策略为SCHED_FIFO，优先级已经是最高的99：

$ ps -ef | grep watchdog
root         6     2  0 Feb24 ?        00:00:18 [watchdog/0]
root        10     2  0 Feb24 ?        00:00:16 [watchdog/1]
root        14     2  0 Feb24 ?        00:00:13 [watchdog/2]
root        18     2  0 Feb24 ?        00:00:12 [watchdog/3]

$ chrt -p 6
pid 6's current scheduling policy: SCHED_FIFO
pid 6's current scheduling priority: 99

$ ps -ef | grep watchdog

root 6 2 0 Feb24 ? 00:00:18 [watchdog/0]

root 10 2 0 Feb24 ? 00:00:16 [watchdog/1]

root 14 2 0 Feb24 ? 00:00:13 [watchdog/2]

root 18 2 0 Feb24 ? 00:00:12 [watchdog/3]

$ chrt -p 6

pid 6's current scheduling policy: SCHED_FIFO

pid 6's current scheduling priority: 99

如果占着CPU不放的实时进程也是SCHED_FIFO并且优先级为99，就有可能导致soft lockup。为什么呢？我们看一下实时进程的调度策略就明白了：

在多个实时进程之间，优先级更高的会抢先运行
（注：实时进程的优先级数字越大则优先级越高，99最高，0最低；而普通进程正好相反，优先级数字越大则优先级越低，139最低，100最高）；
优先级相同的实时进程之间，不会互相抢占，只能等对方主动释放CPU；
SCHED_FIFO调度策略的特点是，进程会一直保持运行直到发生以下情况之一：
1. 进程主动调用sched_yield(2)放弃运行，自动排到运行队列的队尾，等到相同优先级的其它进程运行之后才有机会再运行；
2. 进程进入睡眠状态（比如由于等待I/O的原因），唤醒后自动排到运行队列的队尾，等到相同优先级的其它进程运行之后才有机会再运行；
3. 被优先级更高的实时进程抢占，这种情况下会自动排到运行队列的队首，下次运行的机会排在相同优先级的其它进程的前面。
SCHED_RR进程与SCHED_FIFO唯一不同的是，实时进程的运行时间是分为一段一段的，在相同优先级的进程之间轮流运行，每个进程运行完一个时间段之后，必须让给下一个进程（强调：仅对相同优先级而言，不同优先级的进程之间仍然会互相抢占）。

所以，如果占着CPU不放的实时进程的调度策略是SCHED_FIFO，并且优先级为与[watchdog/x]相同的99，SCHED_FIFO的调度策略决定了只要它不放手，[watchdog/x]就无法运行，结果是会导致soft lockup。

接下来第二个问题是：

实时进程会不会导致其它进程得不到运行机会？

如果实时进程占着CPU不放，会不会导致其它进程得不到运行机会，包括管理员的shell也无法运行、连基本的管理任务也进行不了，最终造成整个系统失去控制？

通常不会。因为Linux kernel有一个RealTime Throttling机制，就是为了防止CPU消耗型的实时进程霸占所有的CPU资源而造成整个系统失去控制。它的原理很简单，就是保证无论如何普通进程都能得到一定比例（默认5%）的CPU时间，可以通过两个内核参数来控制：

/proc/sys/kernel/sched_rt_period_us
缺省值是1,000,000 μs (1秒)，表示实时进程的运行粒度为1秒。（注：修改这个参数请谨慎，太大或太小都可能带来问题）。
/proc/sys/kernel/sched_rt_runtime_us
缺省值是 950,000 μs (0.95秒)，表示在1秒的运行周期里所有的实时进程一起最多可以占用0.95秒的CPU时间。
如果sched_rt_runtime_us=-1，表示取消限制，意味着实时进程可以占用100%的CPU时间（慎用，有可能使系统失去控制）。

所以，Linux kernel默认情况下保证了普通进程无论如何都可以得到5%的CPU时间，尽管系统可能会慢如蜗牛，但管理员仍然可以利用这5%的时间设法恢复系统，比如停掉失控的实时进程，或者给自己的shell进程赋予更高的实时优先级以便执行管理任务，等等。

Real-time Throttling支持cgroup，详见https://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt

参考资料：
https://lwn.net/Articles/296419/

IPC、读核笔记

Linux kernel spinlock使用不当的后果

2017/01/05 vmunix

spinlock(自旋锁)是内核中最常见的锁，它的特点是：等待锁的过程中不休眠，而是占着CPU空转，优点是避免了上下文切换的开销，缺点是该CPU空转属于浪费，spinlock适合用来保护快进快出的临界区。

spinlock有很多限制条件，其中最重要的是，持有spinlock的CPU不能被抢占，持有spinlock的代码不能休眠。如果违反，会发生死锁，后果很严重。持有spinlock的代码不能休眠，这一条是开发者编写内核程序使用spinlock的时候要人工保证的。而持有spinlock的CPU不能被抢占是由spinlock的API本身提供保证，出于效率的考虑，spinlock的API提供了多种选择，对抢占的防止程度也不一样，开发者在选用的时候需要谨慎，下文对此详细展开。

Linux内核提供了多种spinlock的API，其中最常用的是：
spin_lock/spin_unlock — 禁止内核抢占
spin_lock_irq/spin_unlock_irq — 禁止内核抢占并屏蔽中断
spin_lock_irqsave/spin_unlock_irqrestore — 禁止内核抢占并屏蔽中断，事先保存中断屏蔽位并事后恢复原状

spin_lock()禁止了内核抢占，但是没有屏蔽中断，意味着持有该spinlock的CPU有可能被中断抢占。如果你的某段内核代码选用了spin_lock()，就必须保证这段代码不会被任何中断处理程序调用，否则就会发生死锁（参见后文的一个实际发生的案例）。如果某段内核代码有可能被中断处理程序调用，那就只能选择spin_lock_irq或spin_lock_irqsave。

下面是一个刚发生的实际案例，SLES11 SP4的系统失去响应，kdump生成了vmcore，分析过程中发现以下backtraces揭示了原因：

crash64> bt -c 2
PID: 47     TASK: ffff880230c78400  CPU: 2   COMMAND: "kswapd0"
 #0 [ffff88023fa46e40] crash_nmi_callback at ffffffff81024bcf
 #1 [ffff88023fa46e50] notifier_call_chain at ffffffff8146d6e7
 #2 [ffff88023fa46e80] __atomic_notifier_call_chain at ffffffff8146d72d
 #3 [ffff88023fa46e90] notify_die at ffffffff8146d77d
 #4 [ffff88023fa46ec0] default_do_nmi at ffffffff8146ad13
 #5 [ffff88023fa46ee0] do_nmi at ffffffff8146ae08
 #6 [ffff88023fa46ef0] restart_nmi at ffffffff8146a295
    [exception RIP: _raw_spin_lock+21]
    RIP: ffffffff81469795  RSP: ffff88023fa43738  RFLAGS: 00000283
    RAX: 0000000000002b41  RBX: ffff88023337fc00  RCX: 00000000000000d0
    RDX: 0000000000002b3f  RSI: ffff88023fa437d4  RDI: ffffffff81a02700
    RBP: 0000000000000001   R8: 0000000000000000   R9: ffff88023fa43740
    R10: ffff88023ffd95b8  R11: ffff88023ffd9520  R12: ffff88023337fc00
    R13: 0000000000000001  R14: ffff88023337fce0  R15: 0000000000000008
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
--- <NMI exception stack> ---
 #7 [ffff88023fa43738] _raw_spin_lock at ffffffff81469795
 #8 [ffff88023fa43738] __shrink_dcache_sb at ffffffff81176b36
 #9 [ffff88023fa437b8] prune_dcache at ffffffff81176d82
#10 [ffff88023fa43808] shrink_dcache_memory at ffffffff81176e88
#11 [ffff88023fa43818] shrink_slab at ffffffff81110874
#12 [ffff88023fa438b8] do_try_to_free_pages at ffffffff81111c43
#13 [ffff88023fa43928] try_to_free_pages at ffffffff81112072
#14 [ffff88023fa439c8] __alloc_pages_slowpath at ffffffff81104a6f
#15 [ffff88023fa43af8] __alloc_pages_nodemask at ffffffff81105079
#16 [ffff88023fa43b98] alloc_pages_current at ffffffff8113da6e
#17 [ffff88023fa43bd8] bnx2x_alloc_rx_sge at ffffffffa055d484 [bnx2x]
#18 [ffff88023fa43c18] bnx2x_fill_frag_skb at ffffffffa055d75e [bnx2x]
#19 [ffff88023fa43cb8] bnx2x_tpa_stop at ffffffffa055da86 [bnx2x]
#20 [ffff88023fa43d18] bnx2x_rx_int at ffffffffa056084b [bnx2x]
#21 [ffff88023fa43e48] bnx2x_poll at ffffffffa05613b4 [bnx2x]
#22 [ffff88023fa43e88] net_rx_action at ffffffff813adada
#23 [ffff88023fa43ed8] __do_softirq at ffffffff8106925f
#24 [ffff88023fa43f48] call_softirq at ffffffff81472a5c
#25 [ffff88023fa43f60] do_softirq at ffffffff81004695
#26 [ffff88023fa43f90] smp_apic_timer_interrupt at ffffffff81026fd8
#27 [ffff88023fa43fb0] apic_timer_interrupt at ffffffff814721f3
--- <IRQ stack> ---
#28 [ffff880230c7bad8] apic_timer_interrupt at ffffffff814721f3
    [exception RIP: _raw_spin_trylock]
    RIP: ffffffff81469750  RSP: ffff880230c7bb88  RFLAGS: 00000246
    RAX: ffff8802c63aac40  RBX: ffffffff81469c0e  RCX: ffff8802c63aad00
    RDX: ffff880230c7bfd8  RSI: ffff880230c78400  RDI: ffff8802c63aac18
    RBP: ffff8802c63aac18   R8: ffff880230c7a000   R9: 0000000000000000
    R10: ffff88023fa509a0  R11: ffffffff81051970  R12: ffffffff814721ee
    R13: ffffffff81051970  R14: ffffffff81469c0e  R15: ffff880230c7bb80
    ORIG_RAX: ffffffffffffff10  CS: 0010  SS: 0018
#29 [ffff880230c7bb88] __shrink_dcache_sb at ffffffff81176bec
#30 [ffff880230c7bc08] prune_dcache at ffffffff81176d82
#31 [ffff880230c7bc58] shrink_dcache_memory at ffffffff81176e88
#32 [ffff880230c7bc68] shrink_slab at ffffffff81110874
#33 [ffff880230c7bd08] kswapd_shrink_zone at ffffffff81111086
#34 [ffff880230c7bd68] balance_pgdat at ffffffff811115de
#35 [ffff880230c7be78] kswapd at ffffffff81111980
#36 [ffff880230c7bee8] kthread at ffffffff81084946
#37 [ffff880230c7bf48] kernel_thread_helper at ffffffff81472964

crash64> bt -c 2

PID: 47 TASK: ffff880230c78400 CPU: 2 COMMAND: "kswapd0"

#0 [ffff88023fa46e40] crash_nmi_callback at ffffffff81024bcf

#1 [ffff88023fa46e50] notifier_call_chain at ffffffff8146d6e7

#2 [ffff88023fa46e80] __atomic_notifier_call_chain at ffffffff8146d72d

#3 [ffff88023fa46e90] notify_die at ffffffff8146d77d

#4 [ffff88023fa46ec0] default_do_nmi at ffffffff8146ad13

#5 [ffff88023fa46ee0] do_nmi at ffffffff8146ae08

#6 [ffff88023fa46ef0] restart_nmi at ffffffff8146a295

[exception RIP: _raw_spin_lock+21]

RIP: ffffffff81469795 RSP: ffff88023fa43738 RFLAGS: 00000283

RAX: 0000000000002b41 RBX: ffff88023337fc00 RCX: 00000000000000d0

RDX: 0000000000002b3f RSI: ffff88023fa437d4 RDI: ffffffff81a02700

RBP: 0000000000000001 R8: 0000000000000000 R9: ffff88023fa43740

R10: ffff88023ffd95b8 R11: ffff88023ffd9520 R12: ffff88023337fc00

R13: 0000000000000001 R14: ffff88023337fce0 R15: 0000000000000008

ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

--- <NMI exception stack> ---

#7 [ffff88023fa43738] _raw_spin_lock at ffffffff81469795

#8 [ffff88023fa43738] __shrink_dcache_sb at ffffffff81176b36

#9 [ffff88023fa437b8] prune_dcache at ffffffff81176d82

#10 [ffff88023fa43808] shrink_dcache_memory at ffffffff81176e88

#11 [ffff88023fa43818] shrink_slab at ffffffff81110874

#12 [ffff88023fa438b8] do_try_to_free_pages at ffffffff81111c43

#13 [ffff88023fa43928] try_to_free_pages at ffffffff81112072

#14 [ffff88023fa439c8] __alloc_pages_slowpath at ffffffff81104a6f

#15 [ffff88023fa43af8] __alloc_pages_nodemask at ffffffff81105079

#16 [ffff88023fa43b98] alloc_pages_current at ffffffff8113da6e

#17 [ffff88023fa43bd8] bnx2x_alloc_rx_sge at ffffffffa055d484 [bnx2x]

#18 [ffff88023fa43c18] bnx2x_fill_frag_skb at ffffffffa055d75e [bnx2x]

#19 [ffff88023fa43cb8] bnx2x_tpa_stop at ffffffffa055da86 [bnx2x]

#20 [ffff88023fa43d18] bnx2x_rx_int at ffffffffa056084b [bnx2x]

#21 [ffff88023fa43e48] bnx2x_poll at ffffffffa05613b4 [bnx2x]

#22 [ffff88023fa43e88] net_rx_action at ffffffff813adada

#23 [ffff88023fa43ed8] __do_softirq at ffffffff8106925f

#24 [ffff88023fa43f48] call_softirq at ffffffff81472a5c

#25 [ffff88023fa43f60] do_softirq at ffffffff81004695

#26 [ffff88023fa43f90] smp_apic_timer_interrupt at ffffffff81026fd8

#27 [ffff88023fa43fb0] apic_timer_interrupt at ffffffff814721f3

--- <IRQ stack> ---

#28 [ffff880230c7bad8] apic_timer_interrupt at ffffffff814721f3

[exception RIP: _raw_spin_trylock]

RIP: ffffffff81469750 RSP: ffff880230c7bb88 RFLAGS: 00000246

RAX: ffff8802c63aac40 RBX: ffffffff81469c0e RCX: ffff8802c63aad00

RDX: ffff880230c7bfd8 RSI: ffff880230c78400 RDI: ffff8802c63aac18

RBP: ffff8802c63aac18 R8: ffff880230c7a000 R9: 0000000000000000

R10: ffff88023fa509a0 R11: ffffffff81051970 R12: ffffffff814721ee

R13: ffffffff81051970 R14: ffffffff81469c0e R15: ffff880230c7bb80

ORIG_RAX: ffffffffffffff10 CS: 0010 SS: 0018

#29 [ffff880230c7bb88] __shrink_dcache_sb at ffffffff81176bec

#30 [ffff880230c7bc08] prune_dcache at ffffffff81176d82

#31 [ffff880230c7bc58] shrink_dcache_memory at ffffffff81176e88

#32 [ffff880230c7bc68] shrink_slab at ffffffff81110874

#33 [ffff880230c7bd08] kswapd_shrink_zone at ffffffff81111086

#34 [ffff880230c7bd68] balance_pgdat at ffffffff811115de

#35 [ffff880230c7be78] kswapd at ffffffff81111980

#36 [ffff880230c7bee8] kthread at ffffffff81084946

#37 [ffff880230c7bf48] kernel_thread_helper at ffffffff81472964

我来解释一下，上面的backtraces意思是：CPU 2上正在运行的进程是”kswapd0″（kswapd0是负责swapping的内核线程），它正在压缩dcache以便腾出一些空闲内存，当它执行到__shrink_dcache_sb()的时候被一个中断抢占了CPU，（注意被中断抢占的进程不会离开当前CPU，不会有机会到其它CPU上运行，只能等中断处理结束之后把CPU交还给它），中断处理程序是bnx2x驱动模块（注意看[]，表示的是内核模块），它发现内存不够，于是自动清理内存，最终也走到了压缩dcache这一步，也去调用__shrink_dcache_sb()，但是__shrink_dcache_sb()的临界区受到spinlock保护，见下面源代码第0823行，这个名为dcache_lru_lock的spinlock刚才已经被”kswapd0″进程持有了，所以中断处理程序不可能抢到，问题是持有dcache_lru_lock的”kswapd0″进程又被中断抢占了CPU，不可能继续运行，也就没机会释放掉dcache_lru_lock，这就陷入了死锁状态。

// SLES11 SP4: kernel 3.0.101-71, fs/dcache.c

0814 static void __shrink_dcache_sb(struct super_block *sb, int *count, int flags)
0815 {
0816         /* called from prune_dcache() and shrink_dcache_parent() */
0817         struct dentry *dentry;
0818         LIST_HEAD(referenced);
0819         LIST_HEAD(tmp);
0820         int cnt = *count;
0821 
0822 relock:
0823         spin_lock(&dcache_lru_lock);
0824         while (!list_empty(&sb->s_dentry_lru)) {
0825                 dentry = list_entry(sb->s_dentry_lru.prev,
0826                                 struct dentry, d_lru);
0827                 BUG_ON(dentry->d_sb != sb);
0828 
0829                 if (!spin_trylock(&dentry->d_lock)) {
0830                         spin_unlock(&dcache_lru_lock);
0831                         cpu_relax();
0832                         goto relock;
0833                 }
...

// SLES11 SP4: kernel 3.0.101-71, fs/dcache.c

0814 static void __shrink_dcache_sb(struct super_block *sb, int *count, int flags)

0815 {

0816 /* called from prune_dcache() and shrink_dcache_parent() */

0817 struct dentry *dentry;

0818 LIST_HEAD(referenced);

0819 LIST_HEAD(tmp);

0820 int cnt = *count;

0821

0822 relock:

0823 spin_lock(&dcache_lru_lock);

0824 while (!list_empty(&sb->s_dentry_lru)) {

0825 dentry = list_entry(sb->s_dentry_lru.prev,

0826 struct dentry, d_lru);

0827 BUG_ON(dentry->d_sb != sb);

0828

0829 if (!spin_trylock(&dentry->d_lock)) {

0830 spin_unlock(&dcache_lru_lock);

0831 cpu_relax();

0832 goto relock;

0833 }

...

根本原因在于，既然__shrink_dcache_sb()选用了spin_lock()，就意味着设计者认为它不会被中断处理程序调用，因为spin_lock()不屏蔽中断，是不能防止中断抢占的，只要中断处理程序不调用__shrink_dcache_sb()，死锁就不会发生；如果要让__shrink_dcache_sb()可以被中断处理程序调用，那就不能选用spin_lock()，而应该用spin_lock_irq或spin_lock_irqsave。这个案例中的问题出在bnx2x驱动程序中，它在bnx2x_alloc_rx_sge() 中调用alloc_pages()时不恰当地使用了GFP_KERNEL标志，实际上应该使用GFP_ATOMIC标志，这样alloc_pages()就不会试图去主动回收内存、也就不会最终调用__shrink_dcache_sb()了。此bug记载在SUSE的bsc#975358中，在kernel 3.0.101-77中得以修复。

读核笔记

内核引导参数iommu与intel_iommu有何不同？

2016/03/03 vmunix

前文介绍过IOMMU是提供DMA Remapping功能的硬件模块，可以把DMA地址从虚拟地址翻译成物理地址。Linux kernel有两个引导参数(boot parameter)与iommu有关：iommu=[on/off] 和 intel_iommu=[on/off]，它们有什么区别呢？答案是：参数iommu控制的是GART iommu功能，参数intel_iommu控制的是基于Intel VT-d的iommu功能。

下面的代码表明：CONFIG_IOMMU控制的是GART iommu，CONFIG_DMAR控制的是intel_iommu。（CONFIG_IOMMU对应的是引导参数iommu，CONFIG_DMAR对应的是引导参数intel_iommu，注意：CONFIG_DMAR名称中没有Intel字样，这里比较容易误导，但你看它下面对应的函数intel_iommu_init就很明显了）：

arch/x86_64/kernel/pci-dma.c:

0331 static int __init pci_iommu_init(void)
0332 {
0333 #ifdef CONFIG_CALGARY_IOMMU
0334         calgary_iommu_init();
0335 #endif
0336 
0337 #ifdef CONFIG_DMAR
0338         intel_iommu_init();
0339 #endif
0340 
0341 #ifdef CONFIG_AMD_IOMMU
0342         amd_iommu_init();
0343 #endif
0344 
0345 #ifdef CONFIG_IOMMU
0346         gart_iommu_init();
0347 #endif
0348 
0349         no_iommu_init();
0350         return 0;
0351 }

arch/x86_64/kernel/pci-dma.c:

0331 static int __init pci_iommu_init(void)

0332 {

0333 #ifdef CONFIG_CALGARY_IOMMU

0334 calgary_iommu_init();

0335 #endif

0336

0337 #ifdef CONFIG_DMAR

0338 intel_iommu_init();

0339 #endif

0340

0341 #ifdef CONFIG_AMD_IOMMU

0342 amd_iommu_init();

0343 #endif

0344

0345 #ifdef CONFIG_IOMMU

0346 gart_iommu_init();

0347 #endif

0348

0349 no_iommu_init();

0350 return 0;

0351 }

引导参数iommu控制的是GART iommu，前文介绍过GART (Graphics Address Remapping Table)，最初是为了方便图形芯片直接读取内存而设计的：使用地址转译功能将收集到内存中的数据映射到一个图形芯片可以“看”到的地址。这个地址转译功能自然也可以充当IOMMU，于是GART被Linux kernel用来帮助传统的32位PCI设备访问可寻址范围之外的内存区域。GART iommu有局限性（比如仅限于显存范围内），不具备Intel IOMMU的完整功能。

“iommu”参数默认是打开的，以2.6.18 kernel为例，

configs/kernel-2.6.18-x86_64.config:
...
0187 CONFIG_IOMMU=y
...

configs/kernel-2.6.18-x86_64.config:

...

0187 CONFIG_IOMMU=y

...

注：GART iommu功能是按需激活的，并有前提条件，比如系统内存必须在3GB以上、而且只对有限的设备，参见：

arch/x86_64/Kconfig:
...
0481 config IOMMU
0482         bool "IOMMU support" if EMBEDDED
0483         default y
0484         select SWIOTLB
0485         select AGP
0486         depends on PCI && !X86_64_XEN
0487         help
0488           Support for full DMA access of devices with 32bit memory access only
0489           on systems with more than 3GB. This is usually needed for USB,
0490           sound, many IDE/SATA chipsets and some other devices.
0491           Provides a driver for the AMD Athlon64/Opteron/Turion/Sempron GART
0492           based IOMMU and a software bounce buffer based IOMMU used on Intel
0493           systems and as fallback.
0494           The code is only active when needed (enough memory and limited
0495           device) unless CONFIG_IOMMU_DEBUG or iommu=force is specified
0496           too.
...

arch/x86_64/Kconfig:

...

0481 config IOMMU

0482 bool "IOMMU support" if EMBEDDED

0483 default y

0484 select SWIOTLB

0485 select AGP

0486 depends on PCI && !X86_64_XEN

0487 help

0488 Support for full DMA access of devices with 32bit memory access only

0489 on systems with more than 3GB. This is usually needed for USB,

0490 sound, many IDE/SATA chipsets and some other devices.

0491 Provides a driver for the AMD Athlon64/Opteron/Turion/Sempron GART

0492 based IOMMU and a software bounce buffer based IOMMU used on Intel

0493 systems and as fallback.

0494 The code is only active when needed (enough memory and limited

0495 device) unless CONFIG_IOMMU_DEBUG or iommu=force is specified

0496 too.

...

引导参数intel_iommu控制的是基于Intel VT-d的iommu，该参数默认是关闭的，在config文件中对应的配置如下（注意：名称中用的是DMAR而不是iommu，不留意的话容易错过）：

configs/kernel-2.6.18-x86_64.config
...
0303 # CONFIG_DMAR_DEFAULT_ON is not set
...

configs/kernel-2.6.18-x86_64.config

...

0303 # CONFIG_DMAR_DEFAULT_ON is not set

...

从以下的代码中我们看到：[默认情况]与[显式设置intel_iommu=off]的效果是一样的，结果都是”dmar_disabled=1″，所以 intel_iommu=off 设不设置其实都一样：

drivers/pci/intel-iommu.c:

0330 #ifdef CONFIG_DMAR_DEFAULT_ON
0331 int dmar_disabled = 0;
0332 #else
0333 int dmar_disabled = 1;
0334 #endif /*CONFIG_DMAR_DEFAULT_ON*/

0346 static int __init intel_iommu_setup(char *str)
0347 {
0348         if (!str)
0349                 return -EINVAL;
0350         while (*str) {
0351                 if (!strncmp(str, "on", 2)) {
0352                         dmar_disabled = 0;
0353                         printk(KERN_INFO "Intel-IOMMU: enabled\n");
0354                 } else if (!strncmp(str, "off", 3)) {
0355                         dmar_disabled = 1;
0356                         printk(KERN_INFO "Intel-IOMMU: disabled\n");
0357                 } else if (!strncmp(str, "igfx_off", 8)) {
...

drivers/pci/intel-iommu.c:

0330 #ifdef CONFIG_DMAR_DEFAULT_ON

0331 int dmar_disabled = 0;

0332 #else

0333 int dmar_disabled = 1;

0334 #endif /*CONFIG_DMAR_DEFAULT_ON*/

0346 static int __init intel_iommu_setup(char *str)

0347 {

0348 if (!str)

0349 return -EINVAL;

0350 while (*str) {

0351 if (!strncmp(str, "on", 2)) {

0352 dmar_disabled = 0;

0353 printk(KERN_INFO "Intel-IOMMU: enabled\n");

0354 } else if (!strncmp(str, "off", 3)) {

0355 dmar_disabled = 1;

0356 printk(KERN_INFO "Intel-IOMMU: disabled\n");

0357 } else if (!strncmp(str, "igfx_off", 8)) {

...

注：启动参数intel_iommu有点复杂的是：存在两个与DMAR有关的配置，除了上面看到的CONFIG_DMAR_DEFAULT_ON之外，另外还有一个是CONFIG_DMAR，默认是打开的：

configs/kernel-2.6.18-x86_64.config
...
0302 CONFIG_DMAR=y
0303 # CONFIG_DMAR_DEFAULT_ON is not set
...

configs/kernel-2.6.18-x86_64.config

...

0302 CONFIG_DMAR=y

0303 # CONFIG_DMAR_DEFAULT_ON is not set

...

CONFIG_DMAR告诉内核在编译时要准备好支持DMA Remapping设备（见注一）；
而CONFIG_DMAR_DEFAULT_ON 是告诉内核在引导时是否激活DMAR设备。
也就是说，默认情况下(CONFIG_DMAR=y)内核已经具备了支持DMAR的功能，设置内核引导参数intel_iommu=off（等效于缺省情况：即CONFIG_DMAR_DEFAULT_ON未设置）并不是关闭内核的DMAR功能，仅仅是告诉内核在引导过程中不要把DMAR设备激活而已。
这两个配置参数的详细解释参见以下文件。

arch/x86_64/Kconfig:
...
0703 config DMAR
0704         bool "Support for DMA Remapping Devices (EXPERIMENTAL)"
0705         depends on X86_64 && PCI_MSI && ACPI && EXPERIMENTAL && !XEN
0706         help
0707           DMA remapping (DMAR) devices support enables independent address
0708           translations for Direct Memory Access (DMA) from devices.
0709           These DMA remapping devices are reported via ACPI tables
0710           and include PCI device scope covered by these DMA
0711           remapping devices.
0712 
0713 config DMAR_DEFAULT_ON
0714         def_bool n
0715         prompt "Enable DMA Remapping Devices by default"
0716         depends on DMAR
0717         help
0718           Selecting this option will enable a DMAR device at boot time if
0719           one is found. If this option is not selected, DMAR support can
0720           be enabled by passing intel_iommu=on to the kernel. It is
0721           recommended you say N here while the DMAR code remains
0722           experimental.
...

arch/x86_64/Kconfig:

...

0703 config DMAR

0704 bool "Support for DMA Remapping Devices (EXPERIMENTAL)"

0705 depends on X86_64 && PCI_MSI && ACPI && EXPERIMENTAL && !XEN

0706 help

0707 DMA remapping (DMAR) devices support enables independent address

0708 translations for Direct Memory Access (DMA) from devices.

0709 These DMA remapping devices are reported via ACPI tables

0710 and include PCI device scope covered by these DMA

0711 remapping devices.

0712

0713 config DMAR_DEFAULT_ON

0714 def_bool n

0715 prompt "Enable DMA Remapping Devices by default"

0716 depends on DMAR

0717 help

0718 Selecting this option will enable a DMAR device at boot time if

0719 one is found. If this option is not selected, DMAR support can

0720 be enabled by passing intel_iommu=on to the kernel. It is

0721 recommended you say N here while the DMAR code remains

0722 experimental.

...

（注一）事实上更准确地说，内核不仅仅是在编译时具备了支持DMAR设备的功能，而且在引导过程中始终会根据ACPI table把DMAR设备有关的数据结构都初始化好–无论是否加了引导参数intel_iommu=off。

内核怎么知道哪些设备需要DMA Remapping呢？是通过ACPI table知道的，因为需要DMA Remapping的设备必须在firmware/BIOS中登记。以下是内核初始化DMAR的代码，可以看到无论是否dmar_disabled，都会调用dmar_table_init和dmar_dev_scope_init：

drivers/pci/intel-iommu.c:

3317 int __init intel_iommu_init(void)
3318 {
3319         int ret = 0;
3320 
3321         if (dmar_table_init())
3322                 return  -ENODEV;
3323 
3324         if (dmar_dev_scope_init())
3325                 return  -ENODEV;
3326 
3327         /*
3328          * Check the need for DMA-remapping initialization now.
3329          * Above initialization will also be used by Interrupt-remapping.
3330          */
3331         if (no_iommu || swiotlb || dmar_disabled)
3332                 return -ENODEV;
3333 
...

drivers/pci/intel-iommu.c:

3317 int __init intel_iommu_init(void)

3318 {

3319 int ret = 0;

3320

3321 if (dmar_table_init())

3322 return -ENODEV;

3323

3324 if (dmar_dev_scope_init())

3325 return -ENODEV;

3326

3327 /*

3328 * Check the need for DMA-remapping initialization now.

3329 * Above initialization will also be used by Interrupt-remapping.

3330 */

3331 if (no_iommu || swiotlb || dmar_disabled)

3332 return -ENODEV;

3333

...

这就是为什么只要BIOS中打开了Intel VT-d，我们就总会在kernel messages中看到类似下面的初始化DMAR table的信息，无论intel_iommu参数是on还是off。

...
DMAR:Host address width 46
DMAR:DRHD base: 0x000000efefe000 flags: 0x0
IOMMU efefe000: Number of IOMMU domains reduced from 64K to 4K
IOMMU efefe000: ver 1:0 cap d2078c106f0464 ecap f020de
DMAR:DRHD base: 0x000000dcffe000 flags: 0x1
IOMMU dcffe000: Number of IOMMU domains reduced from 64K to 4K
IOMMU dcffe000: ver 1:0 cap d2078c106f0464 ecap f020de
DMAR:RMRR base: 0x000000bdffd000 end: 0x000000bdffffff
DMAR:RMRR base: 0x000000bdff6000 end: 0x000000bdffcfff
DMAR:RMRR base: 0x000000bdf83000 end: 0x000000bdf84fff
...

...

DMAR:Host address width 46

DMAR:DRHD base: 0x000000efefe000 flags: 0x0

IOMMU efefe000: Number of IOMMU domains reduced from 64K to 4K

IOMMU efefe000: ver 1:0 cap d2078c106f0464 ecap f020de

DMAR:DRHD base: 0x000000dcffe000 flags: 0x1

IOMMU dcffe000: Number of IOMMU domains reduced from 64K to 4K

IOMMU dcffe000: ver 1:0 cap d2078c106f0464 ecap f020de

DMAR:RMRR base: 0x000000bdffd000 end: 0x000000bdffffff

DMAR:RMRR base: 0x000000bdff6000 end: 0x000000bdffcfff

DMAR:RMRR base: 0x000000bdf83000 end: 0x000000bdf84fff

...

如果你想让kernel中与Intel VT-d有关的软件模块完全关闭，仅仅使用启动参数intel_iommu=off是不够的，而必须重新编译内核–在config中配置CONFIG_DMAR=n，或者用另一种方法：在BIOS中关闭Intel VT-d。

读核笔记

PREEMPT_ACTIVE标志在内核抢占中的作用

2016/01/25 vmunix

Linux从2.6开始支持内核抢占，意味着即使进程运行在内核态也可以被抢占。为了支持内核抢占，代码中为每个进程的 thread_info 引入了 preempt_count 计数器，数值为0的时候表示可以内核抢占，每当进程持有内核锁的时候把 preempt_count 计数器加1，表示禁止内核抢占。此外还有一些其它禁止内核抢占的场景，也通过 preempt_counter 字段反应出来：preempt_counter 字段是32位的，除了抢占计数器之外还包括其他标志位，只要 preempt_counter 整体不为0，就不能进行内核抢占，这个设计一下子简化了对众多不能抢占的情况的检测：

Bit 0- 7: 就是上文中所讲的抢占计数器，表示显式禁用内核抢占的次数；
Bit 8-15: 软中断计数器，记录可延迟函数被禁用的次数；
Bit 16-27: 硬中断计数器，表示中断处理程序的嵌套数，irq_enter()递增它，irq_exit()递减它；
Bit 28: PREEMPT_ACTIVE 标志。

这篇笔记要讲的是 PREEMPT_ACTIVE 标志。PREEMPT_ACTIVE标志的本意是表明正在进行内核抢占，设置了之后preempt_counter就不再为0，从而达到禁止内核抢占的效果，使得执行抢占工作的代码不会被再抢占。它的一个重要用途是防止非Running状态的进程被抢占过程错误地从Run Queue中移除。这句话令人十分费解，已经不处于Running状态的进程本来就不应该留在Run Queue中，为什么要防止它被移除？我用了很长时间才琢磨出来，要回答这个问题，首先要理解为什么非Running状态的进程会被抢占？所谓抢占，就是从一个正在运行的进程手上把CPU抢过来，可是既然进程已经不是Running状态了，怎么会还在CPU上，还被抢占？
这是因为进程从Running变成非Running要经过几个步骤：在把自己放进Wait Queue、状态置成非Running之后，最后调用schedule()把自己从Run Queue中移除、并把CPU交给其他进程。设想一下，一个进程恰好在调用schedule()之前就被抢占了，此时它仍然还在CPU上运行。这就是为什么非Running状态的进程也会被抢占的原因。对这样的进程，抢占流程不能擅自将之从Run Queue中移除，因为它的切换过程没有完成，应该让它有机会自己回头接着做完。比如以下的代码，是一个典型的休眠过程：

for (;;) {
    prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);
    if (condition)
        break;
    schedule();
}

for (;;) {

prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);

if (condition)

break;

schedule();

}

如果在第2行被抢占，刚把进程状态设置为TASK_UNINTERRUPTIBLE，本来马上就要测试条件是否满足了，这时被抢占，而抢占过程必定包含调用schedule()的步骤，导致该进程被移出运行队列，失去了运行机会，随后的条件判断语句就无法执行了，假如此时condition条件是满足的，它本来会跳出for循环、而不会去调用schedule()进入休眠，然而却被抢占过程错误地调用schedule()导致它休眠了，也因此错过了那个条件判断语句，也许就永远没有被唤醒的机会了。正确的做法是：进程被抢占后还留在Run Queue中，下次还有机会继续运行，恢复运行后继续判断condition，如果条件不满足，在随后主动调用的schedule()中会被移出运行队列，这是不能由抢占代劳的。

下面我们详细看看PREEMPT_ACTIVE是如何帮助实现上述的正确做法的。在内核里，进程从运行态进入休眠态的最后一步是呼叫调度器schedule()——把自己从Run Queue中移除，把CPU交给其他进程，这在不支持内核抢占的时代没有问题，因为整个过程不会被打断，然而内核抢占的出现使情况变复杂了，现在从运行态进入休眠态的过程可能会被抢占所打断，而抢占过程中会调用schedule()，导致schedule()的调用提前发生，有可能形成race condition。为了避免这种情况，内核抢占过程中不能直接呼叫schedule()调度器，而是呼叫preempt_schedule()，再通过它来调用schedule()，preempt_schedule()会在调用schedule()之前设置PREEMPT_ACTIVE标志，调用之后再清除这个标志。而schedule()会检查这个标志，如果设置了PREEMPT_ACTIVE标志，意味着这是从抢占过程中进入schedule()，对于不是TASK_RUNNING(state != 0)的进程，就不会调用deactivate_task()把进程从Run Queue移除。源码如下：

asmlinkage void __sched schedule(void)
{
        struct task_struct *prev, *next;
...

        if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
                if (unlikely(signal_pending_state(prev->state, prev)))
                        prev->state = TASK_RUNNING;
                else   
                        deactivate_task(rq, prev, DEQUEUE_SLEEP);
                switch_count = &prev->nvcsw;
        }
...

asmlinkage void __sched schedule(void)

{

struct task_struct *prev, *next;

...

if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {

if (unlikely(signal_pending_state(prev->state, prev)))

prev->state = TASK_RUNNING;

else

deactivate_task(rq, prev, DEQUEUE_SLEEP);

switch_count = &prev->nvcsw;

}

...

这段代码的逻辑含义是这样的：
如果设置了PREEMPT_ACTIVE，说明该进程是由于内核抢占而被调离CPU的，这时不把它从Run Queue里移除；如果PREEMPT_ACTIVE没被设置（进程不是由于内核抢占而被调离），还要看一下它有没有未处理的信号，如果有的话，也不把它从Run Queue移除。
总之，只要不是主动呼叫schedule()，而是因被抢占而调离CPU的，进程就还在运行队列中，还有机会运行。

读核笔记

dmar 与 IOMMU

2015/08/19 vmunix

在分析Linux kernel dump的时候经常会看到一个叫做dmar的东西，查看中断信息的时候也时常见到一个名称为dmar0的设备，到底什么是dmar呢？

$ cat /proc/interrupts
            CPU0       CPU1       CPU2       CPU3       
   0:        127          0          0          0  IR-IO-APIC-edge      timer
   1:          2          0          0          0  IR-IO-APIC-edge      i8042
  ...
  48:          0          0          0          0  DMAR_MSI-edge        dmar0
  ...

$ cat /proc/interrupts

CPU0 CPU1 CPU2 CPU3

0: 127 0 0 0 IR-IO-APIC-edge timer

1: 2 0 0 0 IR-IO-APIC-edge i8042

...

48: 0 0 0 0 DMAR_MSI-edge dmar0

...

大家知道，I/O设备可以直接存取内存，称为DMA(Direct Memory Access)；DMA要存取的内存地址称为DMA地址（也可称为BUS address）。在DMA技术刚出现的时候，DMA地址都是物理内存地址，简单直接，但缺点是不灵活，比如要求物理内存必须是连续的一整块而且不能是高位地址等等，也不能充分满足虚拟机的需要。后来dmar就出现了。 dmar意为DMA remapping，是Intel为支持虚拟机而设计的I/O虚拟化技术，I/O设备访问的DMA地址不再是物理内存地址，而要通过DMA remapping硬件进行转译，DMA remapping硬件会把DMA地址翻译成物理内存地址，并检查访问权限等等。负责DMA remapping操作的硬件称为IOMMU。做个类比：大家都知道MMU是支持内存地址虚拟化的硬件，MMU是为CPU服务的；而IOMMU是为I/O设备服务的，是将DMA地址进行虚拟化的硬件。 IOMMA不仅将DMA地址虚拟化，还起到隔离、保护等作用，如下图所示意，详细请参阅Intel Virtualization Technology for Directed I/O 现在我们知道了dmar的概念，那么Linux中断信息中出现的dmar0又是什么呢？还是用MMU作类比吧，便于理解：当CPU访问一个在地址翻译表中不存在的地址时，就会触发一个fault，Linux kernel的fault处理例程会判断这是合法地址还是非法地址，如果是合法地址，就分配相应的物理内存页面并建立从物理地址到虚拟地址的翻译表项，如果是非法地址，就给进程发个signal，产生core dump。IOMMU也类似，当I/O设备进行DMA访问也可能触发fault，有些fault是recoverable的，有些是non-recoverable的，这些fault都需要Linux kernel进行处理，所以IOMMU就利用中断(interrupt)的方式呼唤内核，这就是我们在/proc/interrupts中看到的dmar0那一行的意思。我们看到的中断号48，据此还可以进一步发掘更多的信息：

crash64> irq 48
    IRQ: 48
 STATUS: 100 (IRQ_INPROGRESS)
HANDLER: ffffffff81a96a40            <dmar_msi_type>
         typename: ffffffff81791acb  "DMAR_MSI"
          startup: ffffffff810e3960  <default_startup>
         shutdown: ffffffff810e3920  <default_shutdown>
           enable: ffffffff810e3990  <default_enable>
          disable: ffffffff810e3860  <default_disable>
              ack: ffffffff81031a00  <ack_apic_edge>
             mask: ffffffff812add60  <dmar_msi_mask>
         mask_ack: 0  
           unmask: ffffffff812addc0  <dmar_msi_unmask>
              eoi: 0  
              end: ffffffff810e14f0  <noop>
     set_affinity: ffffffff81033130  <dmar_msi_set_affinity>
        retrigger: ffffffff81031260  <ioapic_retrigger_irq>
         set_type: 0  
         set_wake: 0  
 ACTION: ffff880439deb8c0
          handler: ffffffff812ad9b0  <dmar_fault>
            flags: 0
             name: ffff880439ca9180  "dmar0"
           dev_id: ffff880439ca9140
             next: 0
  DEPTH: 0

crash64> irq 48

IRQ: 48

STATUS: 100 (IRQ_INPROGRESS)

HANDLER: ffffffff81a96a40 <dmar_msi_type>

typename: ffffffff81791acb "DMAR_MSI"

startup: ffffffff810e3960 <default_startup>

shutdown: ffffffff810e3920 <default_shutdown>

enable: ffffffff810e3990 <default_enable>

disable: ffffffff810e3860 <default_disable>

ack: ffffffff81031a00 <ack_apic_edge>

mask: ffffffff812add60 <dmar_msi_mask>

mask_ack: 0

unmask: ffffffff812addc0 <dmar_msi_unmask>

eoi: 0

end: ffffffff810e14f0 <noop>

set_affinity: ffffffff81033130 <dmar_msi_set_affinity>

retrigger: ffffffff81031260 <ioapic_retrigger_irq>

set_type: 0

set_wake: 0

ACTION: ffff880439deb8c0

handler: ffffffff812ad9b0 <dmar_fault>

flags: 0

name: ffff880439ca9180 "dmar0"

dev_id: ffff880439ca9140

next: 0

DEPTH: 0

上面最有意思的信息是ACTION的handler，表示IOMMU发生fault之后的中断处理例程，我们看到的例程名是dmar_fault，源代码如下：

1296 irqreturn_t dmar_fault(int irq, void *dev_id)
1297 {
1298         struct intel_iommu *iommu = dev_id;
1299         int reg, fault_index;
1300         u32 fault_status;
1301         unsigned long flag;
1302 
1303         spin_lock_irqsave(&iommu->register_lock, flag);
1304         fault_status = readl(iommu->reg + DMAR_FSTS_REG);
1305         if (fault_status)
1306                 pr_err("DRHD: handling fault status reg %x\n", fault_status);
1307 
1308         /* TBD: ignore advanced fault log currently */
1309         if (!(fault_status & DMA_FSTS_PPF))
1310                 goto clear_rest;
1311 
1312         fault_index = dma_fsts_fault_record_index(fault_status);
1313         reg = cap_fault_reg_offset(iommu->cap);
1314         while (1) {
1315                 u8 fault_reason;
1316                 u16 source_id;
1317                 u64 guest_addr;
1318                 int type;
1319                 u32 data;
1320 
1321                 /* highest 32 bits */
1322                 data = readl(iommu->reg + reg +
1323                                 fault_index * PRIMARY_FAULT_REG_LEN + 12);
1324                 if (!(data & DMA_FRCD_F))
1325                         break;
1326 
1327                 fault_reason = dma_frcd_fault_reason(data);
1328                 type = dma_frcd_type(data);
1329 
1330                 data = readl(iommu->reg + reg +
1331                                 fault_index * PRIMARY_FAULT_REG_LEN + 8);
1332                 source_id = dma_frcd_source_id(data);
1333 
1334                 guest_addr = dmar_readq(iommu->reg + reg +
1335                                 fault_index * PRIMARY_FAULT_REG_LEN);
1336                 guest_addr = dma_frcd_page_addr(guest_addr);
1337                 /* clear the fault */
1338                 writel(DMA_FRCD_F, iommu->reg + reg +
1339                         fault_index * PRIMARY_FAULT_REG_LEN + 12);
1340 
1341                 spin_unlock_irqrestore(&iommu->register_lock, flag);
1342 
1343                 dmar_fault_do_one(iommu, type, fault_reason,
1344                                 source_id, guest_addr);
1345 
1346                 fault_index++;
1347                 if (fault_index >= cap_num_fault_regs(iommu->cap))
1348                         fault_index = 0;
1349                 spin_lock_irqsave(&iommu->register_lock, flag);
1350         }
1351 clear_rest:
1352         /* clear all the other faults */
1353         fault_status = readl(iommu->reg + DMAR_FSTS_REG);
1354         writel(fault_status, iommu->reg + DMAR_FSTS_REG);
1355 
1356         spin_unlock_irqrestore(&iommu->register_lock, flag);
1357         return IRQ_HANDLED;
1358 }

1296 irqreturn_t dmar_fault(int irq, void *dev_id)

1297 {

1298 struct intel_iommu *iommu = dev_id;

1299 int reg, fault_index;

1300 u32 fault_status;

1301 unsigned long flag;

1302

1303 spin_lock_irqsave(&iommu->register_lock, flag);

1304 fault_status = readl(iommu->reg + DMAR_FSTS_REG);

1305 if (fault_status)

1306 pr_err("DRHD: handling fault status reg %x\n", fault_status);

1307

1308 /* TBD: ignore advanced fault log currently */

1309 if (!(fault_status & DMA_FSTS_PPF))

1310 goto clear_rest;

1311

1312 fault_index = dma_fsts_fault_record_index(fault_status);

1313 reg = cap_fault_reg_offset(iommu->cap);

1314 while (1) {

1315 u8 fault_reason;

1316 u16 source_id;

1317 u64 guest_addr;

1318 int type;

1319 u32 data;

1320

1321 /* highest 32 bits */

1322 data = readl(iommu->reg + reg +

1323 fault_index * PRIMARY_FAULT_REG_LEN + 12);

1324 if (!(data & DMA_FRCD_F))

1325 break;

1326

1327 fault_reason = dma_frcd_fault_reason(data);

1328 type = dma_frcd_type(data);

1329

1330 data = readl(iommu->reg + reg +

1331 fault_index * PRIMARY_FAULT_REG_LEN + 8);

1332 source_id = dma_frcd_source_id(data);

1333

1334 guest_addr = dmar_readq(iommu->reg + reg +

1335 fault_index * PRIMARY_FAULT_REG_LEN);

1336 guest_addr = dma_frcd_page_addr(guest_addr);

1337 /* clear the fault */

1338 writel(DMA_FRCD_F, iommu->reg + reg +

1339 fault_index * PRIMARY_FAULT_REG_LEN + 12);

1340

1341 spin_unlock_irqrestore(&iommu->register_lock, flag);

1342

1343 dmar_fault_do_one(iommu, type, fault_reason,

1344 source_id, guest_addr);

1345

1346 fault_index++;

1347 if (fault_index >= cap_num_fault_regs(iommu->cap))

1348 fault_index = 0;

1349 spin_lock_irqsave(&iommu->register_lock, flag);

1350 }

1351 clear_rest:

1352 /* clear all the other faults */

1353 fault_status = readl(iommu->reg + DMAR_FSTS_REG);

1354 writel(fault_status, iommu->reg + DMAR_FSTS_REG);

1355

1356 spin_unlock_irqrestore(&iommu->register_lock, flag);

1357 return IRQ_HANDLED;

1358 }

请注意行号1343，dmar_fault_do_one()会报告fault的具体信息，包括对应设备的物理位置。由于一个dmar对应着很多个I/O设备，这条信息可以帮助定位到具体哪一个设备。源代码如下：

1270 static int dmar_fault_do_one(struct intel_iommu *iommu, int type,
1271                 u8 fault_reason, u16 source_id, unsigned long long addr)
1272 {
1273         const char *reason;
1274         int fault_type;
1275 
1276         reason = dmar_get_fault_reason(fault_reason, &fault_type);
1277 
1278         if (fault_type == INTR_REMAP)
1279                 pr_err("INTR-REMAP: Request device [[%02x:%02x.%d] "
1280                        "fault index %llx\n"
1281                         "INTR-REMAP:[fault reason %02d] %s\n",
1282                         (source_id >> 8), PCI_SLOT(source_id & 0xFF),
1283                         PCI_FUNC(source_id & 0xFF), addr >> 48,
1284                         fault_reason, reason);
1285         else
1286                 pr_err("DMAR:[%s] Request device [%02x:%02x.%d] "
1287                        "fault addr %llx \n"
1288                        "DMAR:[fault reason %02d] %s\n",
1289                        (type ? "DMA Read" : "DMA Write"),
1290                        (source_id >> 8), PCI_SLOT(source_id & 0xFF),
1291                        PCI_FUNC(source_id & 0xFF), addr, fault_reason, reason);
1292         return 0;
1293 }

1270 static int dmar_fault_do_one(struct intel_iommu *iommu, int type,

1271 u8 fault_reason, u16 source_id, unsigned long long addr)

1272 {

1273 const char *reason;

1274 int fault_type;

1275

1276 reason = dmar_get_fault_reason(fault_reason, &fault_type);

1277

1278 if (fault_type == INTR_REMAP)

1279 pr_err("INTR-REMAP: Request device [[%02x:%02x.%d] "

1280 "fault index %llx\n"

1281 "INTR-REMAP:[fault reason %02d] %s\n",

1282 (source_id >> 8), PCI_SLOT(source_id & 0xFF),

1283 PCI_FUNC(source_id & 0xFF), addr >> 48,

1284 fault_reason, reason);

1285 else

1286 pr_err("DMAR:[%s] Request device [%02x:%02x.%d] "

1287 "fault addr %llx \n"

1288 "DMAR:[fault reason %02d] %s\n",

1289 (type ? "DMA Read" : "DMA Write"),

1290 (source_id >> 8), PCI_SLOT(source_id & 0xFF),

1291 PCI_FUNC(source_id & 0xFF), addr, fault_reason, reason);

1292 return 0;

1293 }

dmar的初始化是kernel根据ACPI中的dmar table进行的，每一个表项对应一个dmar设备，名称从dmar0开始依次递增，涉及取名的代码如下：

0751 int alloc_iommu(struct dmar_drhd_unit *drhd)
0752 {
0753         struct intel_iommu *iommu;
0754         u32 ver;
0755         static int iommu_allocated = 0;
0756         int agaw = 0;
0757         int msagaw = 0;
0758         int err;
0759 
0760         if (!drhd->reg_base_addr) {
0761                 warn_invalid_dmar(0, "");
0762                 return -EINVAL;
0763         }
0764 
0765         iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);
0766         if (!iommu)
0767                 return -ENOMEM;
0768 
0769         iommu->seq_id = iommu_allocated++;
0770         sprintf (iommu->name, "dmar%d", iommu->seq_id);
...
0797         pr_info("IOMMU %d: reg_base_addr %llx ver %d:%d cap %llx ecap %llx\n",
0798                 iommu->seq_id,
0799                 (unsigned long long)drhd->reg_base_addr,
0800                 DMAR_VER_MAJOR(ver), DMAR_VER_MINOR(ver),
0801                 (unsigned long long)iommu->cap,
0802                 (unsigned long long)iommu->ecap);
...

0751 int alloc_iommu(struct dmar_drhd_unit *drhd)

0752 {

0753 struct intel_iommu *iommu;

0754 u32 ver;

0755 static int iommu_allocated = 0;

0756 int agaw = 0;

0757 int msagaw = 0;

0758 int err;

0759

0760 if (!drhd->reg_base_addr) {

0761 warn_invalid_dmar(0, "");

0762 return -EINVAL;

0763 }

0764

0765 iommu = kzalloc(sizeof(*iommu), GFP_KERNEL);

0766 if (!iommu)

0767 return -ENOMEM;

0768

0769 iommu->seq_id = iommu_allocated++;

0770 sprintf (iommu->name, "dmar%d", iommu->seq_id);

...

0797 pr_info("IOMMU %d: reg_base_addr %llx ver %d:%d cap %llx ecap %llx\n",

0798 iommu->seq_id,

0799 (unsigned long long)drhd->reg_base_addr,

0800 DMAR_VER_MAJOR(ver), DMAR_VER_MINOR(ver),

0801 (unsigned long long)iommu->cap,

0802 (unsigned long long)iommu->ecap);

...

上面也揭示了boot过程留在dmesg中信息的来历：

dmar: IOMMU 0: reg_base_addr f8ffe000 ver 1:0 cap d2078c106f0462 ecap f020fe

1	dmar: IOMMU 0: reg_base_addr f8ffe000 ver 1:0 cap d2078c106f0462 ecap f020fe

附注：过去的AMD64芯片也提供一个功能有限的地址转译模块——GART (Graphics Address Remapping Table)，有时候它也可以充当IOMMU，这导致了人们对GART和新的IOMMU的混淆。最初设计GART是为了方便图形芯片直接读取内存：使用地址转译功能将收集到内存中的数据映射到一个图形芯片可以“看”到的地址。后来GART被Linux kernel用来帮助传统的32位PCI设备访问可寻址范围之外的内存区域。这件事新的IOMMU当然也可以做到，而且没有GART的局限性（它仅限于显存的范围之内），IOMMU可以将I/O设备的任何DMA地址转换为物理内存地址。

参考资料：
Linux Kernel的Intel-IOMMU.txt
Intel’s Virtualization for Directed I/O (a.k.a IOMMU)
Wikipedia IOMMU
理解IOMMU、北桥、MMIO和ioremap
Intel Virtualization Technology for Directed I/O