From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60136 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ogh5A-0001GY-Ad for qemu-devel@nongnu.org; Wed, 04 Aug 2010 12:44:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ogh59-0004oN-1D for qemu-devel@nongnu.org; Wed, 04 Aug 2010 12:44:44 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:34581) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ogh58-0004oI-Tz for qemu-devel@nongnu.org; Wed, 04 Aug 2010 12:44:43 -0400 Received: by qwf6 with SMTP id 6so1116173qwf.4 for ; Wed, 04 Aug 2010 09:44:42 -0700 (PDT) Message-ID: <4C5998F1.4030001@codemonkey.ws> Date: Wed, 04 Aug 2010 11:44:33 -0500 From: Anthony Liguori 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> <4C5995B4.90505@redhat.com> <4C5996F4.6010205@redhat.com> In-Reply-To: <4C5996F4.6010205@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: Avi Kivity Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Gerd Hoffmann , Gleb Natapov , "Richard W.M. Jones" On 08/04/2010 11:36 AM, Avi Kivity wrote: > On 08/04/2010 07:30 PM, Avi Kivity wrote: >> 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. >> > > Oh, you meant host RAM, not guest RAM. Disregard. > > This is basically my suggestion to libguestfs: instead of generating > an initrd, generate a bootable cdrom, and boot from that. The result > is faster and has a smaller memory footprint. Everyone wins. Yeah, but we could also do that entirely in QEMU. If that's what we suggest doing, there's no reason not to do it instead of the option rom trickery that we do today. The option rom stuff has a number of short comings. Because we hijack int19, extboot doesn't get to run. That means that if you use -kernel to load a grub (the Ubuntu guys for their own absurd reasons) then grub does not see extboot backed disks. The solution for them is the same, generate a proper disk and boot from that disk. Regards, Anthony Liguori