SeaBIOS

seabios@seabios.org

3 participants
3799 discussions

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Gerd Hoffmann 22 Nov '18

22 Nov '18

Hi, > > Background: The drivers in seabios work on both virtual and physical > > hardware (you can run seabios as coreboot payload on physical hardware). > > There are quite a few places where are delays and timeouts which are > > required to work properly on physical hardware. But typically virtual > > hardware is alot faster. There is -- for example -- no time needed to > > establish a sata link. Link detection in ahci is instant on qemu. > > I'll investigate also other timeouts. I'd focus on legacy lpc/isa hardware here. PCI-ish hardware which has such timeouts (sata, usb, ...) typically isn't present in the virtual machine if you care about performance. Or, in other words, the best way to handle the sata link detection delay is to use "qemu -M q35,sata=off". cheers, Gerd

2 1

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Kevin O'Connor 20 Nov '18

20 Nov '18

On Mon, Nov 19, 2018 at 07:38:39PM +0100, Stefano Garzarella wrote: > 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 FYI, this was raised a few months ago - see: https://mail.coreboot.org/pipermail/seabios/2018-March/012186.html IIRC, it should be possible to verify the TPM device is present before trying to wait for it. -Kevin

3 2

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Gerd Hoffmann 20 Nov '18

20 Nov '18

Hi, > 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. Another possible option is to simply use shorter timeouts on qemu (using runningOnQEMU()), I'd suggest to check with the TPM maintainers whenever that is ok. Background: The drivers in seabios work on both virtual and physical hardware (you can run seabios as coreboot payload on physical hardware). There are quite a few places where are delays and timeouts which are required to work properly on physical hardware. But typically virtual hardware is alot faster. There is -- for example -- no time needed to establish a sata link. Link detection in ahci is instant on qemu. cheers, Gerd

2 1

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Stefan Hajnoczi 19 Nov '18

19 Nov '18

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(a)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

3 2

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Gerd Hoffmann 19 Nov '18

19 Nov '18

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 ... > Any pointers or suggestions would be helpful. seabios could try to skip initializing hardware without bootindex with "qemu -boot menu=off,strict=on". mmconfig support? I think that would reduce the number of vmexits needed for pci initialization. cheers, Gerd

2 1

Re: [SeaBIOS] SeaBIOS booting time optimization
by Samuel Ortiz 19 Nov '18

19 Nov '18

