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

[Gleb Natapov <gleb@redhat.com>]

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.