From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59802 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oajlh-0000yU-6L for qemu-devel@nongnu.org; Mon, 19 Jul 2010 02:24:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oajlg-0002OT-1y for qemu-devel@nongnu.org; Mon, 19 Jul 2010 02:24:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12834) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oajlf-0002OI-PP for qemu-devel@nongnu.org; Mon, 19 Jul 2010 02:24:00 -0400 Date: Mon, 19 Jul 2010 09:23:56 +0300 From: Gleb Natapov Subject: Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device Message-ID: <20100719062356.GU4689@redhat.com> References: <20100717095059.GA19767@amd.home.annexia.org> <20100717095353.GB19767@amd.home.annexia.org> <269D196D-8CE8-4E24-8EE1-39756AC55F7F@suse.de> <20100718200942.GL13194@amd.home.annexia.org> <44FD4F00-843D-41C8-B21A-148D16745015@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44FD4F00-843D-41C8-B21A-148D16745015@suse.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "Richard W.M.Jones" , qemu-devel@nongnu.org On Sun, Jul 18, 2010 at 10:32:53PM +0200, Alexander Graf wrote: > > On 18.07.2010, at 22:09, Richard W.M. Jones wrote: > > > On Sun, Jul 18, 2010 at 07:26:57PM +0200, Alexander Graf wrote: > >> On 17.07.2010, at 11:53, Richard W.M. Jones wrote: > >>> On Sat, Jul 17, 2010 at 10:50:59AM +0100, Richard W.M. Jones wrote: > >>>> 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. > >>> > >>> Or thinking around the subject: > >>> > >>> Change fw_cfg so that you send a command + a physical address, and > >>> fw_cfg memcpy's the kernel / initrd / etc to that physical address. > >>> Then linuxboot.bin doesn't have to do the manual copying. > >>> > >>> Or just change linuxboot.bin so it does 32 bit inl instructions, which > >>> might at least be a bit faster ... > >> > >> I don't see why it would be slow. ins should be emulated using coalesced mmio, no? > > > > It knocks 1 second off libguestfs boot times on my faster 64 bit > > desktop machine, and 2 seconds off with my old 32 bit laptop. > > (Roughly 15% faster in both cases) > > > > The 64 bit machine times are: > > > > Without my patch: > > > > real 0m7.581s > > user 0m4.730s > > sys 0m2.124s > > > > With my patch: > > > > real 0m6.579s > > user 0m3.614s > > sys 0m1.941s > > > > If you want to reproduce this (you'll need a recent Fedora machine) > > you can do: > > > > $ cat qemu-wrapper > > #!/bin/sh - > > qemudir=/home/rjones/d/qemu > > exec $qemudir/x86_64-softmmu/qemu-system-x86_64 -L $qemudir/pc-bios "$@" > > > > $ export LIBGUESTFS_QEMU=/home/rjones/d/qemu/qemu-wrapper > > $ time guestfish --ro -a /dev/null run > > > > Obviously I'm running that several times over, discarding the first > > few runs, because I'm only interested in the "hot cache" case. > > > > By the way, even if you reject the patch as a whole, part 1/2 of the > > patch is just an obvious bug fix, and I think should be applied > > anyway. > > > > http://lists.gnu.org/archive/html/qemu-devel/2010-07/threads.html#00967 > > I haven't rejected anything yet - in general I like the idea of DMA'ing fw_cfg variables. I guess since it's basically an ISA PV device, we also don't need to care about bus mastering or anything, right? Or do we? Hrm. > That what I am warring about too. If we are adding device we have to be sure such device can actually exist on real hw too otherwise we may have problems later. Also 1 second on 100M file does not look like huge gain to me. -- Gleb.