CPU的自我控制-异常之于虚拟化

很难说直接从第一页开始阅读分析完所有ARMv8-A指令集后，就能搞清楚虚拟化与ARMv8-A指令集的事情，毕竟老虎咬天也是无处下口。

不能广度优先搜索，就得先搞搞深度优先了，于是就要找一个关键的点作为入口，这个入口需要符合两个要素：

1.足够关键：不是关键点不足以涉及关键问题，也不足以充分描述虚拟化与ARMv8-A的事情。

2.有知识基础，但不是充足的知识基础：如果这个切入点上，连基本的断言性认知都缺乏，如何敢于猜测，更何谈论证(基本公理都没有建立，搞毛线推论，更别扯什么证明了)；而充分的知识基础意思就是可以直接用嘴说了，就不用费这个劲了。

然后，就找到了异常这个入口。

——————————————异常之于虚拟化——————————————

根据我的认知，CPU没有对虚拟化的支持，虚拟化依旧可以实现(出门左拐JAVA虚拟机，当然，右拐dalvik也可以)，这是指令不会直接运行在CPU上的虚拟化，效率自不必说；而有了硬件支持的虚拟化，最关键的问题就是指令流(我为什么不好好的说"程序"-而是说指令流))可以直接运行在CPU上。

指令直接运行在CPU意味着(什么呢)：在没有虚拟化支持的CPU上，指令直接运行在CPU上就意味着这个程序拥有了对CPU的完全处置权。或许调度中断等可以打断当前指令流水的运行，但是当前指令流运行时是可以对所有内存、外设、即计算机整体进行任意修改，也就是可以修改一下调度中断的处理函数，然后劫持整个计算机。

而对存在虚拟化支持的CPU却不是这样，支持虚拟化的CPU的指令集中很多敏感指令附带有异常，我为什么说附带有异常呢，是因为这些指令执行时会检查相关寄存器状态，这些寄存器的状态就会使指令按照不同的方式执行(对，这就是CPU的自我控制)，描述时检查寄存器状态似乎会花时间执行检查，其实在硬件设计中就是有一个开关决定指令的执行方式(另外请不要考虑两阶段MMU访存异常，那对虚拟化非常关键，但是我们先不把它加入)。这些状态与指令进行了有机结合，就可以按照指令集规定的机制改变指令流的执行。当指令流执行了一个附带异常的指令，如果CPU相关寄存器的设置决定这个状态下指令附带的异常会被触发，那么CPU就会轻飘飘的将这条指令流截断，欢快的跑到早就预备好的异常处理指令序列开始执行，如果CPU相关寄存器的设置决定这个状态下的指令附带的异常不会被触发，那么指令流就会继续走下去，如此，就对指令流中的指令序列的能力进行了限制，指令流的执行范围也就能够被限制。

上面所说的这种限制与内存访问的限制还是存在机制上的不同的，指令流的限制是说CPU所处状态(特权等级x)下能够执行的指令的限制；能够实现内存限制的是伟大的页表同学， 那个另说。

这一大篇絮絮叨叨的文字，其实在别处的表述可能会很简单，比如：这个CPU支持虚拟化，ARMv8开始支持虚拟化啦；但是很明显，技术细节的现实远比简单的表述复杂的多的多的多的多。

——————————————异常之于syscall——————————————