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

[Avi Kivity <avi@qumranet.com>]

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.

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.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.