On Mon, Nov 19, 2018 at 3:15 PM Gerd Hoffmann kraxel@redhat.com wrote:
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.
Hi guys, just an update, I enabled the debug prints and I saw two timeouts fired with a lot of time lost (~780ms between "init timer" and "Scan for VGA ..."), putting other prints I discovered that a lot of time is spent in the tpm_setup(), during the probe of the 2 TPM devices:
00.548869 init timer 00.549677 ./src/post.c:157 platform_hardware_setup 00.550182 ./src/hw/tpm_drivers.c:579 tpmhw_probe 01.300833 WARNING - Timeout at wait_reg8:81! 01.301388 ./src/hw/tpm_drivers.c:579 tpmhw_probe 01.331843 WARNING - Timeout at wait_reg8:81! 01.332316 ./src/post.c:160 platform_hardware_setup 01.333358 Scan for VGA option rom
Indeed, in the probe of the TPM devices (TIS and CRB) there are timeouts of 750 ms and 30 ms respectively.
Then, statically disabling TPM and TCG (CONFIG_TCGBIOS) the time spent in SeaBIOS goes down from ~846ms to ~56ms: # SeaBIOS disabling CONFIG_TCGBIOS BIOS=/home/stefano/repos/seabios/out_notcgbios/bios.bin qemu_init_end: 40.658371 fw_start: 40.850395 (+0.192024) fw_do_boot: 96.750142 (+55.899747) linux_start_boot: 98.880578 (+2.130436)
The tpm_setup() is called after the qemu_cfg_init(), so I think we can disable this call using some fw_cfg parameters, if we will decide to implement a runtime approach.
Cheers, Stefano
cheers, Gerd