From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VADGt-0002pm-E6 for qemu-devel@nongnu.org; Fri, 16 Aug 2013 02:12:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VADGm-0003O9-BF for qemu-devel@nongnu.org; Fri, 16 Aug 2013 02:12:27 -0400 Received: from mail-wg0-x230.google.com ([2a00:1450:400c:c00::230]:57716) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VADGm-0003O0-5c for qemu-devel@nongnu.org; Fri, 16 Aug 2013 02:12:20 -0400 Received: by mail-wg0-f48.google.com with SMTP id f12so1238289wgh.27 for ; Thu, 15 Aug 2013 23:12:19 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <520A880C.8010803@redhat.com> References: <520A58CD.9000404@suse.de> <520A641F.5040608@redhat.com> <520A65BD.3030408@redhat.com> <520A75CE.6020600@redhat.com> <520A880C.8010803@redhat.com> Date: Fri, 16 Aug 2013 08:12:19 +0200 Message-ID: From: Juerg Haefliger Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] QEMU savevm RAM page offsets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Paolo Bonzini , Michael Tokarev , =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-devel@nongnu.org >>>> 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. Indeed simply adding a 512 MB hole between 3.5 GB and 4 GB did the trick. Thanks a lot. > 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". Nice diagram and very helpful. Thanks ...Juerg > Laszlo