虚拟化的内存和中断
我个人以为,在一台物理机器上运行虚拟机器,并且虚拟机器还和物理机器公用一套硬件,最复杂的东西只有两个,那就是内存管理和中断管理,对于内存管理,影子叶表已经解决了绝大多数的问题,对于中断问题,还有很多的不同的解决方案有待选择。 以x86系列处理器为例,当中断发生的时候,总是会有intr信号发送到cpu的,如果此时正在运行的是guest os的话既然guest os运行在ring1,那么很显然
我个人以为,在一台物理机器上运行虚拟机器,并且虚拟机器还和物理机器公用一套硬件,最复杂的东西只有两个,那就是内存管理和中断管理,对于内存管理,影子叶表已经解决了绝大多数的问题,对于中断问题,还有很多的不同的解决方案有待选择。
以x86系列处理器为例,当中断发生的时候,总是会有intr信号发送到cpu的,如果此时正在运行的是guest os的话既然guest os运行在ring1,那么很显然vmm会捕获到这个信号,那么既然vmm捕获到了这个信号,那么它肯定有办法将此信号转交于host os的中断处理程序,至于怎么转发,我想这不是问题,因为每一个设计者都会很好的处理这个问题的,有时间的话看看《设计原本》这本书吧!具体的技术细我我们不需要关注,最重要的是我们必须有一种我们自己的风格,这就是设计!,ring0可以捕获到ring1的操作,那么ring0就可以模拟ring1的任何操作。
下面是自我构思的一个vmm处理硬件中断的过程。设起初,机器在guest os中的用户态执行,突然间来了中断:
1.机器进入ring0,由于涉及了ring的切换,ss,esp,cs,eip均进行了切换,从guest os切换到了vmm
2.由于vmm映射了自己的idt,跳转到了vmm的中断处理程序
3.在vmm的中断处理程序中,将中断号记录在了vmm和host os共享的cross page中。
4.在host os的idt中查找中断向量n对应的处理地址,并且设置host os的cs,eip为此处理程序,并且将原始的host os保存的上下文(cs,eip,ss,esp)压入保存的host os的内核堆栈
5.切换回host os,自然跳入host os的中断处理程序
6.中断处理完毕,iret返回之前,决策调度,如需调度,则下列序列执行延迟,再次调度于此时执行,若否,则继续
7.iret返回,由于第四步压入堆栈的上下文,返回host os继续执行,vmx86run返回到host os vmware-vmx的用户空间,以后进入传统的轨道。
8.如再次切换到guest os,那么从2,3处的guest os上下文开始执行
由此可见,中断执行涉及的上下文切换异常消耗巨大,然而,如果不理清这个处理过程,再高效的事情又从何谈起呢?
更多推荐
所有评论(0)