From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9KB0-0006HR-HC for qemu-devel@nongnu.org; Tue, 13 Aug 2013 15:22:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9KAu-0001a6-OC for qemu-devel@nongnu.org; Tue, 13 Aug 2013 15:22:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9KAu-0001Zw-Fu for qemu-devel@nongnu.org; Tue, 13 Aug 2013 15:22:36 -0400 Message-ID: <520A880C.8010803@redhat.com> Date: Tue, 13 Aug 2013 21:25:00 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <520A58CD.9000404@suse.de> <520A641F.5040608@redhat.com> <520A65BD.3030408@redhat.com> <520A75CE.6020600@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QEMU savevm RAM page offsets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juerg Haefliger Cc: Paolo Bonzini , Michael Tokarev , =?ISO-8859-1?Q?Andreas_F=E4rbe?= =?ISO-8859-1?Q?r?= , qemu-devel@nongnu.org On 08/13/13 21:06, Juerg Haefliger wrote: > On Tue, Aug 13, 2013 at 8:07 PM, Paolo Bonzini wrote: >> Il 13/08/2013 19:52, Juerg Haefliger ha scritto: >>> I didn't mean to imply that the savevm format is broken and needed >>> fixing. I was just wondering if the data is there and I simply hadn't >>> found it. Upgrading QEMU is not an option at the moment since these >>> are tightly controlled productions machines. Is it possible to loadvm >>> a savevm file from 1.0 with 1.6 to then use guest-memory-dump? >> >> Yes, it should, but one important thing since 1.0 has been the merger of >> qemu-kvm and QEMU. What distribution are you using? I know Fedora >> allows qemu-kvm-1.0 to QEMU-1.6 compatibility, but I don't know about >> others. > > Ubuntu 12.04 > > >> Michael Tokarev is the maintainer of the Debian package, so he may be >> able to answer. >> >> Alternatively, you can modify your utility to simply add 512 MB to the >> addresses above 3.5 GB. > > Is it really as simple as that? Isn't the OS (particularly Windows) > possibly doing some crazy remapping that needs to be taken into > account? meminfo on a VM with 4GB running Windows 2008 shows the > following: > > C:\Users\Administrator\Desktop\MemInfo\amd64>MemInfo.exe -r > MemInfo v2.10 - Show PFN database information > Copyright (C) 2007-2009 Alex Ionescu > www.alex-ionescu.com > > Physical Memory Range: 0000000000001000 to 000000000009B000 (154 pages, 616 KB) > Physical Memory Range: 0000000000100000 to 00000000DFFFD000 (917245 > pages, 3668980 KB) > Physical Memory Range: 0000000100000000 to 0000000120000000 (131072 > pages, 524288 KB) > MmHighestPhysicalPage: 1179648 That should be fine, I think. The 384 KB hole between 640KB and 1MB is actually contiguously backed by RAMBlock, it is just not (necessarily) presented as conventional memory to the guest. You can treat the [0, 0x0e0000000) left-closed, right-open interval as contiguous. Again, check out the diagram in 4/4 that I linked before. Compare it to pc_init1() in "hw/pc_piix.c", at tag "v1.0" in . Look for the variable "below_4g_mem_size". Laszlo