From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:32977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdFLA-0003No-CS for qemu-devel@nongnu.org; Fri, 17 May 2013 03:44:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UdFL3-0004py-Ql for qemu-devel@nongnu.org; Fri, 17 May 2013 03:44:36 -0400 Received: from mail-ee0-f48.google.com ([74.125.83.48]:35118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdF3D-0000lg-NN for qemu-devel@nongnu.org; Fri, 17 May 2013 03:26:03 -0400 Received: by mail-ee0-f48.google.com with SMTP id b47so2367365eek.21 for ; Fri, 17 May 2013 00:26:03 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5195DB73.3030104@redhat.com> Date: Fri, 17 May 2013 09:25:39 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20130516173422.20571.91890.malonedeb@gac.canonical.com> <51953162.3000107@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Bug 1180923] [NEW] unused memory filled with 0x00 instead of 0xFF List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , TC1988 Cc: Stefan Hajnoczi , Bug 1180923 <1180923@bugs.launchpad.net>, qemu-devel Il 16/05/2013 22:00, Peter Maydell ha scritto: >> > Sounds like (risky) memory probing. On a PC the memory regions that >> > are unpopulated produce 0xff. > Presumably you could fix the PC model to do that by putting a big > background (overlappable) MemoryRegion across the whole of the > system address space which returned -1 for every access? On a modern PC, there is really no non-present memory region where UMBs used to be. Memory between 0xc0000 and 0x100000 will be mostly unused, but it is not mentioned in the firmware ("e820") memory map. For example on KVM the memory map is: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable [ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000007ffdfff] usable [ 0.000000] BIOS-e820: [mem 0x0000000007ffe000-0x0000000007ffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved but SeaBIOS says: Copying option rom (size 36352) from 0xfebc0000 to 0x000c0000 Copying option rom (size 65536) from 0xfebd0000 to 0x000c9000 Copying option rom (size 1024) from genroms/linuxboot.bin to 0x000ca000 Copying option rom (size 9216) from genroms/kvmvapic.bin to 0x000ca800 Space available for UMB: cd000-ee800, f0000-f1c20 So you can see it in three ways: 1) It's not a QEMU problem, but a firmware problem. You could initialize the UMBs with 0xFF in SeaBIOS for example. However, it is probably necessary to round the UMBs somehow, because emm386 probably probes memory with a larger granularity than 32 bytes. For example, in the case above you may want to leave 0x00 outside 0xD0000-0xEC000 (16kb granularity). You also need to ensure the UMBs are write-protected (I do not remember if that's already the case). 2) It's not a QEMU prablem, but an EMM386 problem. Simply, EMM386 does not support chipsets that have RAM at 0xc0000-0x100000. I found some information about a program called UMBPCI that you can use instead of EMM386. 3) It's a QEMU problem, but it should only work with "-M isapc". This would be similar to what Peter suggested, but it would give you very small UMBs (something like 0xD0000-0xE0000). To go beyond that you need to recompile SeaBIOS so that it fits in a 64kb ROM. It's probably possible to make it fit, but you may encounter SeaBIOS bugs because no one uses it with such a small ROM. Having a more useful ISA PC emulation in QEMU would be a nice project, but no one really has time for that among the most active developers. Paolo