From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <48C7C72D.4090704@us.ibm.com> References: <1220989802-13706-1-git-send-email-aliguori@us.ibm.com> <1220989802-13706-8-git-send-email-aliguori@us.ibm.com> <48C7748D.6070600@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Chris Wright , Uri Lublin , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from e2.ny.us.ibm.com ([32.97.182.142]:39490 "EHLO e2.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752564AbYIJNLJ (ORCPT ); Wed, 10 Sep 2008 09:11:09 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8ADB1cC009063 for ; Wed, 10 Sep 2008 09:11:01 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8ADB0Fw228650 for ; Wed, 10 Sep 2008 09:11:00 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8ADB0gs007735 for ; Wed, 10 Sep 2008 09:11:00 -0400 In-Reply-To: <48C7748D.6070600@qumranet.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. >