qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 7/10] Switch the memory savevm handler to be "live"
Date: Wed, 10 Sep 2008 10:17:33 +0300
User-agent: Thunderbird 2.0.0.16 (X11/20080723)

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]