Re: [Qemu-devel] Why is SeaBIOS used with -kernel?

[Kevin O'Connor <kevin@koconnor.net>]

On Fri, Apr 01, 2016 at 09:46:05PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 04:05:46PM -0400, Kevin O'Connor wrote:
> > On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote:
> > > On Fri, Apr 01, 2016 at 11:35:40AM -0400, Kevin O'Connor wrote:
> > > > > +# general stuff
> > > > > +CONFIG_QEMU=y
> > > > > +CONFIG_ROM_SIZE=128
> > > > 
> > > > Why force a size of 128K - I would think 64K would be fine.
> > > 
> > > Agreed.  Setting this to =0 seems the best thing, and it does fit fine
> > > inside 64K.
> > > 
> > > > > +# no input, no boot menu
> > > > > +CONFIG_MOUSE=n
> > > > > +CONFIG_KEYBOARD=n
> > > > [...]
> > > > > +CONFIG_DRIVES=n
> > > > 
> > > > I would not recommended disabling CONFIG_MOUSE, CONFIG_KEYBOARD,
> > > > CONFIG_DRIVES - I only had those in my config so as to avoid having to
> > > > specify all the device drivers.  Ideally these would remain on and the
> > > > individual device drivers would be disabled.
> > > 
> > > We are always use this in a virtual appliance.  Interaction with the
> > > user is both impossible and undesirable.  It either boots or not, and
> > > the whole appliance is discarded in seconds.  We're always using
> > > -kernel with this SeaBIOS build, so probing drives is never needed.
> > 
> > Okay, but if it doesn't change the boot time, then it would be nicer
> > to use a standard rom for all boots.
> 
> I don't think I know which option (or options) make the boot faster,
> but bios-fast.bin is certainly much faster than the qemu standard
> bios.bin -- no amount of variability in the test framework would
> account for that huge difference of 44ms.
> 
> I had convinced myself before that maybe CONFIG_DRIVES=n was the
> factor, but that setting alone doesn't actually make much difference:
> 
> bios-fast.bin (CONFIG_DRIVES=n):
> 
> Result: 1093.3ms ±3.4ms
> Result: 1100.6ms ±8.9ms
> 
> bios-fast.bin + CONFIG_DRIVES=y:
> 
> Result: 1100.3ms ±8.4ms
> Result: 1101.7ms ±1.2ms
> 
> It could be just one setting or an accumulation of several settings.
> At some point I may have the patience to try each one but probably not
> late on Friday night :-/
> 
> > I looked closer at your setup and it appears the SeaBIOS virtio-scsi
> > driver is very slow because it does a full search of all 256 possible
> > scsi targets.  This full scan takes a lot of time.  I put together a
> > quick patch (see below) to stop the scan early.  Gerd/Paulo, do you
> > know if what I've done is valid and/or if there is a better way we can
> > limit the virtio-scsi scan?
> > 
> > I also found a way to reduce the overhead of the "shadow ram" code a
> > little.  I have a patch (see below) for that as well.
> 
> I would say the patches on the KevinOConnor/testing branch don't make
> any measurable difference.
> 
> Stock qemu SeaBIOS:
> 
> Result: 1218.6ms ±1.0ms
> Result: 1214.1ms ±0.0ms
> 
> KevinOConnor/testing branch:
> 
> Result: 1221.9ms ±0.5ms
> Result: 1216.4ms ±0.2ms

I'm getting different results.  When you have time we should probably
track down the discrepancy.  Some of the difference is likely due to
different hardware (I'm using kvm on an old AMD machine) and some is
likely due to different test methodology (I'm timing SeaBIOS debug
output).  However, the changes on that testing branch reliably improve
the boot by 70ms for me when there is a virtio-scsi device present.

Have a good weekend.
-Kevin