设为首页 收藏本站
查看: 1427|回复: 0

[经验分享] 3.1 Qemu KVM内存虚拟化原理

[复制链接]

尚未签到

发表于 2015-10-10 12:44:30 | 显示全部楼层 |阅读模式
  
  
  内存地址分为虚拟地址和物理地址, 所以在虚拟化的环境下内存分为Guest Os virtual mem(GVA) , Host virtual mem((HVA), Guest OSphysical mem(GPA), Host physical mem(HPA)四类。
  
  Guest OS 负责管理GVA,和GPA;  而Host 端分为Qemu 用户空间和KVM 内核空间。Qemu负责Guest OS物理内存的大小和该物理内存对应到Host机上的虚拟地址(因为qemu用户态不能直接管理host 物理内存)。 KVM内核空间则维护GVA对应HVA到HPA的转换。 所以整个内存虚拟化的过程也就是GVA到HPA的转换。
          KVM 提供了两种实现方式来进行客户机虚拟地址到宿主机物理地址之间的直接转换。其一是基于纯软件的实现方式,也即通过影子页表 (Shadow Page Table) 来实现GVA到HPA。其二是基于硬件对虚拟化EPT来实现两者之间的转换,维护GPA到HPA.
  
3.1.1 基于影子页表的内存虚拟化

由于宿主机 MMU 不能直接装载客户机的页表来进行内存访问,所以当客户机访问宿主机物理内存时,需要经过多次地址转换。也即首先根据客户机页表(通过CR3寄存器操作的监控捕获客户机页表操作)把GVA转传成GPA,然后再通过GPA到HVA之间的映射转换成宿主机虚拟地址,最后再根据宿主机页表把GVA转换成GPA。而通过影子页表,则可以实现客户机虚拟地址到宿主机物理地址的直接转换


影子页表简化了地址转换过程,实现了客户机虚拟地址空间到宿主机物理地址空间的直接映射。但是由于客户机中每个进程都有自己的虚拟地址空间,所以 KVM 需要为客户机中的每个进程页表都要维护一套相应的影子页表。在客户机访问内存时,真正被装入宿主机 MMU 的是客户机当前页表所对应的影子页表,从而实现了从客户机虚拟地址到宿主机物理地址的直接转换。而且,在 TLB 和 CPU 缓存上缓存的是来自影子页表中客户机虚拟地址和宿主机物理地址之间的映射,也因此提高了缓存的效率。

在影子页表中,每个页表项指向的都是宿主机的物理地址。这些表项是随着客户机操作系统对客户机页表的修改而相应地建立的。客户机中的每一个页表项都有一个影子页表项与之相对应。如下图 3 所示:

图 1 客户机页表和影子页表


为了快速 DSC0000.jpg 检索客户机页表所对应的的影子页表,KVM 为每个客户机都维护了一个哈希表,影子页表和客户机页表通过此哈希表进行映射。对于每一个客户机来说,客户机的页目录和页表都有唯一的客户机物理地址,通过页目录 / 页表的客户机物理地址就可以在哈希链表中快速地找到对应的影子页目录 / 页表。在检索哈希表时,KVM 把客户机页目录 / 页表的客户机物理地址低 10 位作为键值进行索引,根据其键值定位到对应的链表,然后遍历此链表找到对应的影子页目录/ 页表。当然,如果不能发现对应的影子页目录 / 页表,说明 KVM 还没有为其建立,于是 KVM 就为其分配新的物理页并加入此链表,从而建立起客户机页目录 / 页表和对应的影子页目录 / 页表之间的映射。当客户机切换进程时,客户机操作系统会把待切换进程的页表基址载入 CR3,而 KVM 将会截获这一特权指令,进行新的处理,也即在哈希表中找到与此页表基址对应的影子页表基址,载入客户机 CR3,使客户机在恢复运行时 CR3 实际指向的是新切换进程对应的影子页表。

影子页表异常处理机制

在通过影子页表进行寻址的过程中,有两种原因会引起影子页表的缺页异常,一种是由客户机本身所引起的缺页异常,具体来说就是客户机所访问的客户机页表项存在位 (Present Bit) 为 0,或者写一个只读的客户机物理页,再者所访问的客户机虚拟地址无效等。另一种异常是由客户机页表和影子页表不一致引起的异常。

当缺页异常发生时,KVM 首先截获该异常,然后对发生异常的客户机虚拟地址在客户机页表中所对应页表项的访问权限进行检查,并根据引起异常的错误码,确定出此异常的原因,进行相应的处理。如果该异常是由客户机本身引起的,KVM 则直接把该异常交由客户机的缺页异常处理机制来进行处理。如果该异常是由客户机页表和影子页表不一致引起的,KVM 则根据客户机页表同步影子页表。为此,KVM 要建立起相应的影子页表数据结构,填充宿主机物理地址到影子页表的页表项,还要根据客户机页表项的访问权限修改影子页表对应页表项的访问权限。

由于影子页表可被载入物理 MMU 为客户机直接寻址使用, 所以客户机的大多数内存访问都可以在没有 KVM 介入的情况下正常执行,没有额外的地址转换开销,也就大大提高了客户机运行的效率。但是影子页表的引入也意味着 KVM 需要为每个客户机的每个进程的页表都要维护一套相应的影子页表,这会带来较大内存上的额外开销,此外,客户机页表和和影子页表的同步也比较复杂。因此,Intel 的 EPT(Extent Page Table) 技术和 AMD 的 NPT(Nest Page Table)技术都对内存虚拟化提供了硬件支持。这两种技术原理类似,都是在硬件层面上实现客户机虚拟地址到宿主机物理地址之间的转换。

3.1.2 基于EPT的内存虚拟化

EPT 技术在原有客户机页表对客户机虚拟地址到客户机物理地址映射的基础上,又引入了 EPT页表来实现客户机物理地址到宿主机物理地址的另一次映射,这两次地址映射都是由硬件自动完成。客户机运行时,客户机页表被载入 CR3,而 EPT 页表被载入专门的EPT 页表指针寄存器 EPTP。EPT 页表对地址的映射机理与客户机页表对地址的映射机理相同,下图4 出示了一个页面大小为 4K 的映射过程:

图 2.EPT 页表转换

DSC0001.jpg

在客户机物理地址到宿主机物理地址转换的过程中,由于缺页、写权限不足等原因也会导致客户机退出,产生 EPT异常。对于 EPT 缺页异常,KVM首先根据引起异常的客户机物理地址,映射到对应的宿主机虚拟地址,然后为此虚拟地址分配新的物理页,最后 KVM 再更新 EPT 页表,建立起引起异常的客户机物理地址到宿主机物理地址之间的映射。对 EPT 写权限引起的异常,KVM 则通过更新相应的 EPT 页表来解决。

由此可以看出,EPT 页表相对于前述的影子页表,其实现方式大大简化。而且,由于客户机内部的缺页异常也不会致使客户机退出,因此提高了客户机运行的性能。此外,KVM 只需为每个客户机维护一套 EPT 页表,也大大减少了内存的额外开销。


  
         版权声明:本文为博主原创文章,未经博主允许不得转载。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-125097-1-1.html 上篇帖子: KVM虚拟化管理 下篇帖子: centos5.6下kvm的安装/桥接设置/虚拟机创建及运行
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表