[SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
stefanha at gmail.com
Mon Nov 19 14:07:13 CET 2018
On Mon, Nov 19, 2018 at 11:42:28AM +0100, Stefano Garzarella wrote:
> On Mon, Nov 19, 2018 at 9:49 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
> > Hi,
> > > I'm investigating the SeaBIOS booting time, to understand if we can
> > > reduce the boot time in some cases (e.g. legacy hardware is not
> > > needed). I think this can be interesting also for NEMU developers.
> > > The goal is to have only one image of SeaBIOS configurable at runtime
> > > to reduce the boot time, avoiding unnecessary initialization.
> > Why at runtime? What is bad with two images? With a runtime option
> > you probably need some way to enable the "fastboot" hint for seabios,
> > because some optimizations (like skipping ps/2 initialization) breaks
> > functionality. So it must be opt-in so you can enable it if you know
> > your use case is fine with that. But "qemu -boot fast=on" isn't much
> > different from "qemu -bios seabios-fastboot.bin" after all ...
> You are right, but maybe having a single image can be simpler to distribute,
> and we can implement something (eg. using fw_cfg) to selectively enable
> features needed.
> Anyway, as the first step, I'll try to build a separate image of SeaBIOS.
Gerd, you may be right that explicit an command-line option like -boot
fast=on is required. I was hoping SeaBIOS improvements could
automatically detect cases where no functionality is lost and would not
require new command-line options for users or management tools (e.g.
For example, if SeaBIOS sees -kernel, is it necessary to follow the full
BIOS boot process including loading option ROMs? This way we could
avoid scanning PCI devices.
Admittedly I don't know the answer to how transparent we can make this,
but I hope Stefano will identify how far we can go.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: not available
More information about the SeaBIOS