qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Why is SeaBIOS used with -kernel?


From: Kevin O'Connor
Subject: Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
Date: Fri, 1 Apr 2016 11:35:40 -0400
User-agent: Mutt/1.5.24 (2015-08-30)

On Fri, Apr 01, 2016 at 12:49:47PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 01:32:51PM +0200, Gerd Hoffmann wrote:
> > > I think we were working on the same thing ...  Attached is my
> > > version.
> > > 
> > > Note that you must enable at least CONFIG_MPTABLE else virtio-scsi
> > > does not work in the guest.  I also enabled ACPI & SMBIOS & PIRTABLE.
> > 
> > They are enabled by default, no need to explicitly say so ;)
> 
> So they are.  Here's a v3 patch.
> 
> I also retested everything from scratch.  Previously I was testing the
> stock SeaBIOS bios.bin shipped with qemu vs the fast config.  However
> that has the possible problem that I was testing two slightly
> different versions of SeaBIOS (whatever version qemu ships vs
> upstream).
> 
> Testing from scratch, using upstream SeaBIOS in both cases, there's
> still a significant benefit.  SeaBIOS overhead goes from 63 ms down to
> 19 ms (saving 44 ms).
> 
> Overall the proportion of boot time of the libguestfs appliance
> attributed to SeaBIOS drops from 3.7% to 1.1% (but note this is with
> libguestfs & kernel debugging enabled -- for real users there'd be a
> much larger percentage drop).
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html

> From 8cdf91f13949ab46c6a5804b968400d404c4e00e Mon Sep 17 00:00:00 2001
> From: "Richard W.M. Jones" <address@hidden>
> Date: Fri, 1 Apr 2016 11:35:09 +0100
> Subject: [PATCH] bios: Add fast variant of SeaBIOS for use with -kernel on
>  x86.
> 
> This commit adds a fast variant of SeaBIOS called 'bios-fast.bin'.
> 
> It's designed to be the fastest (also the smallest, but that's not the
> main aim) SeaBIOS that is just enough to boot a Linux kernel using the
> -kernel option on i686 and x86_64.
> 
> This commit does not modify the -kernel option to use this.  You have
> to specify it by doing something like this:
> 
>   -kernel vmlinuz -bios bios-fast.bin

It's possible to build a third binary, but that seems like it would be
a bit annoying for distributions.  I think most of the benefit could
be obtained by just adding a flag to seabios to have it skip device
driver initialization.  That's where the majority of the time saved is
from.

[...]
> --- /dev/null
> +++ b/roms/config.seabios-fast
> @@ -0,0 +1,25 @@
> +# The fastest SeaBIOS that can boot Linux using -kernel.
> +
> +# general stuff
> +CONFIG_QEMU=y
> +CONFIG_ROM_SIZE=128

Why force a size of 128K - I would think 64K would be fine.

> +CONFIG_XEN=n
> +CONFIG_THREADS=n

I doubt either of these two would change timing at all.  There's no
harm in disabling CONFIG_XEN, but I would not recommend disabling
CONFIG_THREADS.

> +CONFIG_WRITABLE_UPPERMEMORY=y
> +
> +# no input, no boot menu
> +CONFIG_MOUSE=n
> +CONFIG_KEYBOARD=n
[...]
> +CONFIG_DRIVES=n

I would not recommended disabling CONFIG_MOUSE, CONFIG_KEYBOARD,
CONFIG_DRIVES - I only had those in my config so as to avoid having to
specify all the device drivers.  Ideally these would remain on and the
individual device drivers would be disabled.

> +CONFIG_BOOTMENU=n
> +CONFIG_BOOTSPLASH=n

These two should have no impact on timing at all.

> +
> +# hardware support we don't need
> +CONFIG_LPT=n
> +CONFIG_SERIAL=n
> +CONFIG_USB=n
[...]
> +CONFIG_TCGBIOS=n
> +CONFIG_VGAHOOKS=n
> +
> +# no logging
> +CONFIG_DEBUG_LEVEL=0

If you really want to go all out on timing tests, you could disable
CONFIG_USE_SMM, and CONFIG_FW_ROMFILE_LOAD.  Disabling
CONFIG_RELOCATE_INIT may help, but probably not.

-Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]