From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54133 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OghjN-0003ik-CG for qemu-devel@nongnu.org; Wed, 04 Aug 2010 13:26:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OghjH-0002mz-3J for qemu-devel@nongnu.org; Wed, 04 Aug 2010 13:26:16 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:33941) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OghjH-0002mo-0G for qemu-devel@nongnu.org; Wed, 04 Aug 2010 13:26:11 -0400 Received: by qwf6 with SMTP id 6so1153216qwf.4 for ; Wed, 04 Aug 2010 10:26:10 -0700 (PDT) Message-ID: <4C59A2AE.2060602@codemonkey.ws> Date: Wed, 04 Aug 2010 12:26:06 -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> <721C3046-D6A7-47B2-A18C-4E59F2B68797@suse.de> In-Reply-To: <721C3046-D6A7-47B2-A18C-4E59F2B68797@suse.de> 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: Alexander Graf Cc: Gleb Natapov , kvm@vger.kernel.org, qemu-devel@nongnu.org, "Richard W.M. Jones" , Avi Kivity , Gerd Hoffmann On 08/04/2010 11:45 AM, Alexander Graf wrote: > Frankly, I partially agreed to your point when we were talking about 300ms vs. 2 seconds. Now that we're talking 8 seconds that whole point is moot. We chose the wrong interface to transfer kernel+initrd data into the guest. > > Now the question is how to fix that. I would veto against anything normally guest-OS-visible. By occupying the floppy, you lose a floppy drive in the guest. By occupying a disk, you see an unwanted disk in the guest. Introduce a new virtio device type (say, id 6). Teach SeaBIOS that 6 is exactly like virtio-blk (id 2). Make it clear that id 6 is only to be used by firmware and that normal guest drivers should not be written for id 6. Problem is now solved and everyone's happy. Now we can all go back to making slides for next week :-) Regards, Anthony Liguori > By taking virtio-serial you see an unwanted virtio-serial line in the guest. fw_cfg is great because it's a private interface nobody else accesses. > > I see two alternatives out of this mess: > > 1) Speed up string PIO so we're actually fast again. > 2) Using a different interface (that could also be DMA fw_cfg - remember, we're on a private interface anyways) > > Admittedly 1 would also help in more cases than just booting with -kernel and -initrd, but if that won't get us to acceptable levels (and yes, 8 seconds for 100MB is unacceptable) I don't see any way around 2. > > > Alex > >