QEMU热迁移机制

1，虚拟机脏页跟踪有两种实现方式，一是通过修改页表属性，使其成为写保护，这样每次guest访问内存都会走page-fault流程，可以记录下虚拟机访问了哪些脏页，但是这种机制效率低下，intel cpu硬件上支持了自动记录虚拟机访问了哪些gfn到内存里，这个机制叫PML（Page-Modification Log）．

2，PML需要qemu侧主动开启，这以KVM_MEM_LOG_DIRTY_PAGES这个标志来决定，它是qemu和kvm都能识别的一个标志，最终的开启动作是kvm来做，qemu guest通过ioctl接口（kvm_vm_ioctl，cmd: KVM_SET_USER_MEMORY__REGION）去调用．

3，guest侧开启PML的请求来到kvm后，会往vcpu的requests上挂入KVM_REQ_UPDATE_CPU_DIRTY_LOGGING请求，也就是说当时并没有立即设置相应的PML enable比特位．

4，等到下一次通过vcpu_enter_guest进入虚拟机时，就会处理挂在这上面的KVM_REQ_UPDATE_CPU_DIRTY_LOGGING请求，主要就是通过secondary_exec_controls_setbit来设置Secondary Processor-Based VM-Execution Controls的第17个bit位．

5，现代intel cpu一般都是支持PML的，所以vcpu创建初始化时，会通过alloc_page分配一个页面并将虚拟地址给到vmx->pml_pg，同时将这页的物理地址填到vmcs的PML_ADDRESS，物理上还有一个PML index的概念，指示某次guest访问gfn时，应将这个gfn填到这页的哪个位置．一页4KB大，每个访问条目信息占用8字节，64比特，所以共计可以有512个条目．

6，当PML页面被写满或者虚拟机因为其它原因退出时，在vm-exit的流程里，都会走vmx_flush_pml_buffer来将PML页面里的脏页信息vcpu->dirty_ring环形buffer里（较早版本的qemu不支持dirty_ring，但dirty_ring效率更高，主要基于这种方式分析），这样PML页面又可以被guest循环利用记录其它的guest对gfn的访问了．

7，一个脏页信息条目由结构体kvm_dirty_gfn表示，在同步到vcpu->dirty_ring时，会通过kvm_dirty_gfn_set_dirtied接口置上kvm_dirty_gfn.flags的KVM_DIRTY_GFN_F_DIRTY的位，表示现在这个条目被虚拟机访问过，需要qemu里热迁移相关的代码将其消耗发送给dst端，这里就可以看到一个生产者－消费者模型，kvm是生产者，而热迁移代码是消费者．

8，一旦热迁移代码将entry记录的页面发送给dst端后，就会通过dirty_gfn_set_collected将对应kvm_dirty_gfn.flags置上KVM_DIRTY_GFN_F_RESET，表示我热迁移代码作为消费者已经消费了脏页信息，现在通过kvm_vm_ioctl接口发送KVM_RESET_DIRTY_RINGS命令．

9，一旦kvm侧接受到KVM_RESET_DIRTY_RINGS的命令，检查vcpu->ring->dirty_gfns里所有的gfn，只要其kvm_dirty_gfn.flags为KVM_DIRTY_GFN_F_RESET时，就可以调用kvm_dirty_gfn_set_invalid将flags设置为0，表示前次对这个脏页的写已经全部处理完毕，未来再有guest访问这个gfn时，可以再次记录下．注意，原来为脏，没有及时发送对应页面数据又写了这个gfn对应的页面，这没什么问题，脏后脏是最新的信息，只要没漏就行．这些kvm_dirty_gfn:flags的状态转换实际上构成了一个简单的状态机．

10，dirty ring的方式就是避免了内核态和用户态的拷贝，这是怎么做到的呢？首先用户态在cpu->kvm_fd上调用mmap系统调用，将这个文件PAGE_SIZE * KVM_DIRTY_LOG_PAGE_OFFSET处映射到内核里（kvm）里的vcpu->dirty_ring，映射出来的地址给到用户态（qemu guest）CPUState:kvm_dirty_gfns，这样最终的效果就是，热迁移代码读取CPUState:kvm_dirty_gfns就是直接读取的内核里的脏页信息．

11，上面的＂映射＂依旧说的比较笼统，具体是怎么做的呢？对cpu->kvm_fd调用mmap时，最后会来到该文件对应的kvm_vcpu_mmap回调钩子来，里面就是初始化了PAGE*KVM_DIRTY_LOG_PAGE_OFFSET开始处的这个vma的vm_ops为kvm_vcpu_vm_ops，这个ops就是将来用户态进程访问CPUState:kvm_dirty_gfns时，查找的vma会调用的vma回调钩子集合，里面有自定义的缺页处理函数kvm_vcpu_fault，一旦用户态因为额访问CPUState:kvm_dirty_gfns触发缺页来到自定义的kvm_vcpu_fault缺页修复函数，就会将内核侧（kvm）里vcpu->dirty_ring所在的页面给到vm_fault:page，然后mm的公共流程里就会拿着这个page完成用户态进程对应CPUState:kvm_dirty_gfns虚拟地址的页表，这样下次再访问时，就可以访问到脏页所在的页面了．这种机制最后所造成的一个情况就是，用户态和内核态各有一个虚拟地址映射到同一个物理页面，这个页面最开始来自内核态分配，以实现共享避免内核态/用户态拷贝．

12，从内核里拿到的脏页信息在qemu里也是有流转过程的，首先是CPUState:kvm_dirty_gfns->KVMSlot:dirty_bmap，然后又到了全局的ram_list.dirty_memory里，最后又拆分到每个RAMBlock:bmap里，最终热迁移代码（函数migration_bitmap_find_dirty）其实直接看的是RAMBlock:bmap里的信息来决定发送脏页．

相比于脏信息的流转以及状态记录，热迁移本身的流程是简单直接的．

1，所有需要热迁移的模块（除了最重要的内存模块，还有其它模块也可能需要热迁移，比如block），自行通过register_savevm_live函数注册SaveStateEntry到全局savevm_state量里．

2，SaveStateEntry里最重要的成员就是SaveVMHandlers，这里面都是迁移各个阶段需要调用的回调函数，比如对于ram模块就是savevm_ram_handlers，在第一阶段需要调用的就是save_setup（ram模块就是ram_save_setup）进行发送前的准备，比如分配bmap脏页信息图，第二阶段要调用的就是save_live_iterate（ram_save_iterate）进行迭代发送，也包括了dst端需要运行的还原函数（ram_load）．

3，虚拟机热迁移开始时，虚拟机并不会立即停止，而是边运行产生脏页，边发送，这也是催生复杂的脏页跟踪机制的原因．由此划分了迭代发送和最后一阶段的划分点，那就是剩下待发送的内存小于一轮能发送的阀值时，就可以停机src端的虚拟机了，进入第三阶段最后一轮发送．

4，如果虚拟机产生脏页的速率bytes_dirty_period > bytes_dirty_threshold时，可以通过mig_throttle_guest_down函数让vcpu线程睡眠，降低其运行频率，这样自然产生脏页的速率也就降低了．

Intel SDM3 27.2.6对PML有较为详细的介绍，这里简单总结下，PML可以开出一页的内存，每当虚拟机访问GPA时，最重要的信息GPA虚拟机物理地址就会作为一个entry放入这一页内存里，一页4KB的空间，共计512个entry．这一页的物理内存地址可以放入VMCS的PML Address域里，另外还有一个PML index域，用来指示现在将访问entry放入哪个位置．

qemu侧开启脏页记录的一个路径可以是（逐步向下增长调用路径上的函数）：

hmp_migrate->qmp_migrate

ERST

    {
        .name       = "migrate",
        .args_type  = "detach:-d,blk:-b,inc:-i,resume:-r,uri:s",
        .params     = "[-d] [-b] [-i] [-r] uri",
        .help       = "migrate to URI (using -d to not wait for completion)"
		      "\n\t\t\t -b for migration without shared storage with"
		      " full copy of disk\n\t\t\t -i for migration without "
		      "shared storage with incremental copy of disk "
		      "(base image shared between src and destination)"
                      "\n\t\t\t -r to resume a paused migration",
        .cmd        = hmp_migrate,
    },


SRST
``migrate [-d] [-b] [-i]`` *uri*
  Migrate to *uri* (using -d to not wait for completion).

  ``-b``
    for migration with full copy of disk
  ``-i``
    for migration with incremental copy of disk (base image is shared)

在qmp_migrate里依据不同uri接口可以调用不同的函数，比如tcp，unix以及vsock都走socket_start_outgoing_migration：

socket_start_outgoing_migration->socket_start_outgoing_migration_internal

在socket_start_outgoing_migration_internal函数里以socket_outgoing_migration作为callback调用qio_channel_socket_connect_async：

qio_channel_socket_connect_async(sioc,
                                 saddr,
                                 socket_outgoing_migration,
                                 data,
                                 socket_connect_data_free,
                                 NULL);

