Announcing qboot, a minimal x86 firmware for QEMU

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Announcing qboot, a minimal x86 firmware for QEMU

Paolo Bonzini-5
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!

Paolo

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Avi Kivity-2
On 05/21/2015 04:51 PM, 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!
>

Lovely!

Note you have memcpy.o instead of memcpy.c.

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Paolo Bonzini-5


On 21/05/2015 17:48, Avi Kivity wrote:
> Lovely!
>
> Note you have memcpy.o instead of memcpy.c.

Doh, and it's not used anyway.  Check the repository, and let me know if
OSv boots with it (it probably needs ACPI; Linux doesn't boot virtio
without ACPI).

Paolo

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Jan Kiszka-3
In reply to this post by Paolo Bonzini-5
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

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Avi Kivity-2
In reply to this post by Paolo Bonzini-5
On 05/21/2015 07:21 PM, Paolo Bonzini wrote:
>
> On 21/05/2015 17:48, Avi Kivity wrote:
>> Lovely!
>>
>> Note you have memcpy.o instead of memcpy.c.
> Doh, and it's not used anyway.  Check the repository, and let me know if
> OSv boots with it (it probably needs ACPI; Linux doesn't boot virtio
> without ACPI).
>

Yes, it requires ACPI.  We don't implement the pre-ACPI bootstrap methods.

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Yong Wang
In reply to this post by Paolo Bonzini-5
On Thu, May 21, 2015 at 03:51:43PM +0200, Paolo Bonzini wrote:
> 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.
>

We are working on adding NFIT support into virtual bios.


Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Daniel P. Berrangé
In reply to this post by Paolo Bonzini-5
On Thu, May 21, 2015 at 03:51:43PM +0200, 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.

On the QEMU side of things I wonder if there is scope for taking AArch64's
'virt' machine type concept and duplicating it on all architectures. It
would be nice to have a common minimal machine type on all architectures
that discards all legacy platform stuff and focuses on the minimum needed
to run modern virtual machine optimized guest OS. People would always know
that a machine type called 'virt' was the minimal virtualization platform,
while the others all target emulation of realworld (legacy) baremetal
platforms.

Regards,
Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Peter Maydell-5
On 22 May 2015 at 12:01, Daniel P. Berrange <[hidden email]> wrote:
> On the QEMU side of things I wonder if there is scope for taking AArch64's
> 'virt' machine type concept and duplicating it on all architectures.

Experience suggests that holding the line on "minimal" is really
quite tricky, though -- there's always one more thing that
somebody really wants to add...

-- PMM

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Daniel P. Berrangé
On Fri, May 22, 2015 at 12:04:54PM +0100, Peter Maydell wrote:
> On 22 May 2015 at 12:01, Daniel P. Berrange <[hidden email]> wrote:
> > On the QEMU side of things I wonder if there is scope for taking AArch64's
> > 'virt' machine type concept and duplicating it on all architectures.
>
> Experience suggests that holding the line on "minimal" is really
> quite tricky, though -- there's always one more thing that
> somebody really wants to add...

Yep, it is hard saying no - but I'd think as long as it was possible to add
the extra features using -device, it ought to be practical to keep a "virt"
machine types "-nodefaults -nodefconfig" base setup pretty minimal. In
particular I don't see why we need to have a SATA controller and ISA/LPC
bridge in every virt machine - root PCI bus only should be possible, as you
can provide disks via virtio-blk or virtio-scsi and serial, parallel, mouse,
floppy via PCI devices and/or by adding a USB bus in the cases where you
really need one.

Regards,
Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Peter Maydell-5
On 22 May 2015 at 12:12, Daniel P. Berrange <[hidden email]> wrote:
> Yep, it is hard saying no - but I'd think as long as it was possible to add
> the extra features using -device, it ought to be practical to keep a "virt"
> machine types "-nodefaults -nodefconfig" base setup pretty minimal.

