> For the complete documentation index, see [llms.txt](https://richardweiyang-2.gitbook.io/understanding_qemu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://richardweiyang-2.gitbook.io/understanding_qemu/00-lm/04-ram_migration.md). # 内存热迁移 内存是整个虚拟机中重要的部分，也是迁移过程中迁移量最大的部分。 首先我们将从迁移框架的流程上看看整个过程都有哪些函数参与其中，了解内存迁移的流程结构。 接着我们要从数据结构层面看看我们在这些流程中究竟是要处理哪些数据。 ## 内存迁移流程 ### 发送流程 要说流程，还是要先回到总体架构那一节中的总体流程。 ``` migration_thread() qemu_savevm_state_header qemu_put_be32(f, QEMU_VM_FILE_MAGIC); qemu_put_be32(f, QEMU_VM_FILE_VERSION); qemu_put_be32(f, QEMU_VM_CONFIGURATION); vmstate_save_state(f, &vmstate_configuration, &savevm_state, 0); qemu_savevm_send_open_return_path(s->to_dst_file); qemu_savevm_send_ping(s->to_dst_file, 1); qemu_savevm_command_send(f, MIG_CMD_PING, , (uint8_t *)&buf) ; iterate savevm_state and call save_setup qemu_savevm_state_setup(s->to_dst_file); save_section_header(f, se, QEMU_VM_SECTION_START) se->ops->save_setup(f, se->opaque) save_section_footer(f, se) precopy_notify(PRECOPY_NOTIFY_SETUP, &local_err) migrate_set_state(&s->state, MIGRATION_STATUS_SETUP, MIGRATION_STATUS_ACTIVE); migration_iteration_run ; iterate savevm_state and call save_live_pending qemu_savevm_state_pending(pend_pre/compat/post) se->ops->save_live_pending() ; iterate savevm_state and call save_live_iterate qemu_savevm_state_iterate() save_section_header(f, se, QEMU_VM_SECTION_PART) se->ops->save_live_iterate(f, se->opaque) save_section_footer(f, se) migration_completion() qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER, NULL); vm_stop_force_state(RUN_STATE_FINISH_MIGRATE) qemu_savevm_state_complete_precopy(s->to_dst_file, false, inactivate); ; iterate savevm_state and call save_live_complete_precopy cpu_synchronize_all_states(); save_section_header(f, se, QEMU_VM_SECTION_END); se->ops->save_live_complete_precopy(f, se->opaque) save_section_footer(f, se); ; iterate savevm_state and call vmstate_save save_section_header(f, se, QEMU_VM_SECTION_FULL); vmstate_save(f, se, vmdesc) save_section_footer(f, se); migration_detect_error migration_update_counters migration_iteration_finish ``` 在这个基础上我们进一步抽取和简化，能看到整个过程中主要是这么几个回调函数在起作用。 * se->ops->save\_setup * se->ops->save\_live\_pending * se->ops->save\_live\_iterate * se->ops->save\_live\_complete\_precopy 那对应到内存，这个se就是savevm\_ram\_handlers，其对应的函数们就是 * ram\_save\_setup * ram\_save\_pending * ram\_save\_iterate * ram\_save\_complete 虽然里面做了很多事儿，也有很多细节上的优化，不过总的流程可以总结成两句话： * 用bitmap跟踪脏页 * 将脏页传送到对端 ### 接收流程 看完了发送，还得来看看接收。同样，看具体内存之前，先看一看总体架构。 ``` qemu_loadvm_state() qemu_get_be32, QEMU_VM_FILE_MAGIC qemu_get_be32, QEMU_VM_FILE_VERSION qemu_loadvm_state_setup se->ops->load_setup vmstate_load_state(f, &vmstate_configuration, &savevm_state, 0) cpu_synchronize_all_pre_loadvm cpu_synchronize_pre_loadvm(cpu) qemu_loadvm_state_main section_type = qemu_get_byte(f) QEMU_VM_SECTION_START | QEMU_VM_SECTION_FULL qemu_loadvm_section_start_full section_id = qemu_get_be32 vmstate_load QEMU_VM_SECTION_PART | QEMU_VM_SECTION_END qemu_loadvm_section_part_end section_id = qemu_get_be32 vmstate_load QEMU_VM_COMMAND loadvm_process_command QEMU_VM_EOF qemu_loadvm_state_cleanup se->ops->load_cleanup cpu_synchronize_all_post_init cpu_synchronize_post_init(cpu); ``` 进一步打开，我们可以看到有这么几个重要的函数。 * se->ops->load\_setup * se->ops->load\_state 对应到内存，分别是 * ram\_load\_setup * ram\_load ## 发送接收对应关系 ``` source destination +------------------------+ +-------------------------+ | | | | SETUP | ram_save_setup | | ram_load_setup | | | | | +------------------------+ +-------------------------+ sync dirty bit to Setup RAMBlock->receivedmap RAMBlock->bmap +------------------------+ +-------------------------+ | | | | ITER | ram_save_pending | | ram_load | | ram_save_iterate | | | | | | | +------------------------+ +-------------------------+ sync dirty bit Receive page and send page +------------------------+ +-------------------------+ | | | | COMP | ram_save_pending | | ram_load | | ram_save_complete | | | | | | | +------------------------+ +-------------------------+ sync dirty bit Receive page and send page ``` ## 脏页同步 在整个内存迁移的过程中脏页同步是重中之重了，这一小节我们来看看qemu是如何获得这一段时间中的虚拟机脏页的。 ### 代码流程 qemu发起获得脏页的地方有几处，比如每次迭代开始，或者最后要结束的时候。这个动作都通过统一的函数migration\_bitmap\_sync()。 ``` migration_bitmap_sync memory_global_dirty_log_sync (1) memory_region_sync_dirty_bitmap(NULL); listener->log_sync(listener, &mrs) -> kvm_log_sync kvm_physical_sync_dirty_bitmap migration_bitmap_sync_range; called on each RAMBlock cpu_physical_memory_sync_dirty_bitmap (2) ``` 其中主要工作分成两步： * 通过KVM\_GET\_DIRTY\_LOG获得脏页到kvm\_dirty\_log.dirty\_bitmap，并复制到ram\_list.dirty\_memory * 再将ram\_list.dirty\_memory的脏页拷贝到RAMBlock->bmap 至于KVM\_GET\_DIRTY\_LOG是怎么得到的脏页这个要看kvm的代码，其中一部分的功劳在vmx\_flush\_pml\_buffer()。 ### 相关数据结构 在内存迁移过程中重要的数据结构就是跟踪脏页的bitmap了。 其中一共用到了两个bitmap： * RAMBlock->bmap * ram\_list.dirty\_memory\[DIRTY\_MEMORY\_MIGRATION] 如果要画一个图来解释的画，那么这个可能会像一点。 ``` ram_list.dirty_memory[] +----------------------+---------------+--------------+----------------+ | | | | | +----------------------+---------------+--------------+----------------+ ^ ^ ^ ^ | | | | RAMBlock.bmap RAMBlock.bmap +----------------------+ +--------------+ | | | | +----------------------+ +--------------+ ``` ram\_list.dirty\_memroy\[]是一整个虚拟机地址空间的bitmap。虽然虚拟机的地址空间可能有空洞，但是这个bitmap是连续的。 RAMBlock.bmap是每个RAMBlock表示的地址空间的bitmap。 所以同步的时候分成两步： * 虚拟机对内存发生读写时会更新ram\_list.dirty\_memroy\[] * 每次内存迁移迭代开始，将ram\_list.dirty\_memory\[]更新到RAMBlock.bmap 这样两个bitmap各司其职可以同步进行。 ## 进化 理解了总体的流程和重要的数据结构，我们来看看内存迁移部分是如何进化的。如何从最开始的找到脏页迁移脏页，变成现在这么复杂的逻辑的。 ### 零页 迁移的时候，如果知道这个页面的内容都是0，那么从信息的角度看，其实信息量很小。那是不是有更好的方法去传送这些信息呢？ 函数save\_zero\_page\_to\_file()，就做了这件事。如果这个页面是零页，我们只传送一些标示符号。 ### 压缩 这个想法也比较直接，就是在传送前先压缩一下。这个工作交给了do\_compress\_ram\_page()。 ### 多线程 这也是一个比较直观的想法，一个人干活慢，那就多叫几个人。多线程的设置在compress\_threads\_save\_setup()。 ### Free Page 这个想法相对来说就比较隐晦了。意思是系统中总有部分的内存没有使用是free的，那么这些内存在最开始的时候就没有必要传送。（默认第一遍是都传送的。） 当然要做到这点，需要在虚拟机中有一个内应。当前这个内应是virtio-balloon。在启动虚拟机时需要加上参数。 ``` -object iothread,id=iothread1 --device virtio-balloon,free-page-hint=true,iothread=iothread1 ``` ### multifd 接下来这个东西略微有点复杂。也不知道为什么名字叫multifd，好像很有来头的样子。那就先来看看其中重要的数据结构。 第一个叫multifd\_send\_state。这个结构在函数multifd\_save\_setup中初始化。样子大概长这样。 ``` multifd_send_state +-------------------------------+ |packet_num | global | (uint64_t) | |sem_sync | |channels_ready | | (QemuSemaphore) | | | |pages | | (MultiFDPages_t*) | | | |params | [migrate_multifd_channels()] each channel has one MultiFDSendParams | (MultiFDSendParams*) | | | MultiFDSendParams MultiFDSendParams MultiFDSendParams +-------------------------------+ +-------------------+ +-------------------+ +-------------------+ |name | |name | |name | | multifdsend_0 | | multifdsend_1 | | multifdsend_2 | |pages | |pages | |pages | | (MultiFDPages_t*) | | (MultiFDPages_t*) | | (MultiFDPages_t*) | |packet | |packet | |packet | | (MultiFDPacket_t*)| | (MultiFDPacket_t*)| | (MultiFDPacket_t*)| | | | | | | | | | | | | +-------------------+ +-------------------+ +-------------------+ ``` 几点说明： * multifd是一个多线程的结构，一共有migrate\_multifd\_channels个线程，这个可以通过参数设置 * 所以也很好理解的是对应有migrate\_multifd\_channels()个params，每个线程人手一个不要打架 * 每个params中重要的两个成员是pages/packet，packet相当于控制信息，pages就是数据 接着我们来看看page和packet的样子。 ``` pages (MultiFDPages_t*) +----------------------+ |packet_num | global | (uint64_t) | |block | | (RAMBlock*) | |allocated | |used | | (uint32_t) | |offset | [allocated] | (ram_addr_t) | |iov | [allocated] | (struct iovec*) | | +------------------+ | |iov_base | = block->host + offset | |iov_len | = TARGET_PAGE_SIZE | +------------------+ | | +----------------------+ ``` 看到这个大家或许能够明白一点，page其实是一个iov的集合。一共分配有allocated个iov的结构，用于发送数据。不过要注意的一点是，发送的所有数据都属于同一个RAMBlock。 ``` packet (MultiFDPacket_t*) +----------------------+ |magic | = MULTIFD_MAGIC |version | = MULTIFD_VERSION |flags | = params->flags | | |pages_alloc | = page_count |pages_used | = pages->used |next_packet_size | = params->next_packet_size |packet_num | = params->packet_num | | |offset[] | [page_count] | (ram_addr_t) | +----------------------+ ``` 这个相当于每次发送时的元数据了。而且因为iov的传送只有base/len，所以这里还要传送在RAMBlock中的offset。 ### xbzrle 这个东西也很高端，全称叫 [XOR Based Zero run lenght encoding](https://github.com/qemu/qemu/blob/master/docs/xbzrle.txt). 其中使用到的编码是[LEB128](https://en.wikipedia.org/wiki/LEB128). 这个东西很有意思，说起来其实也简单。 **不直接传送每个页的内容，而是传送每个页的差值** 怎么样，是不是很有意思？好了，这个思想的所有内容就这么写，其他的就剩下具体的实现细节了。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://richardweiyang-2.gitbook.io/understanding_qemu/00-lm/04-ram_migration.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.