首页 > 代码库 > KVm中EPT逆向映射机制分析

KVm中EPT逆向映射机制分析

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 - 1];
};

 

该结构的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 - 1,
                      slot->base_gfn, level) + 1;

        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 = 0;
    /*如果*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 & 1)) {
        rmap_printk("pte_list_add: %p %llx 1->many\n", spte, *spte);
        desc = mmu_alloc_pte_list_desc(vcpu);
        desc->sptes[0] = (u64 *)*pte_list;
        desc->sptes[1] = spte;
        *pte_list = (unsigned long)desc | 1;
        ++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-1] && desc->more) {
            desc = desc->more;
            count += PTE_LIST_EXT;
        }
        /*如果已经满了,就再次扩展more*/
        if (desc->sptes[PTE_LIST_EXT-1]) {
            desc->more = mmu_alloc_pte_list_desc(vcpu);
            desc = desc->more;
        }
        /*找到首个为空的项,进行填充*/
        for (i = 0; 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源码

 

KVm中EPT逆向映射机制分析