qio_channel_socket_connect_async函数里将socket_outgoing_migration作为callback参数调用qio_task_new构造一个QIOTask：

QIOTask *task = qio_task_new(
    OBJECT(ioc), callback, opaque, destroy);
SocketAddress *addrCopy;

QIOTask *qio_task_new(Object *source,
                      QIOTaskFunc func,
                      gpointer opaque,
                      GDestroyNotify destroy)
{
    QIOTask *task;
    ...
    task->func = func;
    ...
    return task;
}

这里可以看到，socket_outgoing_migration给到了QIOTask.func成员，那么为什么叫IO呢？可以理解虚拟机迁移，其实也就是将当前节点的内存发送到另外的节点，可以理解成IO操作．

然后qio_channel_socket_connect_async调用qio_task_run_in_thread函数，构造出的task作为第一个参数：

qio_task_run_in_thread(task,
                       qio_channel_socket_connect_worker,
                       addrCopy,
                       (GDestroyNotify)qapi_free_SocketAddress,
                       context);

最终会运行到开始提到的回调函数socket_outgoing_migration，该函数向下又有调用：

socket_outgoing_migration->migration_channel_connect->migrate_fd_connect

在migrate_fd_connect函数里，会创建一个名为live_migration的线程：

qemu_thread_create(&s->thread, "live_migration",
        migration_thread, s, QEMU_THREAD_JOINABLE);

该live_migration线程的工作函数为migration_thread，它向下又有调用链：

migration_thread->qemu_savevm_state_setup->save_setup(ram_save_setup)->ram_init_all->ram_init_bitmaps

在ram_init_bitmaps里以GLOBAL_DIRTY_MIGRATION这个标志（原因）启动脏页记录：

memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION);

这个标志其意思就是现在因为迁移要开启了，所以哪些是脏页要记录下来，后面需要迁移这些脏页．除了开始迁移需要记录脏页，还有一个原因也可以开启脏页：

/* Possible bits for global_dirty_log_{start|stop} */

/* Dirty tracking enabled because migration is running */
#define GLOBAL_DIRTY_MIGRATION  (1U << 0)

/* Dirty tracking enabled because measuring dirty rate */
#define GLOBAL_DIRTY_DIRTY_RATE (1U << 1)

#define GLOBAL_DIRTY_MASK  (0x3)

memory_global_dirty_log_start函数里先把传进来的GLOBAL_DIRTY_MIGRATION和global_dirty_tracking相或又给到global_dirty_tracking，这样global_dirty_tracking就有一个新的比特位第bit 0位被设置了，其肯定不为0：

global_dirty_tracking |= flags;

然后memory_global_dirty_log_start继续向下调：

memory_region_transaction_commit->flatviews_reset->generate_memory_topology->render_memory_region

在render_memory_region函数里有：

...
FlatRange fr;
...
fr.dirty_log_mask = memory_region_get_dirty_log_mask(mr);

而memory_region_get_dirty_log_mask如下：

uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr)
{
    uint8_t mask = mr->dirty_log_mask;
    RAMBlock *rb = mr->ram_block;

    if (global_dirty_tracking && ((rb && qemu_ram_is_migratable(rb)) ||
                             memory_region_is_iommu(mr))) {
        mask |= (1 << DIRTY_MEMORY_MIGRATION);
    }

    if (tcg_enabled() && rb) {
        /* TCG only cares about dirty memory logging for RAM, not IOMMU.  */
        mask |= (1 << DIRTY_MEMORY_CODE);
    }
    return mask;
}

这里最主要的条件其实就是global_dirty_tracking，前面看到了global_dirty_tracking第0位被设置了，其肯定是有值的，所以返回的mask其第DIRTY_MEMORY_MIGRATION个比特位也就被设置了（就是bit 2）．memory_region_transaction_commit完成对flatviews_reset的调用后（就是设置新的FlatRange:dirty_log_mask）又调用address_space_set_flatview：

memory_region_transaction_commit->address_space_set_flatview->address_space_update_topology_pass

在address_space_update_topology_pass里就可以看到利用FlatRange:dirty_log_mask作为条件判断是否开启脏页记录了：

