From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35081 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OgNJl-0004CM-V1 for qemu-devel@nongnu.org; Tue, 03 Aug 2010 15:38:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OgNJj-0000vz-2x for qemu-devel@nongnu.org; Tue, 03 Aug 2010 15:38:28 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:63413) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OgNJj-0000vq-0t for qemu-devel@nongnu.org; Tue, 03 Aug 2010 15:38:27 -0400 Received: by qyk31 with SMTP id 31so1503578qyk.4 for ; Tue, 03 Aug 2010 12:38:26 -0700 (PDT) Message-ID: <4C58702D.10406@codemonkey.ws> Date: Tue, 03 Aug 2010 14:38:21 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35? References: <20100803162857.GX13789@amd.home.annexia.org> <4C584781.9040609@redhat.com> <4C5847CD.9080107@codemonkey.ws> <4C5848C7.3090806@redhat.com> <4C584982.5000108@codemonkey.ws> <4C584B66.5070404@redhat.com> <4C5854F1.3000905@codemonkey.ws> <4C5858B2.9090801@redhat.com> <4C585F5B.5070502@codemonkey.ws> <4C58635B.7020407@redhat.com> <20100803190525.GB16570@redhat.com> <4C586AB9.5040302@codemonkey.ws> <4C586CF9.7030206@redhat.com> In-Reply-To: <4C586CF9.7030206@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: kvm@vger.kernel.org, "Richard W.M. Jones" , Gleb Natapov , qemu-devel@nongnu.org On 08/03/2010 02:24 PM, Avi Kivity wrote: > On 08/03/2010 10:15 PM, Anthony Liguori wrote: >> >> fw_cfg has to be available pretty early on so relying on a PCI device >> isn't reasonable. Having dual interfaces seems wasteful. > > Agree. > >> >> We're already doing bulk data transfer over fw_cfg as we need to do >> it to transfer roms and potentially a boot splash. > > Why do we need to transfer roms? These are devices on the memory bus > or pci bus, it just needs to be there at the right address. Not quite. The BIOS owns the option ROM space. The way it works on bare metal is that the PCI ROM BAR gets mapped to some location in physical memory by the BIOS, the BIOS executes the initialization vector, and after initialization, the ROM will reorganize itself into something smaller. It's nice and clean. But ISA is not nearly as clean. Ultimately, to make this mix work in a reasonable way, we have to provide a side channel interface to SeaBIOS such that we can deliver ROMs outside of PCI and still let SeaBIOS decide how ROMs get organized. It's additionally complicated by the fact that we didn't support PCI ROM BAR until recently so to maintain compatibility with -M older, we have to use a side channel to lay out option roms. Regards, Anthony Liguori > Boot splash should just be another rom as it would be on a real system. > >> Even outside of loading an initrd, the performance is going to start >> to matter with a large number of devices. > > I don't really see why. >