November 2018 - SeaBIOS - mail.coreboot.org

Enable vga_console later during startup
by Julian Sparber Nov. 22, 2018

Nov. 22, 2018

Hi to all, During boot Seabios shows some text including the version number on top of the screen for a couple of seconds before switching to the boot splash. It doesn't happen every time, but it is really annoying when it does because it makes the boot much less fluid. I fixed this by enabling the vga_console later during the startup. I attached a patch to this email. I tried it in qemu and on my laptop. Let me know what you think. Cheers, jsparber

2 1

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Gerd Hoffmann Nov. 22, 2018

Nov. 22, 2018

On Thu, Nov 22, 2018 at 12:08:55PM +0100, Stefano Garzarella wrote: > Hi, > I continued to investigate how to reduce the boot time with SeaBIOS > and QEMU when it used with linuxboot_dma.bin (-kernel parameter). > I reached ~12ms with a SeaBIOS configuration (attached) where I > disabled debug output, all Hardware support (except SMM & MTRRs) and I > applied a small patch to disable VGA setup and console (attached). Is there any difference to "qemu -vga none" ? > Samuel, I put also the total time to userspace (linux_start_user) > adding a probe in the kernel_init() and when I disabled the VGA in the > SeaBIOS I noticed also a speed up in the kernel boot phase. Might come from linux 16bit boot code scanning vgabios for available video modes (for vga=<mode> cmdline arg). > Another approach that I tried, obtaining similar results, is to > recognize the linuxboot_dma.bin at runtime, then skip > device_hardware_setup(), enable_vga_console(), and vgarom_setup(). Hmm, tricky. linuxboot_dma.bin just registers a boot entry, so with "qemu -kernel -boot menu=on" you can still get a boot menu, and the direkt kernel boot is one menu item there. So you can't know for sure whenever a direct kernel boot will happen or not. So, I think at minimum we should make this depend on both linuxboot_dma and boot menu disabled. cheers, Gerd

2 1

Re: [SeaBIOS] [Qemu-devel] SeaBIOS booting time optimization
by Gerd Hoffmann Nov. 22, 2018

Nov. 22, 2018

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 Nov. 20, 2018

Nov. 20, 2018

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 Nov. 20, 2018

Nov. 20, 2018

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 Nov. 19, 2018

Nov. 19, 2018

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 Nov. 19, 2018

Nov. 19, 2018

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 Nov. 19, 2018

Nov. 19, 2018

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 Nov. 18, 2018

Nov. 18, 2018

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 Nov. 17, 2018

Nov. 17, 2018

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