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

[Anthony Liguori <aliguori@us.ibm.com>]

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.
>