Mmm, but -device only works for pluggable devices really. We don't
have a coherent mechanism for saying "put the PS/2 keyboard controller
into the system at its usual IO ports" on the command line.

-- PMM

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Daniel P. Berrangé
On Fri, May 22, 2015 at 12:21:27PM +0100, Peter Maydell wrote:
> On 22 May 2015 at 12:12, Daniel P. Berrange <[hidden email]> wrote:
> > Yep, it is hard saying no - but I'd think as long as it was possible to add
> > the extra features using -device, it ought to be practical to keep a "virt"
> > machine types "-nodefaults -nodefconfig" base setup pretty minimal.
>
> Mmm, but -device only works for pluggable devices really. We don't
> have a coherent mechanism for saying "put the PS/2 keyboard controller
> into the system at its usual IO ports" on the command line.

Oh, I didn't neccessarily mean that we'd need the ability to add a
ps/2 keyboard via -device. I meant that there just need to be able
to add /some/ kind of keyboard. eg we have a usb-kbd device that
could potentially fill that role. Likewise for mouse pointer. Serial
ports, etc.

Regards,
Daniel
--
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Gerd Hoffmann-3
In reply to this post by Peter Maydell-5
On Fr, 2015-05-22 at 12:21 +0100, Peter Maydell wrote:
> On 22 May 2015 at 12:12, Daniel P. Berrange <[hidden email]> wrote:
> > Yep, it is hard saying no - but I'd think as long as it was possible to add
> > the extra features using -device, it ought to be practical to keep a "virt"
> > machine types "-nodefaults -nodefconfig" base setup pretty minimal.
>
> Mmm, but -device only works for pluggable devices really. We don't
> have a coherent mechanism for saying "put the PS/2 keyboard controller
> into the system at its usual IO ports" on the command line.

Do we need that in the first place?
You can plugin a usb keyboard today.
You'll be able to plugin a virtio keyboard soon.

I think alot of hardware where this applies to is the legacy stuff we
want to get rid of for '-M virt' ...

cheers,
  Gerd



Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Markus Armbruster
In reply to this post by Peter Maydell-5
Peter Maydell <[hidden email]> writes:

> On 22 May 2015 at 12:12, Daniel P. Berrange <[hidden email]> wrote:
>> Yep, it is hard saying no - but I'd think as long as it was possible to add
>> the extra features using -device, it ought to be practical to keep a "virt"
>> machine types "-nodefaults -nodefconfig" base setup pretty minimal.
>
> Mmm, but -device only works for pluggable devices really. We don't
> have a coherent mechanism for saying "put the PS/2 keyboard controller
> into the system at its usual IO ports" on the command line.

... yet.

The qdev long-term vision has always been to support starting with an
empty board, then add device models and their wiring.  Unfortunately,
progress towards that goal has been slow.

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Gerd Hoffmann-3
In reply to this post by Paolo Bonzini-5
  Hi,

> qboot is available at git://github.com/bonzini/qboot.git.

Firmware repo has packages now.

https://www.kraxel.org/repos/firmware.repo
https://www.kraxel.org/repos/jenkins/qboot/

enjoy,
  Gerd



Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Kevin O'Connor-2
In reply to this post by Paolo Bonzini-5
On Thu, May 21, 2015 at 03:51:43PM +0200, 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.

Hi Paolo,

I'm curious if you've tried profiling SeaBIOS to see where it is
spending unnecessary time?  I wonder if a stripped down SeaBIOS could
obtain sufficient performance.

The page at http://seabios.org/Debugging#Timing_debug_messages
describes how to do basic profiling via timing of debug messages.

The default SeaBIOS build takes ~180ms on my (old AMD) system.  But,
by removing drivers and options via Kconfig I was able to bring it
down to ~25ms.  I suspect some additional Kconfig settings and a few
optimizations would make it possible to significantly reduce this
time.

