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

["Richard W.M. Jones" <rjones@redhat.com>]

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

> Another consumer of time is ACPI table deployment.  I wonder if you
> could get similar results by running QEMU with "-no-acpi"?

No apparent difference:

Stock qemu SeaBIOS:

Result: 1211.5ms ±4.8ms

Stock qemu SeaBIOS + qemu -no-acpi:

Result: 1213.9ms ±6.5ms

> Beyond that, I think the only other big time consumers of the default
> seabios is debug messages.  If so, then I think we can come up with a
> way to limit these debug messages in SeaBIOS.
> 
> The SeaBIOS testing patches are at:
> 
>   https://github.com/KevinOConnor/seabios/tree/testing

Thanks,
Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org