xv6 磁盘中断流程和启动时调度流程

本文讲述 xv6 中的一些细节流程，还有对之前文中遗留的问题做一些补充说明，主要有以下几个问题：

1. 一次完整的磁盘中断流程
2. 进入调度器后的详细流程
3. sched 函数中的条件判断
4. scheduler 函数中为什么要周期性关中断

一次完整的磁盘流程

此节讲述完整的磁盘读写流程，读写的流程总体差不多，这里以读为例子，先看“流程图”（看代码时的笔记图）

read
    int $T_SYSCALL
        sys_read
            fileread
                readi
                    bread
                        bget
                        iderw
                            idestart

还是从 A 进程的用户态 read 函数开始：

1. A 进程用户态调用 read 读取磁盘上的数据
2. read 通过 INT 0x80 软件中断，通过中断门进入内核，此时会关中断（NOTE 这里我以中断门来实现系统调用为例，会关中断，xv6 源代码是以陷阱门实现系统调用，不会关中断）
3. 期间多次取锁放锁，进行了多次 pushcli 和 popcli，但总是成对存在，所以目前总体还是处于 0 次 puchcli 状态
4. 如果磁盘数据没有缓存，调用 iderw 来读写磁盘

A 进程内核态，iderw 函数：

1. acquire(&idelock)，获取磁盘锁，pushcli，cpu.IF = 0，1 次pushcli 状态
2. 调用 idestart，将要读写的命令，扇区号等信息写进磁盘端口，以此来请求磁盘操作。写磁盘端口是通过 out 指令实现的。向磁盘发送命令后，磁盘就会工作，磁盘完成工作后就会向 cpu 发送中断信号。
3. A 进程调用 sleep 等待磁盘操作完成。在 sleep 函数中，获取 ptable.lock，释放 idelock，然后调用 sched 让出

by the way，这里补充说明 sched 函数中的条件检查，之前的文章都一笔带过了：

void sched(void)   //让出CPU，重新调度
{
  int intena;
  struct proc *p = myproc();

  if(!holding(&ptable.lock))      // 必须持有 ptable.lock
    panic("sched ptable.lock");
  if(mycpu()->ncli != 1)          // 1 次 pushcli 状态
    panic("sched locks");
  if(p->state == RUNNING)         // 只可能是 SLEEPING、RUNNABLE、ZOMBIE 三种状态之一
    panic("sched running");
  if(readeflags()&FL_IF)          // 此时肯定处于关中断状态(通过中断门进入内核会关中断，1次pushcli状态也应该对应关中断状态)
    panic("sched interruptible");
  intena = mycpu()->intena;
  swtch(&p->context, mycpu()->scheduler);
  mycpu()->intena = intena;
}

sched 函数中有 4 个条件检查：

1. xv6 是个多 CPU 多任务系统，在 sched 任务调度的时候，需要持有 ptable.lock，不然进程的上下文会发生紊乱，举个简单的例子，A 时间片到了，先将 A 的状态设置为 RUNNABLE，然后调用 sched 让出 CPU，如果此时没有持有 ptable.lock，那么 A 进程便可能在另一个 CPU 上被调度，那么便出现一个进程在两 CPU 上运行的情况，Error
2. 在 sched 函数中应当只有 1 次 pushcli 状态，这个条件检查感觉有点难以理解。从实践看代码确实，不管从哪条路径到达 sched 函数，都应该只有 1 次 pushcli，这是获取 ptable.lock 的锁造成的。从个人理解上说，sched 是为了调度进程，是要从 A 进程到 B 进程，那么 A 进程的开关中断(pushcli popcli 次数)不应该带入 B 进程，除了一种情况——调度，那就是 A 进程获取 ptable.lock 但是要在 B 进程中释放 ptable.lock。所以 sched 中应当只有 1 次 pushcli
3. 在真正切换进程上下文之前，会首先修改旧进程的状态，在 xv6 中是 SLEEPING、RUNNABLE、ZOMBIE 三种之一
4. 在 sched 中理应处于关中断状态，如果是通过中断门进入内核的，那么本身就处于关中断。如果是通过陷阱门进入内核，那么有 1 次 pushcli，也会处于关中断状态

回到磁盘中断，当 A 进程调用 sched 切换到 B 进程，这里假如 B 进程最初是因为时间片到了，调用 yield->sched->swtch 主动让出 CPU 的，则 B 进程的流程如下：