static void address_space_update_topology_pass(AddressSpace *as,
                                               const FlatView *old_view,
                                               const FlatView *new_view,
                                               bool adding)
{
    ...
    FlatRange *frold, *frnew;
    ...
            if (adding) {
                MEMORY_LISTENER_UPDATE_REGION(frnew, as, Forward, region_nop);
                if (frnew->dirty_log_mask & ~frold->dirty_log_mask) {
                    MEMORY_LISTENER_UPDATE_REGION(frnew, as, Forward, log_start,
                                                  frold->dirty_log_mask,
                                                  frnew->dirty_log_mask);
                }
                if (frold->dirty_log_mask & ~frnew->dirty_log_mask) {
                    MEMORY_LISTENER_UPDATE_REGION(frnew, as, Reverse, log_stop,
                                                  frold->dirty_log_mask,
                                                  frnew->dirty_log_mask);
                }
    
}

条件frnew->dirty_log_mask & ~frold->dirty_log_mask就是说原来旧的FlatRange:dirty_log_mask没有设置的而新的FlatRange:dirty_log_mask有设置的话，就调用MEMORY_LISTENER_UPDATE_REGION进行更新，可以看到调用它的第四个参数是log_start，而MEMORY_LISTENER_UPDATE_REGION的实现如下：

#define MEMORY_LISTENER_UPDATE_REGION(fr, as, dir, callback, _args...)  \
    do {                                                                \
        MemoryRegionSection mrs = section_from_flat_range(fr,           \
                address_space_to_flatview(as));                         \
        MEMORY_LISTENER_CALL(as, callback, dir, &mrs, ##_args);         \
    } while(0)

在MEMORY_LISTENER_CALL里会调用log_start这个函数了：

_listener->_callback(_listener, _section, ##_args);

对于kvm memory listener来说，这个log_start函数就是kvm_log_start：

kml->listener.log_start = kvm_log_start;

关于其初始化的流程，本文就不赘述了． kvm_log_start有如下调用链：

kvm_log_start->kvm_section_update_flags->kvm_slot_update_flags

kvm_slot_update_flags函数定义如下：

static int kvm_slot_update_flags(KVMMemoryListener *kml, KVMSlot *mem,
                                 MemoryRegion *mr)
{
    mem->flags = kvm_mem_flags(mr);

    /* If nothing changed effectively, no need to issue ioctl */
    if (mem->flags == mem->old_flags) {
        return 0;
    }

    kvm_slot_init_dirty_bitmap(mem);
    return kvm_set_user_memory_region(kml, mem, false);
}

先是调用了kvm_mem_flags，然后调用kvm_set_user_memory_region．先看kvm_mem_flags：

static int kvm_mem_flags(MemoryRegion *mr)
{
    bool readonly = mr->readonly || memory_region_is_romd(mr);
    int flags = 0;

    if (memory_region_get_dirty_log_mask(mr) != 0) {
        flags |= KVM_MEM_LOG_DIRTY_PAGES;
    }
    if (readonly && kvm_readonly_mem_allowed) {
        flags |= KVM_MEM_READONLY;
    }
    return flags;
}

这里重点关注给flags或上了KVM_MEM_LOG_DIRTY_PAGES，而这个标志内核里的kvm模块能够识别，并用来开启硬件PML，这个流程在下节＂kvm侧开启脏页记录＂会详细描述．注意这里判断是否要给flags或上KVM_MEM_LOG_DIRTY_PAGES这个标志，采用了函数memory_region_get_dirty_log_mask的返回值进行判断，前面分析过，只要global_dirty_tracking有值，其返回值非0，这样kvm_mem_flags返回的flags肯定就置上了KVM_MEM_LOG_DIRTY_PAGES．

kvm_slot_update_flags随后调用了kvm_set_user_memory_region，在后者函数里有代码：

static int kvm_set_user_memory_region(KVMMemoryListener *kml, KVMSlot *slot, bool new)
{
    ...
    struct kvm_userspace_memory_region mem;
    mem.flags = slot->flags;
    ...
        ret = kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, &mem);
    ...
}

slot->flags是带有KVM_MEM_LOG_DIRTY_PAGES的，这里又给到了kvm_userspace_memory_region:flags，因为内核kvm和qemu都可以识别kvm_userspace_memory_region这个结构体，显而易见，这个mem（kvm_userspace_memory_region）就要通过ioctl系统调用带到内核态了． 从这里向下就到内核了，以KVM_SET_USER_MEMORY_REGION命令进入ioctl，后续kvm的流程留到下节．

当kvm_vm_ioctl来到内核时，kvm里有个同名函数会处理这个ioctl请求：

static long kvm_vm_ioctl(struct file *filp,
			   unsigned int ioctl, unsigned long arg)
{
    ...
	case KVM_SET_USER_MEMORY_REGION: {
		struct kvm_userspace_memory_region kvm_userspace_mem;

		r = -EFAULT;
		if (copy_from_user(&kvm_userspace_mem, argp,
						sizeof(kvm_userspace_mem)))
			goto out;

		r = kvm_vm_ioctl_set_memory_region(kvm, &kvm_userspace_mem);
		break;
	}
    ...
}

可以看到这个case就是qemu调用ioctl的命令编号：KVM_SET_USER_MEMORY_REGION．同时可以看到，用户态传来的kvm_userspace_memory_region通过copy_from_user拷贝了内核态里的kvm_userspace_mem，其flags带有KVM_MEM_LOG_DIRTY_PAGES．

从kvm_vm_ioctl_set_memory_region向下有如下调用链：

kvm_vm_ioctl_set_memory_region->kvm_set_memory_region->__kvm_set_memory_region

在__kvm_set_memory_region里，又引入了kvm_memory_slot概念：

int __kvm_set_memory_region(struct kvm *kvm,
			    const struct kvm_userspace_memory_region *mem)
{
	struct kvm_memory_slot old, new;
	...
	new.flags = mem->flags;
}

在这里可以看到，带有KVM_MEM_LOG_DIRTY_PAGES标志的flags又被转给了kvm_memory_slot:flags．从__kvm_set_memory_region继续往下：

__kvm_set_memory_region->kvm_arch_commit_memory_region->kvm_mmu_slot_apply_flags

在kvm_mmu_slot_apply_flags函数里：

static void kvm_mmu_slot_apply_flags(struct kvm *kvm,
				     struct kvm_memory_slot *old,
				     struct kvm_memory_slot *new,
				     enum kvm_mr_change change)
{
	bool log_dirty_pages = new->flags & KVM_MEM_LOG_DIRTY_PAGES;

	/*
	 * Update CPU dirty logging if dirty logging is being toggled.  This
	 * applies to all operations.
	 */
	if ((old->flags ^ new->flags) & KVM_MEM_LOG_DIRTY_PAGES)
		kvm_mmu_update_cpu_dirty_logging(kvm, log_dirty_pages);
	...
}

log_dirty_pages相当于是取出了kvm_memory_slot:flags里第KVM_MEM_LOG_DIRTY_PAGES这个bit位的设置情况，log_dirty_pages为0代表没有设置，为1代表设置了．下面的if判断条件意义是：只要原来flags和新的flags在KVM_MEM_LOG_DIRTY_PAGES这个比特位上发生变化时，都会调用kvm_mmu_update_cpu_dirty_logging函数，但是注意第二个参数指定了是否开启PML，kvm_mmu_slot_apply_flags定义如下：

static void kvm_mmu_update_cpu_dirty_logging(struct kvm *kvm, bool enable)
{
	struct kvm_arch *ka = &kvm->arch;

	if (!kvm_x86_ops.cpu_dirty_log_size)
		return;

	if ((enable && ++ka->cpu_dirty_logging_count == 1) ||
	    (!enable && --ka->cpu_dirty_logging_count == 0))
		kvm_make_all_cpus_request(kvm, KVM_REQ_UPDATE_CPU_DIRTY_LOGGING);

	WARN_ON_ONCE(ka->cpu_dirty_logging_count < 0);
}

一般开启PML功能第一个条件就会满足．kvm_make_all_cpus_request只是将KVM_REQ_UPDATE_CPU_DIRTY_LOGGING这个请求给挂到vcpu->requests了，并没有立即写硬件相关的bit位．如下调用链：

kvm_make_all_cpus_request->kvm_make_all_cpus_request_except->kvm_make_vcpus_request_mask->kvm_make_request

最后的kvm_make_request如下：

static inline void kvm_make_request(int req, struct kvm_vcpu *vcpu)
{
	/*
	 * Ensure the rest of the request is published to kvm_check_request's
	 * caller.  Paired with the smp_mb__after_atomic in kvm_check_request.
	 */
	smp_wmb();
	set_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
}

可以看到只是设了一个bit位．那么什么时候设置硬件的比特位，以开启PML功能呢？搜索KVM_REQ_UPDATE_CPU_DIRTY_LOGGING知道，在下一次通过vcpu_enter_guest进入虚拟机时会处理挂在vcpu->requests上的请求：

if (kvm_check_request(KVM_REQ_UPDATE_CPU_DIRTY_LOGGING, vcpu))
	static_call(kvm_x86_update_cpu_dirty_logging)(vcpu);

kvm_x86_update_cpu_dirty_logging符号通过KVM_X86_OP_NULL展开：

KVM_X86_OP_NULL(update_cpu_dirty_logging)
#define KVM_X86_OP(func) \
	DECLARE_STATIC_CALL(kvm_x86_##func, *(((struct kvm_x86_ops *)0)->func));
#define DECLARE_STATIC_CALL(name, func)					\
	extern struct static_call_key STATIC_CALL_KEY(name);		\
	extern typeof(func) STATIC_CALL_TRAMP(name);

可以看到，最后实际调用的是kvm_x86_ops:update_cpu_dirty_logging，其就是vmx_update_cpu_dirty_logging：

.update_cpu_dirty_logging = vmx_update_cpu_dirty_logging,

vmx_update_cpu_dirty_logging会调用secondary_exec_controls_setbit：

secondary_exec_controls_setbit(vmx, SECONDARY_EXEC_ENABLE_PML);

SECONDARY_EXEC_ENABLE_PML定义如下：

#define SECONDARY_EXEC_ENABLE_PML               VMCS_CONTROL_BIT(PAGE_MOD_LOGGING)
#define VMCS_CONTROL_BIT(x)	BIT(VMX_FEATURE_##x & 0x1f)
#define BIT(nr)			(UL(1) << (nr))
#define VMX_FEATURE_PAGE_MOD_LOGGING	( 2*32+ 17) /* "pml" Log dirty pages into buffer */

这其实就是Secondary Processor-Based VM-Execution Controls的第17个bit位，intel虚拟化手册对这个位解释如下：

17 Enable PML If this control is 1, an access to a guest-physical address that sets an EPT dirty bit first adds an entry to the page-modification. See Section 27.2.6.

可以很清楚的看到，这个bit就是开启PML功能的．

再来看secondary_exec_controls_setbit的定义，其是宏定义拼接的：

BUILD_CONTROLS_SHADOW(secondary_exec, SECONDARY_VM_EXEC_CONTROL)
#define BUILD_CONTROLS_SHADOW(lname, uname)				    \
static inline void lname##_controls_set(struct vcpu_vmx *vmx, u32 val)	    \
{									    \
	if (vmx->loaded_vmcs->controls_shadow.lname != val) {		    \
		vmcs_write32(uname, val);				    \
		vmx->loaded_vmcs->controls_shadow.lname = val;		    \
	}								    \
}									    \
static inline u32 __##lname##_controls_get(struct loaded_vmcs *vmcs)	    \
{									    \
	return vmcs->controls_shadow.lname;				    \
}									    \
static inline u32 lname##_controls_get(struct vcpu_vmx *vmx)		    \
{									    \
	return __##lname##_controls_get(vmx->loaded_vmcs);		    \
}									    \
static inline void lname##_controls_setbit(struct vcpu_vmx *vmx, u32 val)   \
{									    \
	lname##_controls_set(vmx, lname##_controls_get(vmx) | val);	    \
}									    \
static inline void lname##_controls_clearbit(struct vcpu_vmx *vmx, u32 val) \
{									    \
	lname##_controls_set(vmx, lname##_controls_get(vmx) & ~val);	    \
}

先看SECONDARY_VM_EXEC_CONTROL的实现，它是在vmcs中的一个偏移：

enum vmcs_field {
...
	SECONDARY_VM_EXEC_CONTROL       = 0x0000401e,
...
}

这个偏移在intel虚拟化手册里的定义正是Secondary Processor-Based VM-Execution Controls寄存器。

再看secondary_exec_controls_setbit的实现，先通过secondary_exec_controls_get拿到原来的vmcs->controls_shadow:secondary_exec这个u32的值和新的val（1<<17）相或，然后在secondary_controls_set里通过vmcs_write32写到当前vmcs的secondary exec control字段，这样就启动了PML功能，关于vmcs_write32的实现如下，当然最后肯定是内联了：

static __always_inline void vmcs_write32(unsigned long field, u32 value)
{
	vmcs_check32(field);
	if (static_branch_unlikely(&enable_evmcs))
		return evmcs_write32(field, value);

	__vmcs_writel(field, value);
}

static __always_inline void __vmcs_writel(unsigned long field, unsigned long value)
{
	vmx_asm2(vmwrite, "r"(field), "rm"(value), field, value);
}

vmwrite就是操作当前cpu的VMCS，关于它intel虚拟化手册有详尽描述．

在前面介绍了qemu+kvm共同开启了PML硬件记录脏页的功能，本小节想分析下kvm内核侧记录脏页的流程，根据intel虚拟化手册，本质上开启PML后，脏页的记录实际上由cpu自动完成，每当guest虚拟机访问内存时，cpu会自动将GPA记录到pml buffer里，软件没有太多的工作，软件里主要是在pml buffer满时将脏信息搬移到dirty ring环形区里，qemu 6.2使用了kvm内核里的kvm_vcpu:dirty_ring以提高效率，而qemu 4.2使用了kvm内核里传统的kvm_memory_slot:dirty_bitmap，后面主要分析dirty ring的方式，而简单分析下dirty_bitmap方式．使用dirty ring的方式避免了内核态/用户态的数据拷贝，提高了效率，后面将详细看到这个过程．

首先在创建vcpu而初始化vmcs的流程里vmx_create_vcpu->init_vmcs：

if (enable_pml) {
	    vmcs_write64(PML_ADDRESS, page_to_phys(vmx->pml_pg));
	    vmcs_write16(GUEST_PML_INDEX, PML_ENTITY_NUM - 1);
    }

enable_pml作为一个模块参数，默认为1：

bool __read_mostly enable_pml = 1;
module_param_named(pml, enable_pml, bool, S_IRUGO);

根据intel虚拟化手册PML_ADDRESS就是vmcs里用来保存pml buffer地址的寄存器：

enum vmcs_field {
    ...
	PML_ADDRESS			= 0x0000200e,
	...
};

page_to_phys是将一个页面转换成物理地址，cpu访问pml address地址时不需要经过mmu，直接拿着物理地址往内存硬件单元上发送，而pml_pg同样在vmx_create_vcpu的初始化流程里分配：

if (enable_pml) {
	vmx->pml_pg = alloc_page(GFP_KERNEL_ACCOUNT | __GFP_ZERO);
	if (!vmx->pml_pg)
		goto free_vpid;
}

根据intel虚拟化手册，pml log buffer是由512个64-bit的条目组成的，所以使用alloc_page分配一页空间就行．然后使用vmcs_write64写入到vmcs的PML_ADDRSS字段即硬件上生效．根据intel虚拟化手册，pml功能还有一个pml index的vmcs字段，它控制了现在可以写pml buffer的哪个条目，它从511递减到0，然后就会产生一个page-modification log-full event导致虚拟机退出：

enum vmcs_field {	
	...
	GUEST_PML_INDEX			= 0x00000812,
	...
};

#define PML_ENTITY_NUM		512

可以看到GUEST_PML_INDEX通过vmcs_write16被初始化最大值511． 当前面小节介绍的enable pml bit打开，pml address以及pml index都设置好后，cpu硬件在每次访问GPA时，都会记录下来这次访问到pml buffer． 当虚拟机因为page-modification log-full event退出时，就会产生vm exit，这会退到宿主机（kvm）里有先有统一的接口去处理：__vmx_handle_exit，page-modification log-full event在kvm里其实是有专门的处理函数的，叫handle_pml_full，只是这个函数较为简单，并没有保存pml buffer里的脏信息到内存别处的动作．保存的动作另在如下路径：

__vmx_handle_exit->vmx_flush_pml_buffer

换言之，只要有虚拟机退出，就会做一下pm buffer同步的事情（这当然也包括page-modification log-full event引起的vm exit），后面会有代码看到，软件正是利用了这个特点，可以主动kick cpu一次调度而引起vm exit，从而调用一次vmx_flush_pml_buffer来同步pml buffer．

现在看下vmx_flush_pml_buffer：

static void vmx_flush_pml_buffer(struct kvm_vcpu *vcpu)
{
	struct vcpu_vmx *vmx = to_vmx(vcpu);
	u64 *pml_buf;
	u16 pml_idx;

	pml_idx = vmcs_read16(GUEST_PML_INDEX);

	/* Do nothing if PML buffer is empty */
	if (pml_idx == (PML_ENTITY_NUM - 1))
		return;

	/* PML index always points to next available PML buffer entity */
	if (pml_idx >= PML_ENTITY_NUM)
		pml_idx = 0;
	else
		pml_idx++;

	pml_buf = page_address(vmx->pml_pg);
	for (; pml_idx < PML_ENTITY_NUM; pml_idx++) {
		u64 gpa;

		gpa = pml_buf[pml_idx];
		WARN_ON(gpa & (PAGE_SIZE - 1));
		kvm_vcpu_mark_page_dirty(vcpu, gpa >> PAGE_SHIFT);
	}

	/* reset PML index */
	vmcs_write16(GUEST_PML_INDEX, PML_ENTITY_NUM - 1);
}

首先从vmcs的GUEST_PML_INDEX字段读出了当前的pml index指向哪个条目，pml_buf相当于又拿到pml page的虚拟地址，因为现在软件访问pml页面需要经过mmu，必须以虚拟地址的形式．注意for循环是从当前的pml index往高处的pml entry去遍历，因为根据intel虚拟化手册，硬件写脏页条目信息到pml buffer是从最高的511个条目往下写的．for循环里比较关键的是调用kvm_vcpu_mark_page_dirty保存脏页信息，其第一个参数vcpu其实就是当前引起vm exit的vcpu，而第二个参数是当前要记录的gpa，它左移了一个页面的大小，就是说对一个页面内的访问（任何字节）的访问都将只占据一个pml entry条目，这可以节省pml page的大小．vmx_flush_pml_buffer的最后reset了pml index，这样硬件又可以重复使用pml entry存储未来guest对GPA的访问了．

继续往下分析kvm_vcpu_mark_page_dirty：

void kvm_vcpu_mark_page_dirty(struct kvm_vcpu *vcpu, gfn_t gfn)
{
	struct kvm_memory_slot *memslot;

	memslot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
	mark_page_dirty_in_slot(vcpu->kvm, memslot, gfn);
}

kvm_vcpu_gfn_to_memslot就不展示它的代码进行详细的分析了，总结来说，所有的gfn都由一个个的kvm_memory_slot去管理，里面记录了一个kvm_memory_slot的起始base_gfn，管理的多少页面npages，同时这段gfn的脏信息就存在dirty_bitmap，只不过使用kvm_memory_slot:dirty_bitmap来存储脏页信息已经不是较新的qemu 6.2的方式了．kvm_vcpu_gfn_to_memslot函数主要是通过gfn采用二分搜索的办法，去找到这个gfn被哪个kvm_memory_slot所管理．

kvm_vcpu_gfn_to_memslot->search_memslots->try_get_memslot函数里有个预防侧信道攻击的接口这里可以简单提下：

/*
 * slot_index can come from vcpu->last_used_slot which is not kept
 * in sync with userspace-controllable memslot deletion. So use nospec
 * to prevent the CPU from speculating past the end of memslots[].
 */
slot_index = array_index_nospec(slot_index, slots->used_slots);
slot = &slots->memslots[slot_index];

通过array_index_nospec将数组索引slot_index钳制（clamp）在o-size之间，这样后续使用这个索引访问数组内容时，不会出现越界问题．array_index_nospec返回的slot_index和后面使用这个slot_index去访问数组内容，人为构造了数据依赖，这样现代cpu不会因为乱序/推测执行而先用了未经clamp的索引去访问数组，这种方式比内存屏障会轻量一些．

继续分析mark_page_dirty_in_slot函数：

void mark_page_dirty_in_slot(struct kvm *kvm,
			     struct kvm_memory_slot *memslot,
		 	     gfn_t gfn)
{
	if (memslot && kvm_slot_dirty_track_enabled(memslot)) {
		unsigned long rel_gfn = gfn - memslot->base_gfn;
		u32 slot = (memslot->as_id << 16) | memslot->id;

		if (kvm->dirty_ring_size)
			kvm_dirty_ring_push(kvm_dirty_ring_get(kvm),
					    slot, rel_gfn);
		else
			set_bit_le(rel_gfn, memslot->dirty_bitmap);
	}
}

kvm_slot_dirty_track_enabled会检查前面的节提到过的KVM_MEM_LOG_DIRTY_PAGES标志．

从这个函数就可以看到脏页信息可以有两种方式去保存一种是脏页环形缓冲区，一种是脏页位图．先简单介绍下脏页位图，因为较新的qemu版本已经很少使用这种低效率的方式了．首先在mark_page_dirty_in_slot这里的函数可以看到，rel_gfn是相对于当前kvm_memory_slot:base_gfn的相对偏移gfn，也就是说kvm_memory_slot:dirty_bitmap只是记录当前memslot的脏页信息，这通过set_bit_le置上相应的bit位即可．

针对kvm_memory_slot:dirty_bitmap的方式，内核kvm侧提供一个ioctl接口，用来同步内核侧的脏页信息到用户态qemu：

static long kvm_vm_ioctl(struct file *filp,
			   unsigned int ioctl, unsigned long arg)
{
  ...
	case KVM_GET_DIRTY_LOG: {
		struct kvm_dirty_log log;

		r = -EFAULT;
		if (copy_from_user(&log, argp, sizeof(log)))
			goto out;
		r = kvm_vm_ioctl_get_dirty_log(kvm, &log);
		break;
	}
  ...
}

然后在kvm_vm_ioctl_get_dirty_log->kvm_get_dirty_log_protect里有：

static int kvm_get_dirty_log_protect(struct kvm *kvm, struct kvm_dirty_log *log)
{
    ...
	unsigned long *dirty_bitmap;
	...
	dirty_bitmap = memslot->dirty_bitmap;
	...
	} else {
		dirty_bitmap_buffer = kvm_second_dirty_bitmap(memslot);
		memset(dirty_bitmap_buffer, 0, n);

		KVM_MMU_LOCK(kvm);
		for (i = 0; i < n / sizeof(long); i++) {
			unsigned long mask;
			gfn_t offset;

			if (!dirty_bitmap[i])
				continue;

			flush = true;
			mask = xchg(&dirty_bitmap[i], 0);
			dirty_bitmap_buffer[i] = mask;

			offset = i * BITS_PER_LONG;
			kvm_arch_mmu_enable_log_dirty_pt_masked(kvm, memslot,
								offset, mask);
		}
		KVM_MMU_UNLOCK(kvm);
	}

	if (flush)
		kvm_arch_flush_remote_tlbs_memslot(kvm, memslot);

	if (copy_to_user(log->dirty_bitmap, dirty_bitmap_buffer, n))
	...
}

从这段代码可以很清楚的看到，kvm_memory_slot:dirty_bitmap先是被xchg到一个dirty_bitmap_buffer，然后又将它copy_to_user空间，这也就是前面提到的，使用dirty_bitmap方式效率较低，因为这种方式存在内核态/用户态拷贝．

下面重点介绍脏页环形缓冲区的方式．

dirty ring功能涉及qemu/kvm的配合，qemu侧的支持在下一节去介绍．内核kvm侧通过如下的补丁引入了对dirty ring的基本支持：

fb04a1eddb1a65b6588a021bdc132270d5ae48bb 最早在v5.11引入

我们的内核在372引入了这个功能，147没有．

如果qemu侧支持dirty ring的功能（具体见下节），那么就可以发起KVM_CAP_DIRTY_LOG_RING的ioctl，这个ioctl cmd的处理函数是kvm_vm_ioctl_enable_dirty_log_ring：

static int kvm_vm_ioctl_enable_cap_generic(struct kvm *kvm,
					   struct kvm_enable_cap *cap)
{
    ...
	case KVM_CAP_DIRTY_LOG_RING:
		return kvm_vm_ioctl_enable_dirty_log_ring(kvm, cap->args[0]);
    ...
}

而在kvm_vm_ioctl_enable_dirty_log_ring函数里，会设置kvm:dirty_ring_size：

static int kvm_vm_ioctl_enable_dirty_log_ring(struct kvm *kvm, u32 size)
{
    ...
	} else {
		kvm->dirty_ring_size = size;
		r = 0;
	}
    ...
}

size是qemu用户态传来的，当size大于0时，就相当于是开启了内核的dirty ring功能，同时在kvm_vm_ioctl_enable_dirty_log_ring函数里会有判断传进来的size最大为KVM_DIRTY_RING_MAX_ENTRIES(65536)，在前面的mark_page_dirty_in_slot函数里正是利用了kvm:dirty_ring_size来作为判断条件看是否走kvm_dirty_ring_push函数这种dirty ring的方式记录脏页．

现在回到mark_page_dirty_in_slot继续往下分析内核kvm侧的脏页记录（dirty ring方式），先看一个获取kvm_dirty_ring的辅助函数：

struct kvm_dirty_ring *kvm_dirty_ring_get(struct kvm *kvm)
{
	struct kvm_vcpu *vcpu = kvm_get_running_vcpu();

	WARN_ON_ONCE(vcpu->kvm != kvm);

	return &vcpu->dirty_ring;
}
struct kvm_vcpu *kvm_get_running_vcpu(void)
{
	struct kvm_vcpu *vcpu;

	preempt_disable();
	vcpu = __this_cpu_read(kvm_running_vcpu);
	preempt_enable();

	return vcpu;
}

可以看到kvm_dirty_ring是per-vcpu的，也就是每个vcpu都有一个dirty ring，同时pcp变量kvm_running_vcpu记录了当前物理cpu上运行的是哪个vcpu．继续往下看mark_page_dirty_in_slot调用的kvm_dirty_ring_push：

void kvm_dirty_ring_push(struct kvm_dirty_ring *ring, u32 slot, u64 offset)
{
	struct kvm_dirty_gfn *entry;

	/* It should never get full */
	WARN_ON_ONCE(kvm_dirty_ring_full(ring));

	entry = &ring->dirty_gfns[ring->dirty_index & (ring->size - 1)];

	entry->slot = slot;
	entry->offset = offset;
	/*
	 * Make sure the data is filled in before we publish this to
	 * the userspace program.  There's no paired kernel-side reader.
	 */
	smp_wmb();
	kvm_dirty_gfn_set_dirtied(entry);
	ring->dirty_index++;
	trace_kvm_dirty_ring_push(ring, slot, offset);
}

先从dirty_gfns里拿出kvm_dirty_gfn，这个结构体内核/qemu都可以解释其格式，后面会介绍是因为dirty_gfns正是在内核空间和qemu用户空间共享的内存．kvm_dirty_gfn其实就是描述了guest访问某个gfn时关于脏信息的集合．前面分析父函数mark_page_dirty_in_slot时，知道offset其实是相对于当前gfn所在的kvm_memory_slot的base_gfn，同时slot号由kvm_memory_slot:as_id以及kvm_memory_slot:id两部分组成形成该gfn所属的槽号，也会记录到kvm_dirty_gfn里．kvm_dirty_ring_push里另一个调用的关键函数是kvm_dirty_gfn_set_dirtied：

static inline void kvm_dirty_gfn_set_dirtied(struct kvm_dirty_gfn *gfn)
{
	gfn->flags = KVM_DIRTY_GFN_F_DIRTY;
}

这里其实是设置了当前gfn的状态，表示写脏了，guest刚访问过，KVM_DIRTY_GFN_F_DIRTY就代表gfn的一种dirty状态，这里涉及到gfn状态变化的一个简单状态机，直接引用内核代码的注释：

/*
 * KVM dirty GFN flags, defined as:
 *
 * |---------------+---------------+--------------|
 * | bit 1 (reset) | bit 0 (dirty) | Status       |
 * |---------------+---------------+--------------|
 * |             0 |             0 | Invalid GFN  |
 * |             0 |             1 | Dirty GFN    |
 * |             1 |             X | GFN to reset |
 * |---------------+---------------+--------------|
 *
 * Lifecycle of a dirty GFN goes like:
 *
 *      dirtied         harvested        reset
 * 00 -----------> 01 -------------> 1X -------+
 *  ^                                          |
 *  |                                          |
 *  +------------------------------------------+
 *
 * The userspace program is only responsible for the 01->1X state
 * conversion after harvesting an entry.  Also, it must not skip any
 * dirty bits, so that dirty bits are always harvested in sequence.
 */
#define KVM_DIRTY_GFN_F_DIRTY           _BITUL(0)
#define KVM_DIRTY_GFN_F_RESET           _BITUL(1)
#define KVM_DIRTY_GFN_F_MASK            0x3

也就是说guest访问过的gfn，由内核kvm置脏（因为内核通过PML硬件机制首先知道了哪些gfn被访问过），然后由qemu userspace去harvested，说白了这里其实就有一个生产者－消费者模型，内核记录脏页，由qemu（具体的就是live migration相关的代码）去消费．当qemu消费（harvested）了脏页信息，又需要推进状态机，变kvm_dirty_gfn:flags为KVM_DIRTY_GFN_F_RESET．前面介绍的其实都是直接使用kvm_dirty_gfn的空间了，但是关于其来源（分配）并没有分析，现在分析这点．

在创建vcpu时，就会检查kvm_vcpu:dirty_ring_size是否有值，如果有值，就会调用kvm_dirty_ring_alloc分配kvm_dirty_ring:dirty_gfns的空间：

static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
{
    ...
	if (kvm->dirty_ring_size) {
		r = kvm_dirty_ring_alloc(&vcpu->dirty_ring,
					 id, kvm->dirty_ring_size);
		if (r)
			goto arch_vcpu_destroy;
	}
	...
}

int kvm_dirty_ring_alloc(struct kvm_dirty_ring *ring, int index, u32 size)
{
	ring->dirty_gfns = vzalloc(size);
	if (!ring->dirty_gfns)
		return -ENOMEM;

	ring->size = size / sizeof(struct kvm_dirty_gfn);
	ring->soft_limit = ring->size - kvm_dirty_ring_get_rsvd_entries();
	ring->dirty_index = 0;
	ring->reset_index = 0;
	ring->index = index;

	return 0;
}

以上就是kvm侧使用dirty ring对于脏页记录/处理的流程．

qemu侧对于dirty ring的支持，主要涉及下面一些补丁：

b4420f198dd8eab53cf6062c1871d0e5f5601e86 涉及dirty ring的基本支持 v6.1.0-rc0
2ea5cb0a47c9dbf78235de30a0d5846a4ab6d995 涉及dirty-ring-size参数接口方面的代码 v6.1.0-rc0
856e23a0fb92b0949eace7f43a521e0214246735 针对arm架构有一些微调 v8.1.0-rc0

在上节介绍kvm侧时，提到了用户态kvm要传入大于0的size，内核态kvm才会开启dirty ring功能．这在qemu的kvm_init函数中有所体现：

if (s->kvm_dirty_ring_size > 0) {
     uint64_t ring_bytes;

     ring_bytes = s->kvm_dirty_ring_size * sizeof(struct kvm_dirty_gfn);

     /* Read the max supported pages */
     ret = kvm_vm_check_extension(s, KVM_CAP_DIRTY_LOG_RING);
     if (ret > 0) {
         if (ring_bytes > ret) {
             error_report("KVM dirty ring size %" PRIu32 " too big "
                          "(maximum is %ld).  Please use a smaller value.",
                          s->kvm_dirty_ring_size,
                          (long)ret / sizeof(struct kvm_dirty_gfn));
             ret = -EINVAL;
             goto err;
         }

         ret = kvm_vm_enable_cap(s, KVM_CAP_DIRTY_LOG_RING, 0, ring_bytes);
         if (ret) {
             error_report("Enabling of KVM dirty ring failed: %s. "
                          "Suggested minimum value is 1024.", strerror(-ret));
             goto err;
         }

         s->kvm_dirty_ring_bytes = ring_bytes;
      } else {
          warn_report("KVM dirty ring not available, using bitmap method");
          s->kvm_dirty_ring_size = 0;
     }
 }

这里就可以看到使用KVM_CAP_DIRTY_LOG_RING cmd去调用ioctl，到了kvm就可以设置kvm:dirty_ring_size非0，这样内核态kvm相关的dirty ring的逻辑就可以运行起来．这里可以看到要想通过kvm_vm_enable_cap的KVM_CAP_DIRTY_LOG_RING到内核里去设置kvm:dirty_ring_size为非0，实际上是有两个条件，一是KVMState:kvm_dirty_ring_size要大于0，二是以KVM_CAP_DIRTY_LOG_RING cmd调用的kvm_vm_check_extension要大于0，这其实是从两个角度共同控制是否使用dirty ring功能．先说第一个条件，这是qemu（以及kvm）开给用户的选项能力控制dirty ring的开启．KVMState:kvm_dirty_ring_size在函数kvm_set_dirty_ring_size设置：

static void kvm_set_dirty_ring_size(Object *obj, Visitor *v,
                                    const char *name, void *opaque,
                                    Error **errp)
{
    ...
    s->kvm_dirty_ring_size = value;
}

kvm_set_dirty_ring_size作为dirty-ring-size这个属性的set函数被添加到ObjectClass:properties这个hash表里，在初始化的时候调用：

static void kvm_accel_class_init(ObjectClass *oc, void *data)
{
    ...
    object_class_property_add(oc, "dirty-ring-size", "uint32",
        kvm_get_dirty_ring_size, kvm_set_dirty_ring_size,
        NULL, NULL);
    ...
}

在介绍qemu选项的代码中（文件qemu-options.hx）可以看到如下对dirty-ring-size描述：

``dirty-ring-size=n``
     When the KVM accelerator is used, it controls the size of the per-vCPU
     dirty page ring buffer (number of entries for each vCPU). It should
     be a value that is power of two, and it should be 1024 or bigger (but
     still less than the maximum value that the kernel supports).  4096
     could be a good initial value if you have no idea which is the best.
     Set this value to 0 to disable the feature.  By default, this feature
     is disabled (dirty-ring-size=0).  When enabled, KVM will instead
     record dirty pages in a bitmap.

可以看到，要想使能dirty ring功能，必须将dirty-ring-size设置为非0，一种典型的设置：-accel kvm,dirty-ring-size=4096，目前找了个环境看了下没有显式的设置这个参数，所以目前621环境是没有使用起这个功能的．下面分析第二个控制开启dirty ring的选项：以KVM_CAP_DIRTY_LOG_RING cmd调用kvm_vm_check_extension要大于0．在kvm内核侧这个cmd的实现如下，实际是返回了内核目前支持的最大kvm_dirty_gfn条目数：

#if KVM_DIRTY_LOG_PAGE_OFFSET > 0
		return KVM_DIRTY_RING_MAX_ENTRIES * sizeof(struct kvm_dirty_gfn);
#else
		return 0;

/*
 * Arch needs to define the macro after implementing the dirty ring
 * feature.  KVM_DIRTY_LOG_PAGE_OFFSET should be defined as the
 * starting page offset of the dirty ring structures.
 */
#ifndef KVM_DIRTY_LOG_PAGE_OFFSET
#define KVM_DIRTY_LOG_PAGE_OFFSET 0
#endif

可以看到，arch要是支持了dirty ring功能，就会将KVM_DIRTY_LOG_PAGE_OFFSET设置为非0，比如x86将其实现为64．而arm64没有将其定义为大于0的值，而是使用include/uapi/linux/kvm.h里的默认值0，所以621的代码要想支持arm64的dirty ring，需要backport一些代码．这个宏其作用其实是将dirty ring从内核空间映射到用户态空间的偏移．

介绍完qemu侧对dirty ring开启的控制后，可以分析下qemu侧怎么记录/获取脏页的．

qemu里传统的采用dirty_bmap的方式是通过以下代码链完成从内核侧获取脏页信息到qemu用户态：

kvm_log_sync->kvm_physical_sync_dirty_bitmap->kvm_slot_get_dirty_log->kvm_vm_ioctl

最后的kvm_slot_get_dirty_log实现如下：

static bool kvm_slot_get_dirty_log(KVMState *s, KVMSlot *slot)
{
    struct kvm_dirty_log d = {};
    int ret;

    d.dirty_bitmap = slot->dirty_bmap;
    d.slot = slot->slot | (slot->as_id << 16);
    ret = kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d);

    if (ret == -ENOENT) {
        /* kernel does not have dirty bitmap in this slot */
        ret = 0;
    }
    if (ret) {
        error_report_once("%s: KVM_GET_DIRTY_LOG failed with %d",
                          __func__, ret);
    }
    return ret == 0;
}