Hi Stefano, On Fri, Nov 16, 2018 at 05:13:59PM +0100, Stefano Garzarella 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. Definitely, thanks. > Following this thread ( > https://mail.coreboot.org/pipermail/seabios/2015-July/009497.html), > I'm using qboot (https://github.com/bonzini/qboot) to compare the SeaBIOS > booting time. > > As Paolo did in qboot, I manually add small debug port writes in SeaBIOS and > linuxboot_dma.c (QEMU) to trace the events with perf (kvm_pio events) When doing similar measuremnts, I also used the debug-exit qemu device in order to make imho simpler measuremnts, see https://github.com/intel/nemu/wiki/Measuring-Boot-Latency Probably not as precised as yours, but it was enough for what we tried to characterize. > The goal is to have only one image of SeaBIOS configurable at runtime to > reduce > the boot time, avoiding unnecessary initialization. > > Any pointers or suggestions would be helpful. > > Following I put some preliminary measurements that I obtained: > I used this QEMU command line: > ./qemu-system-x86_64 -bios $BIOS -m 1G -cpu host -M accel=kvm \ > -kernel /boot/vmlinuz-4.18.18-300.fc29.x86_64 -append 'console=ttyS0' \ > -nographic -serial mon:stdio > > For each test, I measured these times (in milliseconds) relative to the > "sched_process_exec" event: > - qemu_init_end: first kvm_entry (i.e. QEMU initialized has finished) > - fw_start: first entry of the BIOS > - fw_do_boot: after the BIOS initialization (e.g. PCI setup, etc.) > - linux_start_boot: before the jump to the Linux kernel Are you planning to also measure the total time to userspace as well? How we set the hardware up from the FW/BIOS can also influence the overall (up to ring 3) boot latency on our experiments. > # qboot > BIOS=/home/stefano/repos/qboot/bios.bin > qemu_init_end: 40.561234 > fw_start: 40.721729 (+0.160495) > fw_do_boot: 47.025591 (+6.303862) > linux_start_boot: 48.874112 (+1.848521) > > # SeaBIOS with default configuration > BIOS=/home/stefano/repos/seabios/out_default/bios.bin > qemu_init_end: 40.419451 > fw_start: 40.639967 (+0.220516) > fw_do_boot: 886.668828 (+846.028861) > linux_start_boot: 889.723547 (+3.054719) > > # SeaBIOS with Kevin's configuration > # (https://mail.coreboot.org/pipermail/seabios/2015-July/009508.html) > # Note: this SeaBIOS setup is so stripped down that it can't actually boot > an OS > BIOS=/home/stefano/repos/seabios/out_kevin/bios.bin > qemu_init_end: 40.676412 > fw_start: 40.755757 (+0.079345) > fw_do_boot: 56.427023 (+15.671266) That's a slight improvement ;) > I did the same tests also with NEMU (without using -M virt) and I have > approximately the same results. Yes, as expected. > As the next step, I'll start from Kevin's configuration to have a minimal > SeaBIOS image ables to boot a Linux kernel. Please keep us posted. Cheers, Samuel.

2 1

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Samuel Ortiz 18 Nov '18

18 Nov '18

Hi Stefan, On Fri, Nov 16, 2018 at 04:39:20PM +0000, Stefan Hajnoczi wrote: > On Fri, Nov 16, 2018 at 4:21 PM Stefano Garzarella <sgarzare(a)redhat.com> wrote: > > 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. > > Questions for NEMU folks: > > qboot isn't part of the virt-x86 NEMU tree and is only mentioned in > one or two places. Is NEMU focussing exclusively on OVMF guest > firmware instead of qboot? Initally we were only focusing on OVMF, but we added support for qboot [1] as we were not happy with the OVMF boot latencies we measured, especially in the Kata containers context. Rob was about to start looking at seabios support as well. We are going to upstream a cleaner version of the virt support to qboot very soon now. > Are there other boot time optimizations in NEMU that are a candidate > for upstreaming? We did not add anything specific, but when comparing PC+qboot with virt+qboot, we're seeing interesting overall boot time improvements. We assume the simpler virt machine type explains the difference. Cheers, Samuel. [1] https://github.com/rbradford/qboot/commit/dbcaaa1f6921064cd46f330a3625eb01e…

1 0

[ANNOUNCE] SeaBIOS 1.12.0
by Kevin O'Connor 17 Nov '18

17 Nov '18

The 1.12.0 version of SeaBIOS has now been released. For more information on the release, please see: http://seabios.org/Releases New in this release: * Initial support for "TPM CRB" hardware * Improved cdrom media reporting in the boot menu on QEMU * Improved floppy support on real floppy hardware * SeaVGABIOS support for QEMU "bochs-display" and QEMU "ramfb" displays * Several bug fixes and code cleanups For information on obtaining SeaBIOS, please see: http://seabios.org/Download ===== git shortlog -n rel-1.11.0..rel-1.12.0 ===== Gerd Hoffmann (12): optionrom: enable non-vga display devices cbvga: factor out cbvga_setup_modes() qemu: add bochs-display support cbvga_setup_modes: use real mode number instead of 0x140 cbvga_list_modes: don't list current mode twice cbvga_set_mode: disable clearmem in windows x86 emulator. bochs_display_setup: return error on failure pmm: use tmp zone on oom vgasrc: add allocate_pmm() qemu: add qemu ramfb support cbvga_set_mode: refine clear display logic pretty boot menu entry for cdrom drives Nikolay Nikolov (11): floppy: Introduce the floppy_dor_read() function floppy: Introduce floppy_dor_mask() floppy: Introduce FLOPPY_DOR_XXX constants floppy: Preserve motor and drive sel bits when resetting the floppy controller floppy: Reset the floppy motor count in floppy_drive_pio() floppy: Use timer_check() in floppy_wait_irq() floppy: hold the DOR reset bit low for 4 microseconds, when resetting floppy: Execute a SPECIFY command after sensing the media type floppy: Support up to 4 floppy drives when turning on the floppy motor floppy: Wait for the floppy motor to reach a stable speed, after starting floppy: Send 4 sense interrupt commands during controller initialization Kevin O'Connor (10): docs: Add sercon-port to Runtime_config.md documentation paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified shadow: Don't invoke a shutdown on reboot unless in a reboot loop build: Use git describe --always docs: Update Download.md to use git clone via https ssdt: Fix building of legacy acpi tables on current iasl compiler docs: Update download file link sdcard: Increase SDHCI_POWER_ON_TIME to 5ms shadow: Rework bios copy code to prevent gcc array-bounds warning docs: Note v1.12.0 release Stefan Berger (5): tpm: Add support for TPM2 ACPI table tpm: Wait for tpmRegValidSts flag on CRB interface before probing tpm: revert return values for successful/failed CRB probing tpm: when CRB is active, select, lock it, and check addresses tpm: Request access to locality 0 Marc-André Lureau (4): x86: add readq() tpm: generalize init_timeout() tpm: use get_tpm_version() callback tpm: add TPM CRB device support Jing Liu (3): pci: fix the return value for truncated capability pci: clean up the debug message for pci capability found pci: recognize RH PCI legacy bridge resource reservation capability Stephen Douthit (3): tpm: Refactor duplicated wait code in tis_wait_sts() & crb_wait_reg() tpm: Wait for interface startup when probing tpm: Handle unimplemented TIS_REG_IFACE_ID in tis_get_tpm_version() Matt DeVillier (2): nvme: fix I/O queue length calculation overflow SeaVGABios/cbvga: Fix bpp for coreboot framebuffer Marcel Apfelbaum (1): pci: fix 'io hints' capability for RedHat PCI bridges Paul Menzel (1): docs/Download: Use more secure HTTPS URLs where possible Shmuel Eiderman (1): pvscsi: Scan all 64 possible targets

1 0

Re: [SeaBIOS] [PATCH] ramdisk: search for all available floppy images instead of one
by Kevin O'Connor 16 Nov '18

16 Nov '18

On Sun, Nov 11, 2018 at 02:12:09AM +0300, Mike Banon wrote: > > However I'm concerned that this would reserve memory for all > > of the floppy images in the e820 map (and thus the final OS > > would not be able to use that memory). > > sorry Kevin I'm not fully understanding the consequences. Would > reserving e820 memory for all the floppies - result in a slightly > lower amount of available RAM to OS (e.g. just 14 MB lower if I add 10 > floppies) or there could be more serious problems? Just the loss of 14MB of ram. It seems odd to reserve that ram when I expect one would rarely use it. Arguably, seabios shouldn't reserve even 1.4MB of ram if one isn't actually booting from the given image, but extending this to every image found when most wouldn't even be accessible seems even worse. >When I've been > testing this patch - together with "35 boot menu entries" patch by > Ivan - https://mail.coreboot.org/pipermail/seabios/2017-June/011416.html > - I added about 30 floppies and everything seemed to work perfectly. > If there are no other possible problems, I am okay with slightly lower > amount of RAM - and only the "multiple floppies" users will be > affected. Also, what's good about this patch is that its' only a small > change for SeaBIOS source code - mostly placing the "floppy searching" > code inside the "for" cycle. But I could try to do something with the > allocation part if that wouldn't turn out too difficult Okay, thanks. We're planning to make a SeaBIOS release in a few days and this change would be post release anyway. -Kevin

2 1

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Stefan Hajnoczi 16 Nov '18

16 Nov '18

On Fri, Nov 16, 2018 at 4:21 PM Stefano Garzarella <sgarzare(a)redhat.com> wrote: > 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. Questions for NEMU folks: qboot isn't part of the virt-x86 NEMU tree and is only mentioned in one or two places. Is NEMU focussing exclusively on OVMF guest firmware instead of qboot? Are there other boot time optimizations in NEMU that are a candidate for upstreaming? Stefan

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS