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



--
Stefano Garzarella
Red Hat