Cheers,
-Kevin

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Kevin O'Connor-2
On Fri, May 22, 2015 at 07:23:27PM -0400, Kevin O'Connor wrote:

> On Thu, May 21, 2015 at 03:51:43PM +0200, 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.
>
> Hi Paolo,
>
> I'm curious if you've tried profiling SeaBIOS to see where it is
> spending unnecessary time?  I wonder if a stripped down SeaBIOS could
> obtain sufficient performance.
>
> The page at http://seabios.org/Debugging#Timing_debug_messages
> describes how to do basic profiling via timing of debug messages.
>
> The default SeaBIOS build takes ~180ms on my (old AMD) system.  But,
> by removing drivers and options via Kconfig I was able to bring it
> down to ~25ms.  I suspect some additional Kconfig settings and a few
> optimizations would make it possible to significantly reduce this
> time.

Out of curiosity, I ran some additional timing tests.  With SeaBIOS
fully stripped down (via Kconfig), it takes ~20ms to get to the boot
phase on my old AMD system.  Of that 20ms, ~7ms is to enable shadow
ram, 2ms is to calibrate the cpu timestamp counter, 4ms is for pci
init, and ~6ms is to make the shadow ram area read-only.  The time in
the remaining parts of the SeaBIOS code is so small that it's hard to
measure.

