免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: kikanjuu

请问完全内存虚拟化处理缺页异常的流程是什么? [复制链接]

论坛徽章:
0
发表于 2008-02-27 09:44 |显示全部楼层
由此保证了当前domain所有顶级页表对应的页面,在SPT中只读。
之后每次捕获#PF进行的客户页表遍历时,Xen总是同时将遍历客户页表对应的机器页面设置为只读,
代码来自guest_walk_tables():
    if ( guest_op && sh_remove_write_access(v, gw->l2mfn, 2, va) != 0 )
        flush_tlb_mask(v->domain->domain_dirty_cpumask);

写保护的是客户页表页对应的影子页表页的机器物理页,而不是客户页表页本身的机器物理页,对吗?
在这里guest_walk_tables()之前,客户页表页对应的影子页表页的机器页尚未被写保护,那么这个导致执行guest_walk_tables()的PF是怎么发生的呢?



通过这种渐进的方式确保了所有客户页表所在页面在SPT中的映射项都是只读的,
之后如果客户操作系统试图修改客户页表会引发#PF,
此时由Xen捕获并模拟其执行,在模拟的同时同步SPT与GPT:
代码来自sh_page_fault()

这里的“PF”是客户操作系统写只读的影子页表页引起的。和前面的进行写保护的PF不是一个,对吗?

[ 本帖最后由 kikanjuu 于 2008-2-27 09:51 编辑 ]

论坛徽章:
0
发表于 2008-02-27 13:48 |显示全部楼层
原帖由 kikanjuu 于 2008-2-27 09:44 发表

写保护的是客户页表页对应的影子页表页的机器物理页,而不是客户页表页本身的机器物理页,对吗?
在这里guest_walk_tables()之前,客户页表页对应的影子页表页的机器页尚未被写保护,那么这个导致执行guest_ ...


VCPU运行在物理CPU时,物理CPU使用SPT进行寻址.
并不存在页面本身被写保护的问题,
比如两个页表项都指向同一个物理页面,
第一个页表项中该物理页面为只读
第二个页表项该物理页面可写,
那么通过第一个线性地址只能进行读操作
通过第二个线性地址可以进行写操作。
对客户操作系统页面的寻址,最终要经过sl1e,
所以只需要将对应的sl1e设为R即可.
int sh_remove_write_accesss(struct vcpu *v, mfn_t gmfn,
                           unsigned int level,
                           unsigned long fault_addr)
{

    /* callbacks与callback_mask都是为hash_foreach()准备的参数 */
    /* Dispatch table for getting per-type functions */
    static hash_callback_t callbacks[SH_type_unused] = {
        NULL, /* none    */

#if CONFIG_PAGING_LEVELS == 2
        SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1,2,2), /* l1_32   */
        SHADOW_INTERNAL_NAME(sh_rm_write_access_from_l1,2,2), /* fl1_32  */
......
#endif
......
    /* Brute-force search of all the shadows, by walking the hash */
    perfc_incr(shadow_writeable_bf);
    /* 靠遍历hash,蛮力搜索所有的shadows*/
    hash_foreach(v, callback_mask, callbacks, gmfn);
......
    return 1;
}



xen将于gmfn对应的所有sl1e中的R/W位置R.

当VCPU的客户操作系统需要修改客户页表时,物理CPU实际上是用SPT进行寻址。
Xen将客户页表所在物理页面在SPT中相应的映射中的R/W位设为R,
那么客户操作系统修改客户页表时, 会引发#PF。

另外一种可能是,
客户操作系统试图修改客户页表,
但客户页表所在页面在SPT中还没有相关映射,在分配shadow时对应的shadow所有映射项为空:
mfn_t shadow_alloc(struct domain *d,  
                    u32 shadow_type,
                    unsigned long backpointer)
{
.....
        p = sh_map_domain_page(shadow_page_to_mfn(sp+i));   
        ASSERT(p != NULL);
        clear_page(p);
        sh_unmap_domain_page(p);
        INIT_LIST_HEAD(&sp[i].list);
        sp[i].type = shadow_type;
        sp[i].pinned = 0;
        sp[i].count = 0;
        sp[i].backpointer = backpointer;
        sp[i].next_shadow = NULL;
        perfc_incr(shadow_alloc_count);
......
}

这是回由于P位的问题引发#PF,
Xen捕获#PF,通过查询客户页表/P2M表的方式完成同步

注意:VCPU使用SPT寻址,而Xen使用的是monitor_table进行寻址.

论坛徽章:
0
发表于 2008-02-27 15:20 |显示全部楼层
非常感谢!辛苦你了。

对客户操作系统页面的寻址,最终要经过sl1e,
所以只需要将对应的sl1e设为R即可.


我想问的是,设置sl1e为R的这次PF是怎么发生的呢?或者说,Xen在什么时候将系统中所有SPT中映射到gmfn对应的smfn的所有sl1e都设为R?

[ 本帖最后由 kikanjuu 于 2008-2-27 15:21 编辑 ]

