Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device

[Alexander Graf]

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