The above delays could be removed without much work:  It would be
trivial to add kconfig options to support disabling the pci init and
shadow read-only functionality.  The cpu timestamp calibrations could
be reworked so that the existence of the ACPI timer was checked first
so as to avoid that work.  The enabling of shadow ram could also be
bypassed if QEMU was changed to start with a ram based shadow instead
of a rom shadow (since QEMU doesn't fully implement the chipset shadow
registers, it's really pointless to start in rom shadow mode anyway).

-Kevin

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Vasiliy Tolstov-2
2015-05-23 6:55 GMT+03:00 Kevin O'Connor <[hidden email]>:
> Out of curiosity, I ran some additional timing tests.  With SeaBIOS
> fully stripped down (via Kconfig), it takes ~20ms to get to the boot
> phase on my old AMD system.  Of that 20ms, ~7ms is to enable shadow
> ram, 2ms is to calibrate the cpu timestamp counter, 4ms is for pci
> init, and ~6ms is to make the shadow ram area read-only.  The time in
> the remaining parts of the SeaBIOS code is so small that it's hard to
> measure.


Can you share config for seabios? As i understand i can safety to
remove keybord, ps2, usb, ata/ahci and leave only virtio (in case of
using qemu to boo linux/freebsd/windows systems) ?

--
Vasiliy Tolstov,
e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Paolo Bonzini-5
In reply to this post by Kevin O'Connor-2


On 23/05/2015 01:23, Kevin O'Connor wrote:
> Hi Paolo,
>
> I'm curious if you've tried profiling SeaBIOS to see where it is
> spending unnecessary time?

No, I really wanted to get the absolute minimum time needed to get to
the kernel.  I announced it publicly because I think it's also instructive.

> I wonder if a stripped down SeaBIOS could
> obtain sufficient performance.

It most likely could.  However, some of the features (e.g. booting
vmlinuz from parallel flash or, in the future, from persistent memory)
probably do not fit SeaBIOS very well.  One would have to redo them
otherwise, for example using a DMA interface in fw_cfg.

Paolo

> The page at http://seabios.org/Debugging#Timing_debug_messages
> describes how to do basic profiling via timing of debug messages.
>
> The default SeaBIOS build takes ~180ms on my (old AMD) system.  But,
> by removing drivers and options via Kconfig I was able to bring it
> down to ~25ms.  I suspect some additional Kconfig settings and a few
> optimizations would make it possible to significantly reduce this
> time.
>
> Cheers,
> -Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to [hidden email]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Paolo Bonzini-5
In reply to this post by Daniel P. Berrangé


On 22/05/2015 13:12, Daniel P. Berrange wrote:
> In
> particular I don't see why we need to have a SATA controller and ISA/LPC
> bridge in every virt machine - root PCI bus only should be possible, as you
> can provide disks via virtio-blk or virtio-scsi and serial, parallel, mouse,
> floppy via PCI devices and/or by adding a USB bus in the cases where you
> really need one.

I think removing the ISA/LPC bridge is hard.  It includes the real-time
clock and fw_cfg, for example.

Paolo

Reply | Threaded
Open this post in threaded view
|

Re: Announcing qboot, a minimal x86 firmware for QEMU

Kevin O'Connor-2
In reply to this post by Vasiliy Tolstov-2
On Mon, May 25, 2015 at 09:21:49AM +0300, Vasiliy Tolstov wrote:

> 2015-05-23 6:55 GMT+03:00 Kevin O'Connor <[hidden email]>:
> > Out of curiosity, I ran some additional timing tests.  With SeaBIOS
> > fully stripped down (via Kconfig), it takes ~20ms to get to the boot
> > phase on my old AMD system.  Of that 20ms, ~7ms is to enable shadow
> > ram, 2ms is to calibrate the cpu timestamp counter, 4ms is for pci
> > init, and ~6ms is to make the shadow ram area read-only.  The time in
> > the remaining parts of the SeaBIOS code is so small that it's hard to
> > measure.
>
> Can you share config for seabios? As i understand i can safety to
> remove keybord, ps2, usb, ata/ahci and leave only virtio (in case of
> using qemu to boo linux/freebsd/windows systems) ?
To get to 20ms, I basically disabled everything.  (Actually, after
sending my last email I found I cound get to 16ms by setting
CONFIG_WRITABLE_UPPERMEMORY=y - it avoids much of the shadow ram
read-only cost.)  It's not possible to actually boot anything with
this config - I was instead timing to the point where one could add a
multiboot or vmlinux boot capability to SeaBIOS.

To get to these times I disabled debug messages themselves (they take
a few ms of the boot time).  So, to time events without debug messages
I added a few outb() calls to seabios at critical points.  See patch
and config below.

-Kevin


--- a/src/post.c
+++ b/src/post.c
@@ -167,11 +167,15 @@ platform_hardware_setup(void)
     // Init base pc hardware.
     pic_setup();
     mathcp_setup();
+    outb('3', 0x402); outb('\n', 0x402);
     timer_setup();
+    outb('4', 0x402); outb('\n', 0x402);
     clock_setup();
 
     // Platform specific setup
+    outb('5', 0x402); outb('\n', 0x402);
     qemu_platform_setup();
+    outb('6', 0x402); outb('\n', 0x402);
     coreboot_platform_setup();
 }
 
@@ -200,6 +204,7 @@ startBoot(void)
     // Clear low-memory allocations (required by PMM spec).
     memset((void*)BUILD_STACK_ADDR, 0, BUILD_EBDA_MINIMUM - BUILD_STACK_ADDR);
 
+    outb('8', 0x402); outb('\n', 0x402);
     dprintf(3, "Jump to int19\n");
     struct bregs br;
     memset(&br, 0, sizeof(br));
@@ -247,6 +252,7 @@ maininit(void)
     prepareboot();
 
     // Write protect bios memory.
+    outb('7', 0x402); outb('\n', 0x402);
     make_bios_readonly();
 
     // Invoke int 19 to start boot process.
@@ -331,12 +337,14 @@ handle_post(void)
 
     serial_debug_preinit();
     debug_banner();
+    outb('1', 0x402); outb('\n', 0x402);
 
     // Check if we are running under Xen.
     xen_preinit();
 
     // Allow writes to modify bios area (0xf0000)
     make_bios_writable();
+    outb('2', 0x402); outb('\n', 0x402);
 
     // Now that memory is read/writable - start post process.
     dopost();



.config (1K) Download Attachment
12