论坛徽章:
0
发表于 2008-02-27 15:44 |显示全部楼层
原帖由 kikanjuu 于 2008-2-27 15:20 发表
非常感谢!辛苦你了。



我想问的是,设置sl1e为R的这次PF是怎么发生的呢?或者说,Xen在什么时候将系统中所有SPT中映射到gmfn对应的smfn的所有sl1e都设为R?


因为sl1e映射的是客户页表对应的物理页面,所以客户操作系统试图修改客户页表会引发#PF,
对于顶级页表,Xen在客户操作系统更改cr3时,将对应的gmfn在SPT中的sl1e置为R
其余通过每次#PF,在对客户页表进行遍历的时候渐进式的将客户操作系统也表对应的sl1e置为R

论坛徽章:
0
发表于 2008-02-27 16:11 |显示全部楼层
哦,就是说GOS改cr3被截获,其cr3对应的客户页表的l2 mfn在SPT中的pte被设为只读。

当GOS想将l1 gfn挂到l2 gfn上时,由于相应的客户页表的l2 mfn在SPT中的映射先前已为只读,所以发生PF被截获,
同理,当GOS想将非页表gfn挂到l1 gfn上时,由于相应的l1 mfn在SPT中的映射先前已为只读,所以发生PF被截获。是这样吧?

在sh_remove_write_accesss()为什么要将所有SPT中映射到gmfn的pte的读写位置为R,
而不是只将当前cr3对应的GPT对应的SPT中映射到gmfn的pte的读写位置为R?

[ 本帖最后由 kikanjuu 于 2008-2-27 16:27 编辑 ]

论坛徽章:
0
发表于 2008-02-27 19:39 |显示全部楼层
原帖由 kikanjuu 于 2008-2-27 16:11 发表
哦,就是说GOS改cr3被截获,其cr3对应的客户页表的l2 mfn在SPT中的pte被设为只读。

当GOS想将l1 gfn挂到l2 gfn上时,由于相应的客户页表的l2 mfn在SPT中的映射先前已为只读,所以发生PF被截获,
同理,当GO ...


Xen并非对每一个VCPU维护一个与其对应的SPT,而是针对每一个客户页表以及这个客户页表在地址翻译中的层次维护与其对应的一个shadow。
这就是说如果两个VCPU共享某个层次的客户页表,那么其SPT也是共享的。这样可以大大的提升效率。

由于可以使用不同的线性地址访问同一个物理页面,所以在不同的客户页表中可能存在到同一个gmfn的映射,由于Xen要监控对客户页表的写操作做,
所以要将当前gmfn所有的sl1e R/W设为R,以监控各种途径的对客户页表的修改。

论坛徽章:
0
发表于 2008-02-27 20:53 |显示全部楼层
Xen并非对每一个VCPU维护一个与其对应的SPT,而是针对每一个客户页表以及这个客户页表在地址翻译中的层次维护与其对应的一个shadow。

什么是“这个客户页表在地址翻译中的层次”?


由于可以使用不同的线性地址访问同一个物理页面,所以在不同的客户页表中可能存在到同一个gmfn的映射,由于Xen要监控对客户页表的写操作做,

这里的“所以在不同的客户页表中可能存在到同一个gmfn的映射”应该是“所以在不同的影子页表中可能存在到同一个gmfn的映射”吧?

论坛徽章:
0
发表于 2008-02-28 14:02 |显示全部楼层
原帖由 kikanjuu 于 2008-2-27 20:53 发表

什么是“这个客户页表在地址翻译中的层次”?



这里的“所以在不同的客户页表中可能存在到同一个gmfn的映射”应该是“所以在不同的影子页表中可能存在到同一个gmfn的映射”吧?


你说的对,

由于客户页表中可能存在环路映射(如NetBSD),
主要的作用是为客户操作系统修改自身也表提供方便,
那么就是说,
如果客户操作系统利用环路映射访问自己的页表,
对于某个客户页表来说,
在这次访问中,
即可能做为l2,也要做为l1,
Xen为这个客户页表维护两个shadow,
一个是对应于l2,一个对应于l1

Xen本身也使用环路映射维护自己的页表,
利用objdump可以得到
monitor_talbe的线性地址为(0x FE3F800) (32位下)
换算为PTE/PDE为:
[0x3F8][0x3F8][0x000]
也就是说Xen在自身的PDE中有一个映射到其自身的环路映射,
通过这个环路映射
Xen可以轻松的访问自己的页表.

论坛徽章:
0
发表于 2008-02-28 17:10 |显示全部楼层
奉老大旨意,上传此文

Xen硬件虚拟机的内存虚拟化实现.rar

143.26 KB, 下载次数: 451

论坛徽章:
0
发表于 2008-02-28 17:53 |显示全部楼层
真的要谢谢Sirouni和zx_wing!谢谢你们详细的解释和上传的珍贵的资料。能认识国内的熟悉Xen、愿意相互交流的朋友实属不易!
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

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

清除 Cookies - ChinaUnix - Archiver - WAP - TOP