- 论坛徽章:
- 0
|
原帖由 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进行寻址. |
|