From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? Date: Wed, 04 Aug 2010 09:50:55 -0500 Message-ID: <4C597E4F.2050108@codemonkey.ws> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Richard W.M. Jones" , Avi Kivity , Gerd Hoffmann , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mail-qy0-f174.google.com ([209.85.216.174]:65026 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932464Ab0HDOu7 (ORCPT ); Wed, 4 Aug 2010 10:50:59 -0400 Received: by qyk7 with SMTP id 7so1251412qyk.19 for ; Wed, 04 Aug 2010 07:50:59 -0700 (PDT) In-Reply-To: <20100804143842.GX10499@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. >