1. 回到 B 进程 sched 函数中的 swtch 下一条指令处，然后释放 ptable.lock，此时 cpu.IF = 0，0 次 pushcli 状态，cpu.IF = 0 仍然处于关中断状态 是因为 A 进程通过中断门进入内核关中断造成的
2. B 进程经过一些列指令后，最后执行 iret 返回 B 进程的用户态，此时会开中断
3. NOTE，这里我们假设 CPU 内部逻辑：每条指令执行后都会检查是否有中断发生，如果有中断发生且开中断的情况下，则去处理中断。再假设，此前的磁盘操作已完成，已经向 CPU 发生了中断信号。但是在此之前 CPU 一直没有去处理中断，是因为在此之前一直处于关中断状态。
4. Now，CPU 处于开中断状态，继续执行 B 进程的指令，开中断后的第一条指令执行完成后，检查是否有中断发生，发现有磁盘中断，那么中断 B 进程，通过中断门进入内核(该过程关中断)
5. 执行磁盘中断处理程序，也就是执行 insl 指令从 0x1f0 端口将磁盘数据读取到内存，然后唤醒等待该磁盘事件的进程，在我们的例子当中就是 A 进程
6. 中断执行完成，iret 返回 B 进程用户态(该过程开中断)
7. 继续执行 B 进程的指令
8. 时钟中断 B 进程，再次通过中断门进入内核(关中断)，发现 B 进程的时间片到了，那么调用 yield->sched->swtch 重新调度进程，这里假设调度到 A 进程

回到 A 进程的内核态，准确来说回到 iderw->sleep->sched->swtch 的下一条指令

1. A 进程执行 release(ptable.lock)、acquire(idelock)、release(idelock)，此时状态： cpu.IF = 0，0 次 pushcli
2. 将磁盘中断获取的数据 cp 到 A 进程内核态
3. A 进程层层返回
4. 最后 iret 返回 A 进程用户态(开中断)

系统启动进入调度器后的流程

main
    userinit //准备好 initcode 进程
    mpmain
        scheduler  // 进入调度器

调度器上下文：

1. 第一次进入 scheduler，for 循环找到 RUNNABLE 进程，目前就只有一个 initcode 进程为 RUNNABLE 进程，找到并切换上下文到 initcode 进程

initcode 进程上下文：

1. 执行 forkret 函数，因为是第一次执行，会首先执行 iinit 来初始化根文件系统
2. 执行 readsb 从磁盘中读取超级块数据，期间会使用 iderw 读写磁盘，具体流程见第一小节。总之，initcode 进程会调用 sleep 函数让出 CPU 来等待磁盘操作
3. 在 sleep->sched->swtch 中再次切换上下文到 调度器上下文

调度器上下文：

1. 切换到内核页表，然后遍历任务队列，寻找 RUNNABLE 进程，但是目前只有一个且处于 SLEEPING 状态的进程，所以这里调度器会轮询空转，直到磁盘中断处理完成，initcode 进程被唤醒。
2. 再次切换上下文到 initcode 进程

initcode 进程上下文

1. 回到 forkret->iinit->readsb->bread->iderw->sleep->sched->swtch 的下一条指令处，然后层层返回到 forkret
2. 再执行 initlog 恢复日志，这里会涉及到两次磁盘读写，道理同上，不再赘述
3. 第 4 次调度到 initcode 进程后，forkret 函数执行完毕，再执行 trapret 函数，其中包含了 iret 指令，至此回到用户态，开始执行 initcode 进程的逻辑

by the way again，这里解释为什么在 scheduler 函数中需要周期性的开中断：

void scheduler(void)
{
  for(;;){
    sti();    // 周期性开中断

    for(p = ptable.proc; p < &ptable.proc[NPROC]; p++){  //循环找一个RUNNABLE进程
        ...
    }
    
  }
}

进入调度器上下文有两条路径：

1. 系统刚启动进入 scheduler
2. sched 函数中 swtch 上下文到调度器

回想前面说的 sched 函数，在它切换到新进程并返回用户态之前理应都处于关中断的状态。而一直处于关中断且没有开中断的话会引发死循环。

举个例子，假设没有周期性的开中断，也就是 scheduler 代码长这样的话：

void scheduler(void)
{
  for(;;){
    // 遍历进程列表，寻找 RUNNABLE 进程
    for(p = ptable.proc; p < &ptable.proc[NPROC]; p++){
        ...
    }
  }
}

假如当前系统只有一个进程（shell进程），它需要等待键盘输入而被阻塞(state==SLEEPING)，内层循环是找不到 RUNNABLE 进程的，便回到外层循环，外层循环现在相当于什么也不做，便又再次进入内层循环。如此下来死循环。

而加入周期性的开中断后，CPU 便会响应中断。当有键盘输入时，中断当前的调度上下文而进入中断上下文，执行键盘中断处理程序，唤醒 shell 进程，中断处理完成后再回到调度上下文。此时内层循环便能找到一个 RUNNABLE 进程，然后切换到它的上下文执行。

本文就先补充这么多吧，这补充系列的文章是之前做了关于 xv6、nemu 的项目，将 xv6 启动到 nemu 上，这需要对很多地方细扣，对 xv6 的理解又增加了一些，分享出来。

停更这么久啊，一直再忙工作，学习新的东西，时间不是很多，当然也有懒的原因，后面慢慢克服回归吧。OK，那有什么问题欢迎来讨论交流。