From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am5xM-0000Vx-LN for qemu-devel@nongnu.org; Fri, 01 Apr 2016 16:46:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1am5xI-00024z-Cy for qemu-devel@nongnu.org; Fri, 01 Apr 2016 16:46:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am5xI-00024t-57 for qemu-devel@nongnu.org; Fri, 01 Apr 2016 16:46:08 -0400 Date: Fri, 1 Apr 2016 21:46:05 +0100 From: "Richard W.M. Jones" Message-ID: <20160401204605.GR32728@redhat.com> References: <20160401084456.GF32728@redhat.com> <1459502310.7011.37.camel@redhat.com> <20160401101733.GI32728@redhat.com> <1459508875.7011.62.camel@redhat.com> <20160401111139.GK32728@redhat.com> <1459510371.7011.63.camel@redhat.com> <20160401114947.GM32728@redhat.com> <20160401153540.GD25490@morn.lan> <20160401184131.GP32728@redhat.com> <20160401200546.GA19187@morn.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20160401200546.GA19187@morn.lan> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Why is SeaBIOS used with -kernel? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: marc.mari.barcelo@gmail.com, Paolo Bonzini , qemu-devel@nongnu.org, Gerd Hoffmann , Stefan Hajnoczi 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=3Dy > > > > +CONFIG_ROM_SIZE=3D128 > > >=20 > > > Why force a size of 128K - I would think 64K would be fine. > >=20 > > Agreed. Setting this to =3D0 seems the best thing, and it does fit f= ine > > inside 64K. > >=20 > > > > +# no input, no boot menu > > > > +CONFIG_MOUSE=3Dn > > > > +CONFIG_KEYBOARD=3Dn > > > [...] > > > > +CONFIG_DRIVES=3Dn > > >=20 > > > 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. > >=20 > > 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. >=20 > 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=3Dn was the factor, but that setting alone doesn't actually make much difference: bios-fast.bin (CONFIG_DRIVES=3Dn): Result: 1093.3ms =B13.4ms Result: 1100.6ms =B18.9ms bios-fast.bin + CONFIG_DRIVES=3Dy: Result: 1100.3ms =B18.4ms Result: 1101.7ms =B11.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? >=20 > 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 =B11.0ms Result: 1214.1ms =B10.0ms KevinOConnor/testing branch: Result: 1221.9ms =B10.5ms Result: 1216.4ms =B10.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 =B14.8ms Stock qemu SeaBIOS + qemu -no-acpi: Result: 1213.9ms =B16.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. >=20 > The SeaBIOS testing patches are at: >=20 > https://github.com/KevinOConnor/seabios/tree/testing Thanks, Rich. --=20 Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rj= ones 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