使用KVM_GET_DIRTY_LOG这个命令调用到内核里，在内核里的处理，前面已经介绍过了．

上面简单介绍了下传统的dirty_bmap方式，下面主要还是介绍dirty ring的方式，这种方式在qemu的代码里通过以下调用链完成日志收集：

kvm_log_sync_global->kvm_dirty_ring_flush->kvm_dirty_ring_reap->kvm_dirty_ring_reap_locked->kvm_dirty_ring_reap_one->kvm_dirty_ring_mark_page

从kvm_log_sync_global再往上，qemu有两种手段/途径去同步内核的脏页信息，一种是在热迁移路径里现做，这种路径是kvm_log_sync_global作为log_sync_global回调函数而被调用，前面dirty bitmap的方式，使用函数kvm_log_sync其实也是作为log_sync回调函数而使用的，这两个回调钩子在如下函数代码里初始化：

void kvm_memory_listener_register(KVMState *s, KVMMemoryListener *kml,
                                  AddressSpace *as, int as_id, const char *name)
{
    ...
    if (s->kvm_dirty_ring_size) {
        kml->listener.log_sync_global = kvm_log_sync_global;
    } else {
        kml->listener.log_sync = kvm_log_sync;
        kml->listener.log_clear = kvm_log_clear;
    }
    ...
}

在这里也可以很清楚的看到，dirty bitmap和dirty ring在qemu的代码里走了不同的路径，kvm_dirty_ring_size怎么设置的前面已经详细分析过了．

dirty ring的第一种方式同步内核脏页信息是热迁移现做，这种方式的一个路径比如如下：

ram_init_bitmaps->migration_bitmap_sync_precopy->migration_bitmap_sync->memory_global_dirty_log_sync->
memory_region_sync_dirty_bitmap->log_sync_global(kvm_log_sync_global)->kvm_dirty_ring_flush->
kvm_dirty_ring_reap->kvm_dirty_ring_reap_locked->kvm_dirty_ring_reap_one->kvm_dirty_ring_mark_page

对于上面的函数调用链，这里介绍两点，一是ram_init_bitmaps函数里是先调用了memory_global_dirty_log_start再调用migration_bitmap_sync_precopy，也就是热迁移一开启脏页迁移后就做了一次从内核获取脏页信息的动作：

static void ram_init_bitmaps(RAMState *rs)
{
  ...
        if (!migrate_background_snapshot()) {
            memory_global_dirty_log_start(GLOBAL_DIRTY_MIGRATION);
            migration_bitmap_sync_precopy(rs);
        }
  ...
}

第二点是memory_region_sync_dirty_bitmap函数，这个函数屏蔽了dirty_bitmap和dirty ring方式的差异，从它向上的父函数是不知道底层这两种不同的实现方式的：

