3. Hypervisor框架
KVM/ARM是利用LInux内核中现有的基础来实现的,如果重新设计和实现hypervisor复杂的核心功能,这将可能引入一些知名的bug。虽然单独的hypervisor设计方式具有更好的性能和更小的TCB,但是该种方式并不适合ARM架构。ARM硬件在很多方面都比x86更加多样化。不同的设备制造商通常以非标准的方式将硬件组件集成到ARM设备中。ARM硬件缺乏用于硬件探测的功能,例如标准BIOS或APCI总线,并且没有为安装低级软件建立相关机制。但是巨虎所有的ARM平台都支持Linux,通过将KVM/ARM与Linux进行集成,KVM/ARM可自动得进行版本迭代。而XEN则必须积极支持每个安装在XEN hypervisor的平台。例如,对于XEN需要支持的每个新的SoC,开发人员必须在核心Xen hypervisor中实现一个新的串行设备驱动程序。而KVM/ARM得益于其集成在Linux中,其可移植性和硬件支持方面,我们需要解决的一个关键问题是ARM硬件虚拟化扩展是被设计成完全独立于任何标准内核的功能。接下来我们将描述KVM/ARM的新设计,该设计使将有利于将其集成到现有的Linux内核中,同时是其支持硬件虚拟化。
3.1 split-mode虚拟化
完全以ARM的Hyp模式运行hypervisor是很有吸引力的,因为它是最具有特权的级别。然而,由于KVM/ARM是利用现有的内核为基础,如调度器,在HYP模式下运行KVM/ARM也就意味着Linux内核需要运行在HYP模式中。这样至少有两个问题点。第一,Linux中依赖于底层架构的代码是在内核模式下工作的,并且不能在未进行任何修