免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 3192 | 回复: 6

[虚拟化] swapper进程修改页表项 vs kvm中guest页表的写保护 [复制链接]

论坛徽章:
4
戌狗
日期:2013-08-15 18:22:43技术图书徽章
日期:2013-08-21 13:48:45巨蟹座
日期:2013-09-26 17:06:39处女座
日期:2013-12-25 11:26:10
发表于 2013-10-10 16:54 |显示全部楼层
切换页表时,原始的实现是invalidate所有的tlb entry。
为了快速切换页表,intel有所谓pcid直说,arm有所谓asid之说,其目的就是所有tlb entry均关联一个页表id。这样切换页表时,就不必invalidate tlb。

问题1) swapper运行时,修改了属于其他地址空间的页表,那么它如何处理属于其他地址空间的tlb entry?


想当然的答案是swapper在修改了属于其他地址空间的页表后,会按照( 页表id + 虚拟地址)的方式,来invalidate属于其他地址空间的tlb entry。
但是,如果这样的话,kernel修改页表的实质变成了:
a) 进程修改自己的页表,映射从有到无,读写权限从高变低的话,会invlpg(自己的页表id + 虚拟地址)
b) 进程修改他人的页表,映射从有到无,读写权限从高变低的话,会invlpg(他人的页表id + 虚拟地址)

问题2)那么,vmm使用shadow页表时,何必要写保护guest的pte页表?

guest修改任何页表,映射从无到有,读写权限从低变高的话,迟早都会由于page fault触发vm exit,进而填充shadow页表项;
guest修改任何页表,映射从有到无,读写权限从高变低的话,必然会由于invlpg(页表id + 虚拟地址)触发vm exit,进而作废shadow页表项;

这就保证了shadow页表是正确的,完全无需写保护guest页表。

我原本以为写保护guest的页表,是怕guest中的swapper进程,修改guest中的其他进程的页表。由于是修改的其他进程的页表,所以guest认为不需要invlpg,导致vmm无法截获这一变化,因此shadow页表永远与guest页表不再同步。为了避免这种现象,只好写保护guest的页表,以截获这一变化。
但现在pcid和asid的出现,导致swapper进程修改其他进程页表后,仍然需要invlpg(页表id + 虚拟地址),那么这个写保护变的毫无必要。

论坛徽章:
2
CU十二周年纪念徽章
日期:2013-10-24 15:41:34处女座
日期:2013-12-27 22:22:41
发表于 2013-10-10 20:29 |显示全部楼层
本帖最后由 tempname2 于 2013-10-10 20:54 编辑

看错了。

有这个技巧,unsync shadow pages

http://events.linuxfoundation.or ... j2011_guangrong.pdf

16页。

论坛徽章:
15
射手座
日期:2014-02-26 13:45:082015年迎新春徽章
日期:2015-03-04 09:54:452015年辞旧岁徽章
日期:2015-03-03 16:54:15羊年新春福章
日期:2015-02-26 08:47:552015年亚洲杯之卡塔尔
日期:2015-02-03 08:33:45射手座
日期:2014-12-31 08:36:51水瓶座
日期:2014-06-04 08:33:52天蝎座
日期:2014-05-14 14:30:41天秤座
日期:2014-04-21 08:37:08处女座
日期:2014-04-18 16:57:05戌狗
日期:2014-04-04 12:21:33技术图书徽章
日期:2014-03-25 09:00:29
发表于 2013-10-11 09:44 |显示全部楼层
有一种情景是 Guest OS 有可能修改了页表项之后立即释放控制权,这时不需要 invlpg 。为了同步缓存中的影子页表,唯一的办法就只有通过写保护来跟踪 Guest 页表的修改了。
相对于仅捕获 invlpg 指令而言,对 Guest 页表进行写保护的策略,更能保证同步的精确。
如下文章应该给出了较清晰的答案,请参考:
http://fleurer-lee.com/2013/05/19/shadow-quick-note.html

回复 1# 塑料袋


   

论坛徽章:
4
戌狗
日期:2013-08-15 18:22:43技术图书徽章
日期:2013-08-21 13:48:45巨蟹座
日期:2013-09-26 17:06:39处女座
日期:2013-12-25 11:26:10
发表于 2013-10-11 13:31 |显示全部楼层
humjb_1983 发表于 2013-10-11 09:44
有一种情景是 Guest OS 有可能修改了页表项之后立即释放控制权,这时不需要 invlpg 。为了同步缓存中的影子 ...