static void memory_region_sync_dirty_bitmap(MemoryRegion *mr)
{
        if (listener->log_sync) {
            ...
            listener->log_sync(listener, &mrs);//dirty_bitmap方式，kvm_log_sync
            ...
        } else if (listener->log_sync_global) {
            ...
            listener->log_sync_global(listener); //dirty ring方式，kvm_log_sync_global
            ...
        }
 }

dirty ring的第二种同步内核脏页信息的方式是通过一个线程在后台每隔1s做一次：

kvm_dirty_ring_reaper_thread->
kvm_dirty_ring_reap->kvm_dirty_ring_reap_locked->kvm_dirty_ring_reap_one->kvm_dirty_ring_mark_page

上面的调用链第二行和前面的第一种同步脏页信息的路径最后一行是一样的，只有最前面的kvm_dirty_ring_reaper_thread这时是通过创建一个线程来做同步：

static int kvm_dirty_ring_reaper_init(KVMState *s)
{
    struct KVMDirtyRingReaper *r = &s->reaper;

    qemu_thread_create(&r->reaper_thr, "kvm-reaper",
                       kvm_dirty_ring_reaper_thread,
                       s, QEMU_THREAD_JOINABLE);

    return 0;
}

static void *kvm_dirty_ring_reaper_thread(void *data)
{
      ...
      while (true) {
        r->reaper_state = KVM_DIRTY_RING_REAPER_WAIT;
        trace_kvm_dirty_ring_reaper("wait");
        /*
         * TODO: provide a smarter timeout rather than a constant?
         */
        sleep(1);

        trace_kvm_dirty_ring_reaper("wakeup");
        r->reaper_state = KVM_DIRTY_RING_REAPER_REAPING;

        qemu_mutex_lock_iothread();
        kvm_dirty_ring_reap(s);
        qemu_mutex_unlock_iothread();

        r->reaper_iteration++;
    }
    ...
}

可以看到这个后台定期1s同步脏页信息的线程叫kvm-reaper．

分析完了qemu使用dirty ring的两种同步脏页信息的路径，下面可以具体看下qemu将脏页信息又搬到了哪里，先看kvm_dirty_ring_reap_one函数：

static uint32_t kvm_dirty_ring_reap_one(KVMState *s, CPUState *cpu)
{
    struct kvm_dirty_gfn *dirty_gfns = cpu->kvm_dirty_gfns, *cur;
    uint32_t ring_size = s->kvm_dirty_ring_size;
    uint32_t count = 0, fetch = cpu->kvm_fetch_index;

    assert(dirty_gfns && ring_size);
    trace_kvm_dirty_ring_reap_vcpu(cpu->cpu_index);

    while (true) {
        cur = &dirty_gfns[fetch % ring_size];
        if (!dirty_gfn_is_dirtied(cur)) {
            break;
        }
        kvm_dirty_ring_mark_page(s, cur->slot >> 16, cur->slot & 0xffff,
                                 cur->offset);
        dirty_gfn_set_collected(cur);
        trace_kvm_dirty_ring_page(cpu->cpu_index, fetch, cur->offset);
        fetch++;
        count++;
    }
    cpu->kvm_fetch_index = fetch;
    cpu->dirty_pages += count;

    return count;
}

这个函数从CPUState:kvm_dirty_gfns里取出脏页信息，kvm_dirty_gfn前面的分析提到过，它是内核和qemu都认识的一个结构体，然后在while循环里针对所有设置了KVM_DIRTY_GFN_F_DIRTY标志的kvm_dirty_gfn去调用kvm_dirty_ring_mark_page函数：

static bool dirty_gfn_is_dirtied(struct kvm_dirty_gfn *gfn)
{
    return gfn->flags == KVM_DIRTY_GFN_F_DIRTY;
}

kvm_dirty_ring_mark_page函数里将脏页信息又转移到了KVMSlot:dirty_bmap：

static void kvm_dirty_ring_mark_page(KVMState *s, uint32_t as_id,
                                     uint32_t slot_id, uint64_t offset)
{
    KVMMemoryListener *kml;
    KVMSlot *mem;

    if (as_id >= s->nr_as) {
        return;
    }

    kml = s->as[as_id].ml;
    mem = &kml->slots[slot_id];

    if (!mem->memory_size || offset >=
        (mem->memory_size / qemu_real_host_page_size)) {
        return;
    }

    set_bit(offset, mem->dirty_bmap);
}

先通过as_id找到AddressSpace，再通过slot_id找到是哪个KVMSlot，最后将KVMSlot:dirty_bmap对应offset的位置1，代表对应的这个页面被写过．kvm_dirty_ring_reap_one调用完kvm_dirty_ring_mark_page将脏信息转移到KVMSlot:dirty_bmap后，又调用dirty_gfn_set_collected将对应的kvm_dirty_gfn:flags设置为KVM_DIRTY_GFN_F_RESET，表示我qemu作为consumer，已经使用了脏页信息了，你kvm（内核）作为producer可以清除这个脏信息了，但是发起清除的这个请求由qemu来做，只是kvm执行这个动作，在kvm_dirty_ring_reap_one搜集转移了脏信息后，它的父函数kvm_dirty_ring_reap_locked就可以调用KVM_RESET_DIRTY_RINGS这个cmd的ioctl请求了：

static uint64_t kvm_dirty_ring_reap_locked(KVMState *s)
{
    ...
    CPU_FOREACH(cpu) {
        total += kvm_dirty_ring_reap_one(s, cpu);
    }

    if (total) {
        ret = kvm_vm_ioctl(s, KVM_RESET_DIRTY_RINGS);
        assert(ret == total);
    }
    ...
}

在内核kvm侧，处理KVM_RESET_DIRTY_RINGS这个ioctl请求是kvm_vm_ioctl_reset_dirty_pages函数：

static int kvm_vm_ioctl_reset_dirty_pages(struct kvm *kvm)
{
    ...
	kvm_for_each_vcpu(i, vcpu, kvm)
		cleared += kvm_dirty_ring_reset(vcpu->kvm, &vcpu->dirty_ring);
	...
}

而在kvm_dirty_ring_reset函数里会检查kvm_dirty_gfn:flags是否是KVM_DIRTY_GFN_F_RESET，如果是就调用kvm_dirty_gfn_set_invalid将kvm_dirty_gfn:flags设置为0，表示这个脏信息已经被用户态回收过了：

int kvm_dirty_ring_reset(struct kvm *kvm, struct kvm_dirty_ring *ring)
{
    ...
	while (true) {
		entry = &ring->dirty_gfns[ring->reset_index & (ring->size - 1)];

		if (!kvm_dirty_gfn_harvested(entry))
			break;

		next_slot = READ_ONCE(entry->slot);
		next_offset = READ_ONCE(entry->offset);

		/* Update the flags to reflect that this GFN is reset */
		kvm_dirty_gfn_set_invalid(entry);
		...
	}
}

static inline void kvm_dirty_gfn_set_invalid(struct kvm_dirty_gfn *gfn)
{
	gfn->flags = 0;
}

注意这里用户态/内核态的同步逻辑，内核侧写脏时，根据前面层的分析，其直接调用kvm_dirty_gfn_set_dirtied而没有判断之前的状态，因为之前无非就是非脏/脏两种，将非脏变成脏，正是记录了guest对gfn的访问，将脏变成脏也不会丢失脏信息没什么问题．而内核侧需要将flags变成0表示invalid状态时，需要检查其之前是不是KVM_DIRTY_GFN_F_RESET，这个flags的值只有用户态自己回收了脏信息，才会设置，这样避免脏信息丢失．这里也展示了前面层提到的简单状态机．

以上的分析都是说用户态直接拿来信息用便是，但是这个通路究竟怎么联系起来的，前面层分析传统的dirty_bitmap方式，有介绍到传统的方式是copy_to_user这种内核态/用户态间相互拷贝．但是dirty ring是mmap的方式，之前的层分析过了，kvm_dirty_ring:dirty_gfns是在内核虚拟空间通过vzalloc得到的，而在qemu里，创建完vcpu后通过kvm_init_vcpu初始化vcpu时，有以下代码：

int kvm_init_vcpu(CPUState *cpu, Error **errp)
{
    ...
    if (s->kvm_dirty_ring_size) {
        /* Use MAP_SHARED to share pages with the kernel */
        cpu->kvm_dirty_gfns = mmap(NULL, s->kvm_dirty_ring_bytes,
                                   PROT_READ | PROT_WRITE, MAP_SHARED,
                                   cpu->kvm_fd,
                                   PAGE_SIZE * KVM_DIRTY_LOG_PAGE_OFFSET);
        if (cpu->kvm_dirty_gfns == MAP_FAILED) {
            ret = -errno;
            DPRINTF("mmap'ing vcpu dirty gfns failed: %d\n", ret);
            goto err;
        }
    }
    ...
}

