qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] SeaBIOS booting time optimization


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] SeaBIOS booting time optimization
Date: Mon, 19 Nov 2018 13:07:13 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Nov 19, 2018 at 11:42:28AM +0100, Stefano Garzarella wrote:
> On Mon, Nov 19, 2018 at 9:49 AM Gerd Hoffmann <address@hidden> 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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]