On Mon, Nov 19, 2018 at 11:42:28AM +0100, Stefano Garzarella wrote: > On Mon, Nov 19, 2018 at 9:49 AM Gerd Hoffmann <kra...@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. libvirt). 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. Stefan
signature.asc
Description: PGP signature