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: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 7/10] Switch the memory savevm handler to be "live"
Date: Wed, 10 Sep 2008 08:10:05 -0500
User-agent: Thunderbird 2.0.0.16 (X11/20080723)

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.






reply via email to

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