KVm中EPT逆向映射机制分析

Posted 2020-09-20 太初有道，道与神同在，道就是神……

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源码