前言： 在《clocksource的管理和虚拟化》中，大概分析了kvm clock，tsc，hpet等clock source。其中尤其是kvm clock计算尤其复杂。其目的就在于让Guest中的clock更加准确。但是问题还没有完，Guest只是在Host中的一个进程，还是会发生时钟跳变。下文具体分析。 分析： 1，analysis 当前Host的墙上时间是HWT1，此时Guest中的墙上时间GWT1，如果是同一个时区的话，此时HWT1和GWT1是相等的。 如果此时Host中发生了调度，Guest所在的qemu进程不执行了，那么HWT1将继续增长，GWT1是否应该增长呢？ 如果GWT1不增长，那么等到Guest继续执行的时候，就会继续在原来的GWT1基础上增长，那么HWT2到HWT1之间的时间就发生了丢失；现象就是Guest中的时间变慢了。 如果GWT1同时增长，那么就会在Guest进程切回来继续执行的时候，Guest中的时间会瞬间增大了HWT2减掉HWT1的差值。现象就是Guest的墙上时间是对的了。可是新的问题又来了：在Guest的quemu进程被Host切换之前，Guest中刚刚切换走redis，开始执行Nginx；等到Guest继续执行的时候，因为Guest中的时钟跳变增大了很多，Guest会认为Nginx执行了大量的CPU时间。如果Guest中是Linux采用cfs调度算法的话，那么Nginx下次被调度会隔比较长的时间。可是实际呢，Nginx根本没有得到执行！！！ 2，steal time 为了解决上述的Guest中的调度问题，就引入了steal time。 Steal time的原理就是：告诉Guest，哪些时间被Host给steal了，调度的时候，忽略这部分时间，就可以正确调度了。 所以，基本就是两个部分：在Host中通知Guest具体的steal time是多少；在Guest中处理这些时间，修正因时间跳变引起的调度错误。 3，guest register steal time linux-4.0.4/arch/x86/kernel/kvm.c
原理和kvm clock一样：通过写MSR，把per_cpu变量steal_time的物理地址（Guest Physical Address）告诉Host。 4，host steal time linux-4.0.4/include/linux/sched.h中：
注意看run_delay，如注释，就是task等待的时间，也就是没有执行的时间（例子中Guest的qemu被切换走的时间）。具体的计算逻辑在linux-4.0.4/kernel/sched目录下的文件中，不具体分析。
在Host中，用run_delay计算出来Guest的steal time，并通过kvm_write_guest_cached告诉Guest（前文中Guest向Host注册的地址，Host直接修改）。 这样，在Guest恢复执行的时候，就可以知道steal time的具体大小了。 5，guest steal time linux-4.0.4/kernel/sched目录下的调度源代码中，计算steal time。 如果Guest的编译选项中打开了CONFIG_PARAVIRT_TIME_ACCOUNTING了，就可以在/proc/stat中的第八项看到steal time。 后记： clocksource虚拟化，再加上steal time机制，基本可以保证Guest中的时间同步问题了。 当然，在Guest中启用ntp服务也是可以的。。 如果Guest的linux版本比较低，或者windows，前后两次gettimeofday得到的时间差别很大，可以怀疑这里。 Good Luck～
