买本书看吧，比如《处理器虚拟化技术》。

哎！书看了不少！没明白！

驱动A或者B进入虚拟化模式之后，如果它自己没有写针对嵌套虚拟化的处理，那么其他驱动是无法开启虚拟化的

谢谢有用的回答。
你的意思是不是说驱动A开启虚拟化后，如果驱动A不做嵌套虚拟化的处理（不知道什么是嵌套虚拟化处理）的话，驱动B就进不了虚拟化。也就上谁先占用了虚拟化就谁说的算了是吗

是的

1） 目前CPU硬件只支持VMX root和VMX Non-root两层，假设有A,B 两个hypervisor,
    先加载的那个（假设是A）才执行在VMX root模式，如果A支持嵌套虚拟化,那么
    A会拦截B的VMX能力查询以及VMX指令执行，为B提供运行在真实的而且是支持VT-x的
    CPU上的假象。B其实是执行在VMX Non-root下的。对A而言B不过是个特殊的guest。

    现在假设C是执行在VMX Non-root下的guest，执行CPUID时会陷入A(A才是真正
    的hypervisor)。如何处理，A可以有不同的策略：

    A可以直接模拟CPUID指令,然后VMRESUME恢复C的执行。也可以交给B处理，B以为
   自己跑在真实CPU上并接收到VM-exit，这个过程称为virtual VM-exit。当B完成处理
   执行VMRESUME时被A拦截，A负责恢复C的执行，这叫virtual VM-entry。

    实现这个功能是A的职责。A拦截所有VMX指令，所以清楚地知道执行在VMX Non-root
   模式的是B还是C。嵌套虚拟化的原理虽然不难理解，真要实现起来却非常繁琐。你可以
    想象一下写个CPU模拟器，支持所有VT-x特性(BOCHS还未完全做到)。

   所以说，C看到的是什么，完全取决于A。

2)  VMX的目的是简化虚拟化开发以及提升虚拟化应用的执行效率，跟传统的操作系统以及
    驱动、进程没有关系，跟所谓Hook更没关系。你非要把这种“陷入/模拟”的执行流程
    叫做一种hook也无不可。

    虚拟化的本质是要获取全部硬件的控制权，拦截在硬件和传统操作系统之间。在传统操作系统
    看来跟执行在真正的硬件上没有差别（等价性原则）。

    虽然VMX指令一般执行在ring0权限，但VMX root 和VMX Non-root与特权级是不同的
    概念，VMX root下也有ring0,ring3特权级，或者说你可以开发一个完全跑在 VMX root下
    的操作系统。

    换种方式说，成功执行了VMXON指令，就进入了VMX root模式。此时执行的代码就是VMM
   或者叫hypervisor。VMM调度vCPU的执行，通过VMLAUNCH/VMRESUME使CPU执行在
    VMX non-root下时，称为guest。

谢谢

SdKfz 1） 目前CPU硬件只支持VMX root和VMX Non-root两层，假设有A,B 两个hypervisor,     先加载的那个（假设是A）才执行在VMX ...

这里我想问个问题，如果A拦截到了cpuid事件并想把cpuid事件先交给B处理，然后A再处理B的cpuid事件，那该怎么做