CPU的复用和调度使得每一个进程都产生了自己独立占有CPU的假象。
第一阶段在M-Mode下首先触发一个S-Mode下的软中断
进入内核进程
一系列的合法性检查
获取当前进程以及锁多个核心在访问进程时也有可能产生并发的问题，故每一个进程结构体也需要锁的保护
虚拟化操作系统的其中一个重要功能是虚拟化(Virtulization)
修改进程状态为RUNNNABLE
第一次调用swtch，换入内核线程，并换出当前的旧线程
usertrap或kerneltrap函数触发yield()函数让出当前CPU的使用权
物理内存虚拟化通过引入页表和请求分页机制，使得操作系统可以动态和灵活地完成虚拟地址到物理地址的映射。这样给每个进程也造成了一种它可以操纵一大片连续空闲内存的假象，事实上它只占据一小部分离散的真实的物理内存，但虚拟寻址空间却显得非常大
睡眠锁(sleeplock)进而催生出了Sleep&Wakeup机制，在这种机制下也会发生CPU的调度。
详细探讨了Xv6操作系统中，时钟中断如何触发CPU调度，重点分析了yield函数、sched函数和swtch汇编代码在进程切换中的作用。
注意点1——scheduler与yield中的跨进程锁机制
第二阶段响应软中断，通过devintr函数的转发和识别
时钟中断
记录当前CPU原始的中断开关状态
每个CPU都有一个的进程的调度器 每个CPU都会在初始化完成之后调用scheduler()函数 scheduler函数永不返回，而是保持死循环做以下事情： -选择一个进程执行-调用swtch(第二次调用swtch)来执行新进程 -最终进程会将控制权通过swtch再次转回scheduler(即下一次调度)
时钟中断导致的当前进程让出CPU使用权
调用sched完成当前进程上下文的保存
kernel/proc.ckernel/swtch.Skernel/main.c
注：旧进程的yield上半部加锁，内核进程下半部解开内核线程上半部加锁，新线程下半部解开下次时钟中断时，继续重复这个过程
内核进程为何会一直在scheduler函数中等待？文件kenrel/main.c，执行main函数的进程都是内核进程，我们可以在下面的代码中看到，monitor core和application core在最后都会转入scheduler函数。所以后面我们因为时钟中断而让出CPU时，内核进程会一直在scheduler函数中等待着我们。
下一次再次返回时恢复进程在此CPU的原始中断开关状态
Xv6中是通过多次交换的方式来实现进程切换的，调用一次swtch函数完成一次交换动作
voidsched(void)
voidscheduler(void)
voidyield(void)
