Re: [Qemu-devel] Slow kernel/initrd loading via fw_cfg; Was Re: Hack integrating SeaBios / LinuxBoot option rom with QEMU trace backends

[Avi Kivity]

On 10/11/2011 11:27 AM, Daniel P. Berrange wrote:
> >
> >  One thing we can do is boot a guest and immediately snapshot it,
> >  before it runs any application specific code.  Subsequent
> >  invocations will MAP_PRIVATE the memory image and COW their way.
> >  This avoids the kernel initialization time as well.
>
> This is adding an awful lot of complexity to the process, just
> to avoid fixing a performance problem in QEMU.

The performance problem is in the host kernel, not qemu, and I'm 
certainly not against fixing it.  I'm trying to see if we can optimize 
it even further to make it instantaneous.

>   You can't even
> reliably snapshot in between the time of booting the kerenl and
> running the app code, without having to write some kind of handshake
> betwen guest&  the host app. You now also have the problem of
> figuring out when the snapshot has become invalid due to host OS
> software updates, which I explicitly wanted to avoid by *always*
> running the current software directly.

Sure, it adds complexity, but the improvement may be worth it.

> >  >For comparison I also did a test building a bootable ISO using ISOLinux.
> >  >This required 700 ms for the boot time, which is appoximately 1/2 the
> >  >time reqiured for direct kernel/initrd boot. But you have to then add
> >  >on time required to build the ISO on every boot, to add custom kernel
> >  >command line args. So while ISO is faster than LinuxBoot currently
> >  >there is still non-negligable overhead here that I want to avoid.
> >
> >  You can accept parameters from virtio-serial or some other channel.
> >  Is there any reason you need them specifically as *kernel* command
> >  line parameters?
>
> Well some of the parameters are actually kernel parameters :-) The rest
> are things I pass to the 'init' process which runs in the initrd. When
> this process first starts the only things it can easily access are those
> builtin to the kernel image, so data available from /proc or /sys like
> the /proc/cmdline file. It hasn't even loaded things like the virtio-serial
> or virtio-9pfs kernel modules at this point.

It could, if it wanted to.  It's completely custom, yes?

--
error compiling committee.c: too many arguments to function