<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 19, 2018 at 3:15 PM Gerd Hoffmann <<a href="mailto:kraxel@redhat.com" target="_blank">kraxel@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Nov 19, 2018 at 01:07:13PM +0000, Stefan Hajnoczi wrote:<br>
> On Mon, Nov 19, 2018 at 11:42:28AM +0100, Stefano Garzarella wrote:<br>
> > On Mon, Nov 19, 2018 at 9:49 AM Gerd Hoffmann <<a href="mailto:kraxel@redhat.com" target="_blank">kraxel@redhat.com</a>> wrote:<br>
> > <br>
> > > Why at runtime?  What is bad with two images?  With a runtime option<br>
> > > you probably need some way to enable the "fastboot" hint for seabios,<br>
> > > because some optimizations (like skipping ps/2 initialization) breaks<br>
> > > functionality.  So it must be opt-in so you can enable it if you know<br>
> > > your use case is fine with that.  But "qemu -boot fast=on" isn't much<br>
> > > different from "qemu -bios seabios-fastboot.bin" after all ...<br>
> > ><br>
> > <br>
> > You are right, but maybe having a single image can be simpler to distribute,<br>
> > and we can implement something (eg. using fw_cfg) to selectively enable<br>
> > features needed.<br>
> > Anyway, as the first step, I'll try to build a separate image of SeaBIOS.<br>
> <br>
> Gerd, you may be right that explicit an command-line option like -boot<br>
> fast=on is required.  I was hoping SeaBIOS improvements could<br>
> automatically detect cases where no functionality is lost and would not<br>
> require new command-line options for users or management tools (e.g.<br>
> libvirt).<br>
<br>
Will probably be possible to a certain degree, but I expect you can't<br>
get 100% of the qboot savings without something like -boot fast=on.<br>
<br>
> For example, if SeaBIOS sees -kernel, is it necessary to follow the full<br>
> BIOS boot process including loading option ROMs?<br>
<br>
Well, right now -kernel loading is actually implemented by an option rom ...<br>
<br>
> This way we could avoid scanning PCI devices.<br>
<br>
That has consequences for the acpi tables, because qemu checks where the<br>
firmware mapped the pci bars when generating the tables.<br>
<br>
Also it is not a given that skipping pci initialization in seabios is a<br>
win in the end.  The linux kernel has to handle pci bar configuration<br>
then so it might be we just shift around boot times.<br>
<br>
> Admittedly I don't know the answer to how transparent we can make this,<br>
> but I hope Stefano will identify how far we can go.<br>
<br>
Yes, lets see.<br></blockquote><div><br></div><div>Hi guys,</div><div>just an update, I enabled the debug prints and I saw two timeouts fired with a lot</div><div>of time lost (~780ms between "init timer" and "Scan for VGA ..."),</div><div>putting other prints I discovered that a lot of time is spent in the tpm_setup(),</div><div>during the probe of the 2 TPM devices:<br></div><div><br></div><div>00.548869 init timer<br>00.549677 ./src/post.c:157 platform_hardware_setup<br>00.550182 ./src/hw/tpm_drivers.c:579 tpmhw_probe<br>01.300833 WARNING - Timeout at wait_reg8:81!<br>01.301388 ./src/hw/tpm_drivers.c:579 tpmhw_probe<br>01.331843 WARNING - Timeout at wait_reg8:81!<br>01.332316 ./src/post.c:160 platform_hardware_setup<br>01.333358 Scan for VGA option rom</div><div><br></div><div>Indeed, in the probe of the TPM devices (TIS and CRB)  there are timeouts of</div><div>750 ms and 30 ms respectively.</div><div><br></div><div>Then, statically disabling TPM and TCG (CONFIG_TCGBIOS) the time spent</div><div>in SeaBIOS goes down from ~846ms to ~56ms:<br></div><div># SeaBIOS disabling CONFIG_TCGBIOS<br>BIOS=/home/stefano/repos/seabios/out_notcgbios/bios.bin</div><div> qemu_init_end: 40.658371<br> fw_start: 40.850395 (+0.192024)<br> fw_do_boot: 96.750142 (+55.899747)<br> linux_start_boot: 98.880578 (+2.130436)<br></div><div><br></div><div>The tpm_setup() is called after the qemu_cfg_init(), so I think we can disable</div><div>this call using some fw_cfg parameters, if we will decide to implement a runtime</div><div>approach.</div><div><br></div><div>Cheers,</div><div>Stefano<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
cheers,<br>
  Gerd<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_-7994209450793706031gmail_signature"><div dir="ltr"><div><span style="font-family:monospace,monospace">Stefano Garzarella</span></div><div><span style="font-family:monospace,monospace">Red Hat</span><br></div></div></div></div></div></div></div></div>