From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35051 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgfJ7-0001d6-4i for qemu-devel@nongnu.org; Wed, 04 Aug 2010 10:51:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgfJ5-00039A-Sc for qemu-devel@nongnu.org; Wed, 04 Aug 2010 10:51:00 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:57402) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgfJ5-000394-PF for qemu-devel@nongnu.org; Wed, 04 Aug 2010 10:50:59 -0400 Received: by qwf6 with SMTP id 6so1008048qwf.4 for ; Wed, 04 Aug 2010 07:50:59 -0700 (PDT) Message-ID: <4C597E4F.2050108@codemonkey.ws> Date: Wed, 04 Aug 2010 09:50:55 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? References: <4C588804.5060803@redhat.com> <4C590046.2020705@redhat.com> <4C591D48.9080301@redhat.com> <4C592218.3000901@redhat.com> <4C596549.1070109@codemonkey.ws> <20100804130709.GL10499@redhat.com> <4C5967D8.7080707@codemonkey.ws> <20100804132408.GG28523@amd.home.annexia.org> <20100804132625.GN10499@redhat.com> <4C59779E.3060000@codemonkey.ws> <20100804143842.GX10499@redhat.com> In-Reply-To: <20100804143842.GX10499@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel@nongnu.org, Gerd Hoffmann , "Richard W.M. Jones" , kvm@vger.kernel.org, Avi Kivity On 08/04/2010 09:38 AM, Gleb Natapov wrote: >> >> But even if it wasn't it can potentially create havoc. I think we >> currently believe that the northbridge likely never forwards RAM >> access to a device so this doesn't fit how hardware would work. >> >> > Good point. > > >> More importantly, BIOSes and ROMs do very funny things with RAM. >> It's not unusual for a ROM to muck with the e820 map to allocate RAM >> for itself which means there's always the chance that we're going to >> walk over RAM being used for something else. >> >> > ROM does not muck with the e820. It uses PMM to allocate memory and the > memory it gets is marked as reserved in e820 map. > PMM allocations are only valid during the init function's execution. It's intention is to enable the use of scratch memory to decompress or otherwise modify the ROM to shrink its size. If a ROM needs memory after the init function, it needs to use the traditional tricks to allocate long term memory and the most popular one is modifying the e820 tables. See src/arch/i386/firmware/pcbios/e820mangler.S in gPXE. Regards, Anthony Liguori > -- > Gleb. >