From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51255 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oajcu-0006x0-9Q for qemu-devel@nongnu.org; Mon, 19 Jul 2010 02:14:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oajcq-0000qZ-6N for qemu-devel@nongnu.org; Mon, 19 Jul 2010 02:14:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42769) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oajcp-0000qQ-Ux for qemu-devel@nongnu.org; Mon, 19 Jul 2010 02:14:52 -0400 Date: Mon, 19 Jul 2010 09:14:49 +0300 From: Gleb Natapov Message-ID: <20100719061449.GT4689@redhat.com> References: <20100717095059.GA19767@amd.home.annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100717095059.GA19767@amd.home.annexia.org> Subject: [Qemu-devel] Re: Question about qemu firmware configuration (fw_cfg) device List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" Cc: qemu-devel@nongnu.org, agraf@suse.de On Sat, Jul 17, 2010 at 10:50:59AM +0100, Richard W.M. Jones wrote: > I'm trying to speed up the process of loading kernel and initrd. > > I found that the main loop which loads these into qemu memory does it > via executing in the guest: > > rep insb (%dx),%es:(%edi) > > In other words, reading it byte-at-a-time from an emulated IO port. > This is very slow[1] when your initrd is > 100MB like mine is. > > Questions: > > Is fw_cfg a purely qemu concept? Does this BIOS firmware port > 0x510-0x511 exist in real hardware? > It is purely qemu concept. > I understand from the git logs that fw_cfg was added because the old > way was to load kernel & initrd into RAM directly, but this didn't > work because SeaBIOS would clear the RAM, clobbering kernel & initrd. > Could we change to loading these directly into RAM, and instead > provide some indication to SeaBIOS so it doesn't clobber the RAM? I'm > quite prepared to do the work, just wondering if there's something > else I'm not getting about this. > > Rich. > > [1] Several seconds of wallclock time, and according to gprof, the > function 'fw_cfg_io_readb' accounts for > 50% of the time taken in > qemu between qemu starting and us entering the Linux kernel. > Several seconds is not too bad for 100M. Have you tested how much insl improves this? -- Gleb.