On Mon, Nov 19, 2018 at 01:07:13PM +0000, Stefan Hajnoczi wrote:
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@redhat.com wrote:
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).
Will probably be possible to a certain degree, but I expect you can't get 100% of the qboot savings without something like -boot fast=on.
For example, if SeaBIOS sees -kernel, is it necessary to follow the full BIOS boot process including loading option ROMs?
Well, right now -kernel loading is actually implemented by an option rom ...
This way we could avoid scanning PCI devices.
That has consequences for the acpi tables, because qemu checks where the firmware mapped the pci bars when generating the tables.
Also it is not a given that skipping pci initialization in seabios is a win in the end. The linux kernel has to handle pci bar configuration then so it might be we just shift around boot times.
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.
Yes, lets see.
cheers, Gerd