物理时间4ms，每个vCPU运行2ms，如果设置vCPU0在T=0之后的3ms后产生中断，那希望是物理时间的3ms后（也就是vCPU0的虚拟时间2ms）产生中断，还是虚拟时间3ms后产生中断？ARM体系结构支持这两种设置；
运行在vCPU上的软件可以同时访问两种时钟：EL1物理时钟和EL1虚拟时钟；
EL1物理时钟和EL1虚拟时钟：
EL1物理时钟与系统计数器模块直接比较，使用的是wall-clock时间；
EL1虚拟时钟与虚拟计数器比较，而虚拟计数器是在物理计数器上减去一个偏移；
Hypervisor负责为当前调度运行的vCPU指定对应的偏移，这种方式使得虚拟时间只会覆盖vCPU实际运行的那部分时间；
来一张示例图：
6ms的时间段里，每个vCPU运行3ms，Hypervisor可以使用偏移寄存器来将vCPU的时间调整为其实际的运行时间；
2.6 Virtualization Host Extensions（VHE）先抛出一个问题：通常Host OS的内核都运行在EL1，而控制虚拟化的代码运行在EL2，这就意味着传统的上下文切换，这个显然是比较低效的；
VHE用于支持type-2的Hypervisor，这种扩展可以让内核直接跑在EL2，减少host和guest之间共享的系统寄存器数量，同时也减少虚拟化的overhead；
VHE由系统寄存器HCR_EL2的E2H和TGE两个比特位来控制，如下图：
VHE的引入，需要考虑虚拟地址空间的问题，如下图：
我们在内存子系统分析时提到过虚拟地址空间的问题，分为用户地址空间（EL0）和内核地址空间（EL1），两者的区域不一致，而在EL2只有一个虚拟地址空间区域，这是因为Hypervisor不支持应用程序，因此也就不需要分成内核空间和用户空间了；
EL0/EL1虚拟地址空间也同时支持ASID(Address Space Identifiers)，而EL2不支持，原因也是Hypervisor不需要支持应用程序；
从上两点可以看出，为了支持Host OS能运行在EL2，需要添加一个地址空间区域，以及支持ASID，设置HCR_EL2.E2H的寄存器位可以解决这个问题，如下图：
Host OS运行在EL2需要解决的另一个问题就是寄存器访问重定向，在内核中需要访问EL1的寄存器，比如TTBR0_EL1，而当内核运行在EL2时，不需要修改内核代码，可以通过寄存器的设置来控制访问流，如下图：
重定向访问寄存器引入一个新的问题，Hypervisor在某些情况下需要访问真正的EL1寄存器，ARM架构引入了一套新的别名机制，以_EL12/_EL02结尾，如下图，可以在ECH==1的EL2访问TTBR0_EL1：
Host OS运行在EL2还需要考虑异常处理的问题，前边提到过HCR_EL2.IMO/FMO/AMO的比特位可以用来控制物理异常路由到EL1/EL2。当运行在EL0且TGE==1时，所有物理异常都会被路由到EL2（除了SCR_EL3控制的），这是因为Host Apps运行在EL0，而Host OS运行在EL2。
2.7 总结本文涉及到内存虚拟化（stage 2转换），I/O虚拟化（包含了SMMU，中断等），中断虚拟化，以及指令trap and emulation等内容；
基本的套路就是请求虚拟化服务时，路由到EL2去处理，如果有硬件支持的则硬件负责处理，否则可以通过软件进行模拟；
尽管本文还没涉及到代码分析，但是已经大概扫了一遍了，大体的轮廓已经了然于胸了，说了可能不信，我现在都有点小兴奋了；
参考