"Guest OS 有可能修改了页表项之后立即释放控制权,这时不需要 invlpg",这个结论的前提是:未开启pcid /asid。

如果未开启pcid /asid,那么tlb中只有当前进程的地址映射;随着进程切换,硬件还会自动invalidate这些映射。这样才可以不需要invlpg。

但如已开启pcid /asid,那么tlb中有N个进程的地址映射,不管Guest OS修改了那个进程的页表,它都必须invlpg啊。

这才是我真正的疑惑。


另外想请教下,kernel现在是否支持x86上的pcid??

我在代码中没看到kernel使用pcid,但是我觉得很难理解。如果没有pcid的支持,x86又支持超线程,那么岂不是两个逻辑核互相切换的时候,都要invalidate tlb???

超线程的本意是为了节省cache miss的时间,但如果切换两个逻辑核,要导致invalidate tlb的话,岂不是得不尝试???

论坛徽章:
4
戌狗
日期:2013-08-15 18:22:43技术图书徽章
日期:2013-08-21 13:48:45巨蟹座
日期:2013-09-26 17:06:39处女座
日期:2013-12-25 11:26:10
发表于 2013-10-11 14:03 |显示全部楼层
塑料袋 发表于 2013-10-11 13:31
  另外想请教下,kernel现在是否支持x86上的pcid??

我在代码中没看到kernel使用pcid,但是我觉得很难理解。如果没有pcid的支持,x86又支持超线程,那么岂不是两个逻辑核互相切换的时候,都要invalidate tlb???

超线程的本意是为了节省cache miss的时间,但如果切换两个逻辑核,要导致invalidate tlb的话,岂不是得不尝试???...


OK,如果hyperthread的两个逻辑核,使用了两个tlb的话,这个就不再是问题。

听人说恰恰是这样。

论坛徽章:
4
戌狗
日期:2013-08-15 18:22:43技术图书徽章
日期:2013-08-21 13:48:45巨蟹座
日期:2013-09-26 17:06:39处女座
日期:2013-12-25 11:26:10
发表于 2013-10-11 16:14 |显示全部楼层
啊哈,I get it

vmm不管guest有无启用pcid,一律认为未启用。

写保护各个guest页表页,只是为了打标记,标记所有页表页,不管是当前进程还是其他进程的页表页中,可能out of sync的页表页。

对于当前进程的页表页,其实不必关注out of sync,因为当前进程必然会invlpg。

对于其他进程的页表页,就要必须关注out of sync,以模拟如下行为:
1) 真正的tlb : 加载cr3时,为保证tlb与页表一致,tlb被清空
2) 模拟的tlb : 加载cr3时,为保证tlb与页表一致,tlb的各out of sync  页被同步

论坛徽章:
15
射手座
日期:2014-02-26 13:45:082015年迎新春徽章
日期:2015-03-04 09:54:452015年辞旧岁徽章
日期:2015-03-03 16:54:15羊年新春福章
日期:2015-02-26 08:47:552015年亚洲杯之卡塔尔
日期:2015-02-03 08:33:45射手座
日期:2014-12-31 08:36:51水瓶座
日期:2014-06-04 08:33:52天蝎座
日期:2014-05-14 14:30:41天秤座
日期:2014-04-21 08:37:08处女座
日期:2014-04-18 16:57:05戌狗
日期:2014-04-04 12:21:33技术图书徽章
日期:2014-03-25 09:00:29
发表于 2013-10-11 16:57 |显示全部楼层
回复 6# 塑料袋
楼主理解得很深刻~,顺便也学习了。
另外,针对你之前提的问题,提点个人的看法,水平有限,望大仙们指教:
1、对于invlpg操作,理论上,在修改了页表后,都应该做这样的操作,但是不能保证所有人(内核和模块)都会这样做,另一方面,invlpg操作还存在延迟问题,在延迟期间可能也会有问题。对相关机制没有做过深入研究,对VMM相关东东了解也不深,个人看法而已~~
2、对于超线程的问题,对于intel处理器,超线程逻辑核会共享data TLB,iTLB视不同的CPU实现不同,总的来说TLB可能是共享的,这种情况下,根据Intel系统编程指南中的描述,每个TLB entry都会有一个ID来标识对应的CPU,TLB刷新时只会刷自己CPU相关的entry,所以,应该没有这样的问题。



   
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP