From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42432 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oggrl-0003GS-3c for qemu-devel@nongnu.org; Wed, 04 Aug 2010 12:30:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oggrk-0002fg-2n for qemu-devel@nongnu.org; Wed, 04 Aug 2010 12:30:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17699) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oggrj-0002fX-Of for qemu-devel@nongnu.org; Wed, 04 Aug 2010 12:30:52 -0400 Message-ID: <4C5995B4.90505@redhat.com> Date: Wed, 04 Aug 2010 19:30:44 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? References: <20100803190525.GB16570@redhat.com> <4C586AB9.5040302@codemonkey.ws> <4C586CF9.7030206@redhat.com> <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> <20100804133401.GP10499@redhat.com> <4C5970AC.6060105@codemonkey.ws> In-Reply-To: <4C5970AC.6060105@codemonkey.ws> 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: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Gerd Hoffmann , Gleb Natapov , "Richard W.M. Jones" On 08/04/2010 04:52 PM, Anthony Liguori wrote: >>> >> This is not like DMA event if done in chunks and chunks can be pretty >> big. The code that dials with copying may temporary unmap some pci >> devices to have more space there. > > > That's a bit complicated because SeaBIOS is managing the PCI devices > whereas the kernel code is running as an option rom. I don't know the > BIOS PCI interfaces well so I don't know how doable this is. > > Maybe we're just being too fancy here. > > We could rewrite -kernel/-append/-initrd to just generate a floppy > image in RAM, and just boot from floppy. How could this work? the RAM belongs to SeaBIOS immediately after reset, it would just scribble over it. Or worse, not scribble on it until some date in the future. -kernel data has to find its way to memory after the bios gives control to some optionrom. An alternative would be to embed knowledge of -kernel in seabios, but I don't think it's a good one. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.