也就是说，用户态对cpu->kvm_fd所指的文件（代表了vcpu，内核抽象出来的fd供用户态操作vcpu）偏移PAGE_SIZE * KVM_DIRTY_LOG_PAGE_OFFSET处的内容映射到了其用户态虚拟空间．这个mmap函数会通过cpu->kvm_fd参数找到内核里对应这个文件fops即kvm_vcpu_fops：

static struct file_operations kvm_vcpu_fops = {
	.release        = kvm_vcpu_release,
	.unlocked_ioctl = kvm_vcpu_ioctl,
	.mmap           = kvm_vcpu_mmap,
	.llseek		= noop_llseek,
	KVM_COMPAT(kvm_vcpu_compat_ioctl),
};

可以看到，这里设置了mmap回调为kvm_vcpu_mmap，通过如下调用链用户态的mmap系统调用最终会来到这个kvm_vcpu_mmap函数：

SYSCALL_DEFINE6(mmap_pgoff...)->ksys_mmap_pgoff->vm_mmap_pgoff->do_mmap_pgoff->do_mmap->mmap_region->call_mmap: return file->f_op->mmap(file, vma);

kvm_vcpu_mmap函数的逻辑很简单，在做了一些合法性判断后，就将vma的vm_ops设置为kvm_vcpu_vm_ops了，这个vm_ops里也很简单，只实现了fault回调函数为kvm_vcpu_fault：

static const struct vm_operations_struct kvm_vcpu_vm_ops = {
	.fault = kvm_vcpu_fault,
};

static int kvm_vcpu_mmap(struct file *file, struct vm_area_struct *vma)
{
	struct kvm_vcpu *vcpu = file->private_data;
	unsigned long pages = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;

	if ((kvm_page_in_dirty_ring(vcpu->kvm, vma->vm_pgoff) ||
	     kvm_page_in_dirty_ring(vcpu->kvm, vma->vm_pgoff + pages - 1)) &&
	    ((vma->vm_flags & VM_EXEC) || !(vma->vm_flags & VM_SHARED)))
		return -EINVAL;

	vma->vm_ops = &kvm_vcpu_vm_ops;
	return 0;
}

然后用户态访问这个映射的dirty ring时缺页异常里有：

...->handle_mm_fault->__handle_mm_fault->handle_pte_fault->do_fault->do_read_fault->__do_fault: ret = vma->vm_ops->fault(vmf);

最终会来到kvm_vcpu_fault这个fault函数，在这个函数里主要是判断访问的偏移落在了哪个范围，不同的范围得到不同的page，然后给到vmf->page，这样回到缺页的公共流程里，填充页表，下一次访问时就是dirty ring的内容了：

static vm_fault_t kvm_vcpu_fault(struct vm_fault *vmf)
{
	struct kvm_vcpu *vcpu = vmf->vma->vm_file->private_data;
	struct page *page;

	if (vmf->pgoff == 0)
		page = virt_to_page(vcpu->run);
#ifdef CONFIG_X86
	else if (vmf->pgoff == KVM_PIO_PAGE_OFFSET)
		page = virt_to_page(vcpu->arch.pio_data);
#endif
#ifdef CONFIG_KVM_MMIO
	else if (vmf->pgoff == KVM_COALESCED_MMIO_PAGE_OFFSET)
		page = virt_to_page(vcpu->kvm->coalesced_mmio_ring);
#endif
	else if (kvm_page_in_dirty_ring(vcpu->kvm, vmf->pgoff))
		page = kvm_dirty_ring_get_page(
		    &vcpu->dirty_ring,
		    vmf->pgoff - KVM_DIRTY_LOG_PAGE_OFFSET);
	else
		return kvm_arch_vcpu_fault(vcpu, vmf);
	get_page(page);
	vmf->page = page;
	return 0;
}

注意最后的kvm_dirty_ring_get_page里使用了vmalloc_to_page，因为当时在kvm里分配这段空间时使用的就是vzalloc，属于内核的vmalloc虚拟空间．

在即将结束＂脏页跟踪机制＂这节时，最后想分析下qemu代码里脏页信息的流转过程，这个过程涉及到qemu里虚拟机热迁移的整体流程，从脏页信息流转的角度切入这个虚拟机热迁移过程，以为其它节介绍虚拟机热迁移开出一个引子．

在前面已经介绍到，内核的脏页信息在kvm_dirty_ring_reap_one->kvm_dirty_ring_mark_page这个函数里被转移到了KVMSlot:dirty_bmap里，其实这个流程是处于一个更长的虚拟机迁移流程里：

migration_thread->migration_iteration_run->qemu_savevm_state_pending->save_live_pending(ram_save_pending)->migration_bitmap_sync_precopy
->migration_bitmap_sync->memory_global_dirty_log_sync->memory_region_sync_dirty_bitmap->log_sync_global(kvm_log_sync_global)
->kvm_dirty_ring_flush->kvm_dirty_ring_reap->kvm_dirty_ring_reap_locked->kvm_dirty_ring_reap_one->kvm_dirty_ring_mark_page

从内核里拿到脏页信息并转移到KVMSlot:dirty_bmap：

set_bit(offset, mem->dirty_bmap);

后又有流程：

migration_thread->migration_iteration_run->qemu_savevm_state_pending->save_live_pending(ram_save_pending)->migration_bitmap_sync_precopy
->migration_bitmap_sync->memory_global_dirty_log_sync->memory_region_sync_dirty_bitmap->log_sync_global(kvm_log_sync_global)
->kvm_slot_sync_dirty_pages->cpu_physical_memory_set_dirty_lebitmap

将脏页信息转移到了ram_list.dirty_memory全局脏页信息表里：

static inline void cpu_physical_memory_set_dirty_lebitmap(unsigned long *bitmap,
                                                          ram_addr_t start,
                                                          ram_addr_t pages)
{
            ...
            for (i = 0; i < DIRTY_MEMORY_NUM; i++) {
                blocks[i] =
                    qatomic_rcu_read(&ram_list.dirty_memory[i])->blocks;
            }

            for (k = 0; k < nr; k++) {
                if (bitmap[k]) {
                    unsigned long temp = leul_to_cpu(bitmap[k]);

                    qatomic_or(&blocks[DIRTY_MEMORY_VGA][idx][offset], temp);

                    if (global_dirty_tracking) {
                        qatomic_or(
                                &blocks[DIRTY_MEMORY_MIGRATION][idx][offset],
                                temp);
                        if (unlikely(
                            global_dirty_tracking & GLOBAL_DIRTY_DIRTY_RATE)) {
                            total_dirty_pages += ctpopl(temp);
                        }
                    }

                    if (tcg_enabled()) {
                        qatomic_or(&blocks[DIRTY_MEMORY_CODE][idx][offset],
                                   temp);
                    }
                }
                ...
}

随后又有流程：

migration_thread->migration_iteration_run->qemu_savevm_state_pending->save_live_pending(ram_save_pending)->migration_bitmap_sync_precopy
->migration_bitmap_sync->ramblock_sync_dirty_bitmap->cpu_physical_memory_sync_dirty_bitmap

将上面全局的bitmap信息又转移到了每RAMBlock:bmap里：

static inline
uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb,
                                               ram_addr_t start,
                                               ram_addr_t length)
{
    ...
    unsigned long *dest = rb->bmap;
    ...
        src = qatomic_rcu_read(
                &ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION])->blocks;

        for (k = page; k < page + nr; k++) {
            if (src[idx][offset]) {
                unsigned long bits = qatomic_xchg(&src[idx][offset], 0);
                unsigned long new_dirty;
                new_dirty = ~dest[k];
                dest[k] |= bits;
                new_dirty &= bits;
                num_dirty += ctpopl(new_dirty);
            }
    ...
}

最后迁移发送内存的流程，使用的是最后的RAMBlock:bmap里的脏页信息，比如这样的一个路径：

migration_thread->migration_iteration_run
->qemu_savevm_state_iterate->save_live_iterate(ram_save_iterate)->ram_find_and_save_block->find_dirty_block->migration_bitmap_find_dirty

最后的migration_bitmap_find_dirty就是使用RAMBlock:bmap的信息来查询脏页信息，决定只发送脏页：

static inline
unsigned long migration_bitmap_find_dirty(RAMState *rs, RAMBlock *rb,
                                          unsigned long start)
{
    unsigned long size = rb->used_length >> TARGET_PAGE_BITS;
    unsigned long *bitmap = rb->bmap;

    if (ramblock_is_ignored(rb)) {
        return size;
    }

    return find_next_bit(bitmap, size, start);
}

找到脏页后ram_find_and_save_block->ram_save_host_page函数去发送脏页面，这样整个脏页从内核态如何到用户态，用户态qemu又如何转移脏页信息，以及最后在哪里使用的就都清楚了．

以上就是＂脏页跟踪机制＂的全部流程，后续还要介绍qemu里虚拟机的迁移流程．