Re: [Qemu-devel] [PATCH 7/10] Switch the memory savevm handler to be "live"

Anthony Liguori
2008-09-10T13:11:09Z

Avi Kivity wrote:
> Anthony Liguori wrote:
>> This patch replaces the static memory savevm/loadvm handler with a
>> "live" one.
>> This handler is used even if performing a non-live migration.
>>
>> The key difference between this handler and the previous is that each
>> page is
>> prefixed with the address of the page. The QEMUFile rate limiting
>> code, in
>> combination with the live migration dirty tracking bits, is used to
>> determine
>> which pages should be sent and how many should be sent.
>>
>> The live save code "converges" when the number of dirty pages reaches
>> a fixed
>> amount. Currently, this is 10 pages. This is something that should
>> eventually
>> be derived from whatever the bandwidth limitation is.
>>
>> +
>> +static int ram_save_block(QEMUFile *f)
>> +{
>> + static ram_addr_t current_addr = 0;
>> + ram_addr_t saved_addr = current_addr;
>> + ram_addr_t addr = 0;
>> + int found = 0;
>> +
>> + while (addr < phys_ram_size) {
>> + if (cpu_physical_memory_get_dirty(current_addr,
>> MIGRATION_DIRTY_FLAG)) {
>> + uint8_t ch;
>> +
>> + cpu_physical_memory_reset_dirty(current_addr,
>> + current_addr +
>> TARGET_PAGE_SIZE,
>> + MIGRATION_DIRTY_FLAG);
>> +
>> + ch = *(phys_ram_base + current_addr);
>>
>
> Looks like you're using qemu ram addresses. The problem with these is
> that they have no stable meaning. Switching the initialization order
> of vga and memory would break compatibility.

This is true, but keep in mind, the current save/restore code saves the
whole chunk of qemu ram. So switching the initialization order of vga
and memory would currently break save/restore compatibility.

I agree we should try to solve this.

Regards,

Anthony Liguori

> We should separate RAM saving according to the owners of the RAM
> blocks. For example vga would be responsible for moving the
> framebuffer (which has no stable hardware address, either), and
> something else would be responsible for migrating RAM. Of course both
> would call into common code.
>