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

[Richard W.M. Jones]

[This time without the massive attachment]

On Thu, Mar 31, 2016 at 12:22:23PM -0400, Kevin O'Connor wrote:
> On Thu, Mar 31, 2016 at 10:21:25AM +0100, Stefan Hajnoczi wrote:
> > On Sat, Mar 19, 2016 at 08:31:24PM +0000, Richard W.M. Jones wrote:
> > > Is there something I'm missing, or for Linux + -kernel could we use a
> > > much simpler BIOS?
> > 
> > The data that Marc Mari collected when comparing qboot with an optimized
> > SeaBIOS/QEMU showed that there's no need for a separate "lightweight
> > firmware" codebase.

[http://www.seabios.org/pipermail/seabios/2015-July/009554.html]

The problem is that now we've solved the fw_cfg problem, SeaBIOS is
again a bottleneck (but one of several, and not the biggest).

> > https://github.com/bonzini/qboot

I'm actually comparing this to the extremely minimal BIOS used by
kvmtool (and hence by Intel Clear Containers).  That "BIOS" (it's
hardly fair to call it that) contains only a the bare minimum calls
necessary to service the Linux startup code.  In this scenario Linux
is memcpy'd into the guest memory and jumped to directly, so there is
no separate BIOS loading step at all.  The BIOS is only needed because
Linux startup issues BIOS calls eg to get the e820 memory map and do
some VGA mode manipulation.

https://git.kernel.org/cgit/linux/kernel/git/will/kvmtool.git/tree/x86

BTW my target for the total time taken to go from the qemu command to
a guest shell prompt is 150 ms.  Intel Clear Containers can do this
already, albeit using kvmtool and a heavily patched kernel with a
minimal config.

> > It would create a maintenance burden and eventually we'd want many of
> > the SeaBIOS features anyway.  It's better to optimize linuxboot.bin and
> > SeaBIOS instead.
> 
> In the tests I've run, the time spent in SeaBIOS is dominated by
> hardware delays.  (Or for qemu, the time needed for seabios to
> communicate with virtual hardware and the time required for qemu to
> implement the requests.)  As such, boot times can be most easily
> improved by configuring the VM with less hardware, or configuring (via
> SeaBIOS kconfig) less hardware drivers in SeaBIOS.
>
> It's possible to do course grained profiling with SeaBIOS by timing
> its debug messages - see:
> http://www.seabios.org/Debugging#Timing_debug_messages

This is roughly what I've been doing.  I'm using my own test harness:

https://github.com/libguestfs/libguestfs/blob/master/tests/qemu/boot-analysis.c
https://github.com/libguestfs/libguestfs/blob/master/tests/qemu/boot-analysis-timeline.c

The output from this is here (note: download it and use `less -r' to
view it):

http://oirase.annexia.org/tmp/seabios.txt

Actual total boot time is about 1s now.  The attached file
takes longer for a couple of reasons:

 - SeaBIOS debugging is enabled

 - kernel initcall debugging is enabled

I'd dearly love to get rid of the sgabios option ROM.  It looks like
SeaBIOS nearly supports a full serial console now?

> The debug messages themselves can consume time though (one can
> eliminate debug messages using CONFIG_DEBUG_LEVEL=0).  I use the
> following to profile while also accounting for the debug message delay
> (on my system, each debug character takes ~2.5us):
> 
> scripts/readserial.py -f ../qemu-test/qemudebugpipe -t 2.5
> 
> I find a standard SeaBIOS build on my machine with KVM takes ~50ms to
> start the OS (not including OS load time).  This breaks down roughly
> to the following times:
> 
> 6ms  - enabling shadow ram (qemu makes 0xc0000-0x100000 read/writable)
> 4ms  - PCI initialization
> 2ms  - smm init
> 4ms  - load acpi tables from qemu
> 16ms - init and enable vga console
> 5ms  - load and run various option roms from qemu (eg, ipxe)
> 7ms  - locking shadow ram (qemu makes 0xc0000-0x100000 readonly)
> 6ms  - other
> 
> There are several SeaBIOS kconfig options that would remove many of
> the above delays (with the obvious caveat that the given hardware
> would no longer be initialized by seabios).
> 
> > Kevin O'Connor had some SeaBIOS optimizations that improved boot time by
> > skipping unnecessary probing and timer calibration IIRC.  I have CCed
> > Marc and Kevin on this email.
> 
> There were a couple of optimizations in SeaBIOS (avoid TSC calibration
> when not using the TSC, avoid a PS2 keyboard reset delay) found last
> year, but they were committed and released in SeaBIOS v1.9.0.  They
> should already be in QEMU.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v