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. Alex
