2017-05-30
前几天简要分析了linux remap机制,虽然还有些许瑕疵,但总算大致分析的比较清楚。今天分析下EPT下的逆向映射机制。EPT具体的工作流程可参考前面博文,本文对于EPT以及其工作流程不做过多介绍,重点介绍逆向映射机制。其实逆向映射机制在最主要的作用就是映射的逆向,说了等于白说,但也不无道理。linux下根据虚拟地址经过页表转换得到物理地址。怎么根据物理地址得到对应的虚拟地址呢?这里便用到了逆向映射。逆向映射有什么用呢?最重要的,在页面换出时,由于物理内存的管理由一套相对独立的机制在负责,根据物理页面的活跃程度,对物理页面进行换出,而此时就需要更新引用了此页面的页表了,否则造成不同步而出错。如果获取对应的物理页面对应的pte的地址呢?内核的做法是先通过逆向映射得到虚拟地址,根据虚拟地址遍历页表得到pte地址。
在KVM中,逆向映射机制的作用是类似的,但是完成的却不是从HPA到对应的EPT页表项的定位,而是从gfn到对应的页表项的定位。理论上讲根据gfn一步步遍历EPT也未尝不可,但是效率较低;况且在EPT所维护的页面不同于host的页表,理论上讲是虚拟机之间是禁止主动的共享内存的,为了提高效率,就有了当前的逆向映射机制。
我们都知道虚拟机的物理内存由多个slot构成,每个slot都是一个kvm_memory_slot结构,表示虚拟机物理内存的一段空间,为了说明问题,不妨先看下该结构:
struct kvm_memory_slot {
gfn_t base_gfn;
unsigned long npages;
/*一个slot有许多客户机虚拟页面组成,通过dirty_bitmap标记每一个页是否可用,一个页面对应一个位*/
unsigned long *dirty_bitmap;
struct kvm_arch_memory_slot arch;
unsigned long userspace_addr;//对应的HVA 地址
u32 flags;
short id;
};
slot本质是qemu进程用户空间的hva,紧急你是qemu进程的虚拟地址空间,并没有对应物理地址,各个字段的意义不言自明了。其中有一个kvm_arch_memory_slot结构,我们重点描述。
struct kvm_arch_memory_slot {
unsigned long *rmap[KVM_NR_PAGE_SIZES];
struct kvm_lpage_info *lpage_info[KVM_NR_PAGE_SIZES - ];
};
该结构的rmap字段是指针数组,每种页面大小对应一项,截止3.10.1版本,KVM的大页面仅仅支持2M而并没有考虑1G的页面,普通的页面就是4KB了。所以默认状态下,提到大页面就是指的2M的页面。结合上面的kvm_memory_slot结构可以发现,kvm_arch_memory_slot其实是kvm_memory_slot的一个内嵌结构,所以每个slot都关联一个kvm_arch_memory_slot,也就有一个rmap数组。其实在虚拟机中,qemu为虚拟机分配的页面主要是大页面,但是这里为了方面,按照4KB的普通页面做介绍。
初始化阶段
在qemu为虚拟机注册各个slot的时候,在KVM中会初始化逆向映射的相关内存区。__kvm_set_memory_region-->kvm_arch_create_memslot
在该函数中,用一个for循环为每种页面类型的rmap分配空间,具体分配代码如下
lpages = gfn_to_index(slot->base_gfn + npages - ,
slot->base_gfn, level) + ; slot->arch.rmap[i] =
kvm_kvzalloc(lpages * sizeof(*slot->arch.rmap[i]));
if (!slot->arch.rmap[i])
goto out_free;
gfn_to_index把一个gfn转化成该gfn在整个slot中的索引,而这里获取的其实就是整个slot包含的不同level的页面数。然后为slot->arch.rmap[i]分配内存,每个页面对应一个unsigned Long.
建立阶段
建立阶段自然是在填充EPT的时候了,在KVM中维护EPT的核心函数是tdp_page_fault函数。该函数的处理在之前的文章中也有介绍,在函数尾部会调用rmap_add函数建立逆向映射
static int rmap_add(struct kvm_vcpu *vcpu, u64 *spte, gfn_t gfn)
{
struct kvm_mmu_page *sp;
unsigned long *rmapp; sp = page_header(__pa(spte));
kvm_mmu_page_set_gfn(sp, spte - sp->spt, gfn);
rmapp = gfn_to_rmap(vcpu->kvm, gfn, sp->role.level);
return pte_list_add(vcpu, spte, rmapp);
}
page_header是一个内联函数,主要目的在于获取kvm_mmu_page,一个该结构描述一个层级的页表,地址保存在page结构的private字段,然后调用kvm_mmu_page_set_gfn,对kvm_mmu_page进行设置。这不是重点,接着就获取了gfn对应的rmap的地址,重点看下
static unsigned long *gfn_to_rmap(struct kvm *kvm, gfn_t gfn, int level)
{
struct kvm_memory_slot *slot; slot = gfn_to_memslot(kvm, gfn);
return __gfn_to_rmap(gfn, level, slot);
}
首先转化成到对应的slot,然后调用了__gfn_to_rmap
static unsigned long *__gfn_to_rmap(gfn_t gfn, int level,
struct kvm_memory_slot *slot)
{
unsigned long idx;
/*gfn在slot中的index*/
idx = gfn_to_index(gfn, slot->base_gfn, level);
/*rmap是一个指针数组,每个项记录对应层级的gfn对应的逆向映射,index就是下标*/
return &slot->arch.rmap[level - PT_PAGE_TABLE_LEVEL][idx];
}
额。。。到这里就很明确了,我们再次看到了gfn_to_index函数,这里就根据指定的gfn转化成索引,同时也是在rmap数组的下标,然后就返回对应的表项的地址,没啥好说的吧……现在地址已经获取到了,还等什么呢?设置吧,调用pte_list_add函数,该函数也值得一说
static int pte_list_add(struct kvm_vcpu *vcpu, u64 *spte,
unsigned long *pte_list)
{
struct pte_list_desc *desc;
int i, count = ;
/*如果*pte_list为空,直接设置逆向映射即可 */
if (!*pte_list) {
rmap_printk("pte_list_add: %p %llx 0->1\n", spte, *spte);
*pte_list = (unsigned long)spte;
} else if (!(*pte_list & )) {
rmap_printk("pte_list_add: %p %llx 1->many\n", spte, *spte);
desc = mmu_alloc_pte_list_desc(vcpu);
desc->sptes[] = (u64 *)*pte_list;
desc->sptes[] = spte;
*pte_list = (unsigned long)desc | ;
++count;
} else {
rmap_printk("pte_list_add: %p %llx many->many\n", spte, *spte);
desc = (struct pte_list_desc *)(*pte_list & ~1ul);
while (desc->sptes[PTE_LIST_EXT-] && desc->more) {
desc = desc->more;
count += PTE_LIST_EXT;
}
/*如果已经满了,就再次扩展more*/
if (desc->sptes[PTE_LIST_EXT-]) {
desc->more = mmu_alloc_pte_list_desc(vcpu);
desc = desc->more;
}
/*找到首个为空的项,进行填充*/
for (i = ; desc->sptes[i]; ++i)
++count;
desc->sptes[i] = spte;
}
return count;
}
先走下函数流程,我们已经传递进来gfn对应的rmap的地址,就是pte_list,接下来主要分为三部分;if……else if ……else
首先,如果*ptelist为空,则直接*pte_list = (unsigned long)spte;直接把rmap地址的内容设置成表项地址,到这里为止,so easy……但是这并不能解决所有问题,说到这里看下函数前面的注释吧
/*
* Pte mapping structures:
*
* If pte_list bit zero is zero, then pte_list point to the spte.
*
* If pte_list bit zero is one, (then pte_list & ~1) points to a struct
* pte_list_desc containing more mappings.
*
* Returns the number of pte entries before the spte was added or zero if
* the spte was not added.
*
*/
根据注释判断,pte_list即我们之前的到的rmap最低一位表明这直接指向一个spte还是pte_list_desc,后者用作扩展remap.那么到了else if这里,如果*pte_list不为空且也并没有指向一个pte_list_desc,那么就坏了,根据gfn定位到了 这个remap项,但是人家已经在用了,怎么办?解决方案就是通过pte_list_desc扩展下,但是最后要表明这是一个pte_list_desc,所以要吧最后一位置1,然后设置进*pte_list。还是介绍下该结构
struct pte_list_desc {
u64 *sptes[PTE_LIST_EXT];
struct pte_list_desc *more;
};
结构比较简单,自身携带一个PTE_LIST_EXT大小的指针数组,PTE_LIST_EXT为3,也就是扩展一下可以增加2个表项,数量不多,所以如果还不够,就通过下面的more扩展。more又指向一个pte_list_desc。好了,接下看我们的else
如果前两种情况都不对,这就是remap项不为空,且已经指向一个pte_list_desc,同样的道理我们需要获取该结构,找到一个能用的地方啊。如何找?
如果desc->sptes已经满了,且more不为空,则递归的遍历more,while循环出来,就有两种情况
1、sptes有剩余
2、more为空
此时进行判断,如果sptes没满,直接找到一个空闲的项,进行填充;否则,申请一个pte_list_desc,通过more进行扩展,然后在寻找一个空闲的。
PS:上面是函数的大致流程,可是为何需要扩展呢?之前有提到,初始化的时候为每个页面都分配了remap空间,如果qemu进程为虚拟机分配的都是4KB的页面,那么每个页面均会对应一个位置,这样仅仅if哪里就可以了,不需要扩展。但是qemu为虚拟机分配的一般是比较大的页面,就是2M的,但是虚拟机自己分配的很可能是4KB的,这样,初始化的时候为2M的页为单位分配rmap空间,就不能保证所有的小页面都对应一个唯一的remap地址,这样就用到了扩展。
以马内利
参考:kvm 3.10.1源码