本篇文章基于qemu2.6.0，Linux3.10.0内核，x86体系结构。Qemu与KVM同步脏页位图主要分为Qemu与KVM两部分，我们先来看看Qemu部分。
Linux内核启动流程分为如下几个阶段：
下面我们一一进行分析。阅读整篇文章的同时，可以参考内核源代码文档 Documentation\i386\boot.txt。本篇文章基于Linux 2.6.24
本篇文章基于Linux 2.6.32，x86体系结构
系统的引导和初始化阶段是个特例，因为在这个阶段里系统中只有一个“上下文”，只能由一个处理器来处理。在这个阶段里，也就是在系统刚加电或“总清（reset）”之后，系统中暂时只有一个处理器运行，这个处理器称之为“引导处理器”BP；其余的处理器则处于暂停状态，称为“应用处理器”AP。“引导处理器”完成整个系统的引导和初始化，并创建起多个进程，从而可以由多个处理器同时参与处理时，才启动所有的“应用处理器”，让他们完成自身的初始化以后，投入运行。参考intel手册：
The MP initialization protocol defines two classes of processors: the bootstrap processor (BSP) and the application processors (APs). Following a power-up or RESET of an MP system, system hardware dynamically selects one of the processors on the system bus as the BSP. The remaining processors are designated as APs.
我们在这里关心的是“引导处理器”怎样为各个“应用处理器”做好准备，然后启动其运行的过程。
基于Linux 2.6.32内核进行分析，看本篇文章前，建议先看看percpu变量这篇文章
smp_processor_id()用来获取当前cpu的id，首先来看smp_processor_id的定义：
# define smp_processor_id() raw_smp_processor_id()
接下来：
#define raw_smp_processor_id() (percpu_read(cpu_number))
本篇文章基于Linux 2.6.24
percpu变量的关键就是：要求根据CPU的个数，在内存中生成多份拷贝，并且能够根据变量名和CPU编号，正确的对各个CPU的变量进行寻址。
采用per-cpu变量有下列好处：所需数据很可能存在于处理器的缓存中，因此可以更快速地访问。如果在多处理器系统中多个CPU可能同时访问变量，会引发一些通信方面的问题，采用percpu变量恰好规避了这个问题。
本文章转载于http://xichen.pub/2018/01/31/2018-01-31-gitment/，并在其基础上进行完善
Application Name: gitment评论 //随便填
Homepage Url: https://frankjkl.github.io //博客的域名
Application description: //随便填，留空也可以
Authorization Callback URL: https://frankjkl.github.io //一定要写自己Github Pages的URL
注册成功后会得到Client ID和Client Secret