Re: [Qemu-devel] Announcing qboot, a minimal x86 firmware for QEMU

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2015-05-21 15:51, Paolo Bonzini wrote:
> Some of you may have heard about the "Clear Containers" initiative from
> Intel, which couple KVM with various kernel tricks to create extremely
> lightweight virtual machines.  The experimental Clear Containers setup
> requires only 18-20 MB to launch a virtual machine, and needs about 60
> ms to boot.
> 
> Now, as all of you probably know, "QEMU is great for running Windows or
> legacy Linux guests, but that flexibility comes at a hefty price. Not
> only does all of the emulation consume memory, it also requires some
> form of low-level firmware in the guest as well. All of this adds quite
> a bit to virtual-machine startup times (500 to 700 milliseconds is not
> unusual)".
> 
> Right?  In fact, it's for this reason that Clear Containers uses kvmtool
> instead of QEMU.
> 
> No, wrong!  In fact, reporting bad performance is pretty much the same
> as throwing down the gauntlet.
> 
> Enter qboot, a minimal x86 firmware that runs on QEMU and, together with
> a slimmed-down QEMU configuration, boots a virtual machine in 40
> milliseconds[2] on an Ivy Bridge Core i7 processor.
> 
> qboot is available at git://github.com/bonzini/qboot.git.  In all the
> glory of its 8KB of code, it brings together various existing open
> source components:
> 
> * a minimal (really minimal) 16-bit BIOS runtime based on kvmtool's own BIOS
> 
> * a couple hardware initialization routines written mostly from scratch
> but with good help from SeaBIOS source code
> 
> * a minimal 32-bit libc based on kvm-unit-tests
> 
> * the Linux loader from QEMU itself
> 
> The repository has more information on how to achieve fast boot times,
> and examples of using qboot.  Right now there is a limit of 8 MB for
> vmlinuz+initrd+cmdline, which however should be enough for initrd-less
> containers.
> 
> The first commit to qboot is more or less 24 hours old, so there is
> definitely more work to do, in particular to extract ACPI tables from
> QEMU and present them to the guest.  This is probably another day of
> work or so, and it will enable multiprocessor guests with little or no
> impact on the boot times.  SMBIOS information is also available from QEMU.
> 
> On the QEMU side, there is no support yet for persistent memory and the
> NFIT tables from ACPI 6.0.  Once that (and ACPI support) is added, qboot
> will automatically start using it.
> 
> Happy hacking!

Incidentally, I did something similar these days to get Linux booting in
Jailhouse non-root cells, i.e without BIOS and almost no hardware except
memory, cpus and pci devices. Yes, requires a bit pv for Linux, but
really little. Not aiming for speed (yet), just for less hypervisor
work. Maybe there are some milliseconds to save when cutting off more
hardware in an analogous way...

PV pat^Whacks are here:
http://git.kiszka.org/?p=linux.git;a=shortlog;h=refs/heads/queues/jailhouse.
The boot loader is a combination of a python script [1] (result can be
saved and reused - replaces ACPI) and really few lines of code [2][3].

Jan

[1]
https://github.com/siemens/jailhouse/blob/wip/linux-x86-inmate/tools/jailhouse-cell-linux
[2]
https://github.com/siemens/jailhouse/blob/wip/linux-x86-inmate/inmates/lib/x86/header.S
[3]
https://github.com/siemens/jailhouse/blob/wip/linux-x86-inmate/inmates/tools/x86/linux-loader.c

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux