| Message ID | 20160401114947.GM32728@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Fri, Apr 01, 2016 at 12:49:47PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 01, 2016 at 01:32:51PM +0200, Gerd Hoffmann wrote: > > > I think we were working on the same thing ... Attached is my > > > version. > > > > > > Note that you must enable at least CONFIG_MPTABLE else virtio-scsi > > > does not work in the guest. I also enabled ACPI & SMBIOS & PIRTABLE. > > > > They are enabled by default, no need to explicitly say so ;) > > So they are. Here's a v3 patch. > > I also retested everything from scratch. Previously I was testing the > stock SeaBIOS bios.bin shipped with qemu vs the fast config. However > that has the possible problem that I was testing two slightly > different versions of SeaBIOS (whatever version qemu ships vs > upstream). > > Testing from scratch, using upstream SeaBIOS in both cases, there's > still a significant benefit. SeaBIOS overhead goes from 63 ms down to > 19 ms (saving 44 ms). > > Overall the proportion of boot time of the libguestfs appliance > attributed to SeaBIOS drops from 3.7% to 1.1% (but note this is with > libguestfs & kernel debugging enabled -- for real users there'd be a > much larger percentage drop). > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html > From 8cdf91f13949ab46c6a5804b968400d404c4e00e Mon Sep 17 00:00:00 2001 > From: "Richard W.M. Jones" <rjones@redhat.com> > Date: Fri, 1 Apr 2016 11:35:09 +0100 > Subject: [PATCH] bios: Add fast variant of SeaBIOS for use with -kernel on > x86. > > This commit adds a fast variant of SeaBIOS called 'bios-fast.bin'. > > It's designed to be the fastest (also the smallest, but that's not the > main aim) SeaBIOS that is just enough to boot a Linux kernel using the > -kernel option on i686 and x86_64. > > This commit does not modify the -kernel option to use this. You have > to specify it by doing something like this: > > -kernel vmlinuz -bios bios-fast.bin It's possible to build a third binary, but that seems like it would be a bit annoying for distributions. I think most of the benefit could be obtained by just adding a flag to seabios to have it skip device driver initialization. That's where the majority of the time saved is from. [...] > --- /dev/null > +++ b/roms/config.seabios-fast > @@ -0,0 +1,25 @@ > +# The fastest SeaBIOS that can boot Linux using -kernel. > + > +# general stuff > +CONFIG_QEMU=y > +CONFIG_ROM_SIZE=128 Why force a size of 128K - I would think 64K would be fine. > +CONFIG_XEN=n > +CONFIG_THREADS=n I doubt either of these two would change timing at all. There's no harm in disabling CONFIG_XEN, but I would not recommend disabling CONFIG_THREADS. > +CONFIG_WRITABLE_UPPERMEMORY=y > + > +# 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. > +CONFIG_BOOTMENU=n > +CONFIG_BOOTSPLASH=n These two should have no impact on timing at all. > + > +# hardware support we don't need > +CONFIG_LPT=n > +CONFIG_SERIAL=n > +CONFIG_USB=n [...] > +CONFIG_TCGBIOS=n > +CONFIG_VGAHOOKS=n > + > +# no logging > +CONFIG_DEBUG_LEVEL=0 If you really want to go all out on timing tests, you could disable CONFIG_USE_SMM, and CONFIG_FW_ROMFILE_LOAD. Disabling CONFIG_RELOCATE_INIT may help, but probably not. -Kevin
On 01/04/2016 17:35, Kevin O'Connor wrote: > It's possible to build a third binary, but that seems like it would be > a bit annoying for distributions. I don't think that would be a problem. Fedora is already building 4 binaries (128k, 256k, CSM, coreboot), adding a fifth is not a big deal. Paolo > I think most of the benefit could > be obtained by just adding a flag to seabios to have it skip device > driver initialization. That's where the majority of the time saved is > from.
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. Below are some benchmarks of the other things you mentioned. These are complete appliance boot-to-shutdown times [*not* just SeaBIOS]. All debugging has been disabled, and I'm using a slightly different kernel version, so these runs are not comparable to earlier results I posted. All times are the mean of 10 runs. The ± number is 1 standard deviation from the mean. In my estimation only CONFIG_FW_ROMFILE_LOAD=n seems to make a measurable difference. ---------------------------------------------------------------------- Ordinary qemu SeaBIOS configuration Result: 1227.5ms ±7.7ms -bios boot-fast.bin, as per my previous patch Result: 1113.7ms ±6.4ms Leaving CONFIG_XEN and CONFIG_THREADS at default settings Result: 1111.2ms ±3.8ms CONFIG_USE_SMM=n Result: 1116.0ms ±5.0ms CONFIG_FW_ROMFILE_LOAD=n Result: 1106.6ms ±5.0ms CONFIG_RELOCATE_INIT=n Result: 1104.7ms ±11.2ms ---------------------------------------------------------------------- Rich.
On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote: > Below are some benchmarks of the other things you mentioned. These > are complete appliance boot-to-shutdown times [*not* just SeaBIOS]. > All debugging has been disabled, and I'm using a slightly different > kernel version, so these runs are not comparable to earlier results I > posted. All times are the mean of 10 runs. The ± number is 1 > standard deviation from the mean. > > In my estimation only CONFIG_FW_ROMFILE_LOAD=n seems to make a > measurable difference. > > ---------------------------------------------------------------------- > Ordinary qemu SeaBIOS configuration > Result: 1227.5ms ±7.7ms > > -bios boot-fast.bin, as per my previous patch > Result: 1113.7ms ±6.4ms > > Leaving CONFIG_XEN and CONFIG_THREADS at default settings > Result: 1111.2ms ±3.8ms > > CONFIG_USE_SMM=n > Result: 1116.0ms ±5.0ms > > CONFIG_FW_ROMFILE_LOAD=n > Result: 1106.6ms ±5.0ms > > CONFIG_RELOCATE_INIT=n > Result: 1104.7ms ±11.2ms > ---------------------------------------------------------------------- Actually, CONFIG_RELOCATE_INIT=n looks like it is doing something, but the error bars are quite large. Here's another one that makes a difference: CONFIG_BOOTORDER=n Result: 1099.5ms ±3.7ms (Since we're using -kernel, we don't care about bootorder) Rich.
On Fri, Apr 01, 2016 at 07:59:02PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote: > > Below are some benchmarks of the other things you mentioned. These > > are complete appliance boot-to-shutdown times [*not* just SeaBIOS]. > > All debugging has been disabled, and I'm using a slightly different > > kernel version, so these runs are not comparable to earlier results I > > posted. All times are the mean of 10 runs. The ± number is 1 > > standard deviation from the mean. > > > > In my estimation only CONFIG_FW_ROMFILE_LOAD=n seems to make a > > measurable difference. > > > > ---------------------------------------------------------------------- > > Ordinary qemu SeaBIOS configuration > > Result: 1227.5ms ±7.7ms > > > > -bios boot-fast.bin, as per my previous patch > > Result: 1113.7ms ±6.4ms > > > > Leaving CONFIG_XEN and CONFIG_THREADS at default settings > > Result: 1111.2ms ±3.8ms > > > > CONFIG_USE_SMM=n > > Result: 1116.0ms ±5.0ms > > > > CONFIG_FW_ROMFILE_LOAD=n > > Result: 1106.6ms ±5.0ms > > > > CONFIG_RELOCATE_INIT=n > > Result: 1104.7ms ±11.2ms > > ---------------------------------------------------------------------- > > Actually, CONFIG_RELOCATE_INIT=n looks like it is doing something, but > the error bars are quite large. > > Here's another one that makes a difference: > > CONFIG_BOOTORDER=n > Result: 1099.5ms ±3.7ms Are you sure you had CONFIG_DEBUG_LEVEL=0? Otherwise, it doesn't make sense that disabling CONFIG_BOOTORDER=n would change the boot time. Disabling CONFIG_DEBUG_SERIAL is not enough, because SeaBIOS also writes to port 0x402 as an internal debugging mechanism. -Kevin
On Fri, Apr 01, 2016 at 03:04:15PM -0400, Kevin O'Connor wrote: > On Fri, Apr 01, 2016 at 07:59:02PM +0100, Richard W.M. Jones wrote: > > On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote: > > > Below are some benchmarks of the other things you mentioned. These > > > are complete appliance boot-to-shutdown times [*not* just SeaBIOS]. > > > All debugging has been disabled, and I'm using a slightly different > > > kernel version, so these runs are not comparable to earlier results I > > > posted. All times are the mean of 10 runs. The ± number is 1 > > > standard deviation from the mean. > > > > > > In my estimation only CONFIG_FW_ROMFILE_LOAD=n seems to make a > > > measurable difference. > > > > > > ---------------------------------------------------------------------- > > > Ordinary qemu SeaBIOS configuration > > > Result: 1227.5ms ±7.7ms > > > > > > -bios boot-fast.bin, as per my previous patch > > > Result: 1113.7ms ±6.4ms > > > > > > Leaving CONFIG_XEN and CONFIG_THREADS at default settings > > > Result: 1111.2ms ±3.8ms > > > > > > CONFIG_USE_SMM=n > > > Result: 1116.0ms ±5.0ms > > > > > > CONFIG_FW_ROMFILE_LOAD=n > > > Result: 1106.6ms ±5.0ms > > > > > > CONFIG_RELOCATE_INIT=n > > > Result: 1104.7ms ±11.2ms > > > ---------------------------------------------------------------------- > > > > Actually, CONFIG_RELOCATE_INIT=n looks like it is doing something, but > > the error bars are quite large. > > > > Here's another one that makes a difference: > > > > CONFIG_BOOTORDER=n > > Result: 1099.5ms ±3.7ms > > Are you sure you had CONFIG_DEBUG_LEVEL=0? Yes, I'm pretty sure. I'm using qemu with -bios bios-fast.bin, and recompiling SeaBIOS under qemu each time (make && make -C roms bios). The test program is: https://github.com/libguestfs/libguestfs/commit/96ce2f9afedc6a7ecb2f7781958c3940255f453b > Otherwise, it doesn't make > sense that disabling CONFIG_BOOTORDER=n would change the boot time. Could it be explained by it avoiding slow access to qemu fw_cfg? > Disabling CONFIG_DEBUG_SERIAL is not enough, because SeaBIOS also > writes to port 0x402 as an internal debugging mechanism. Rich.
On Fri, Apr 01, 2016 at 08:10:48PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 01, 2016 at 03:04:15PM -0400, Kevin O'Connor wrote: > > Otherwise, it doesn't make > > sense that disabling CONFIG_BOOTORDER=n would change the boot time. > > Could it be explained by it avoiding slow access to qemu fw_cfg? Also, disabling CONFIG_BOOTORDER means that CONFIG_BOOT is disabled, since CONFIG_BOOTMENU and CONFIG_BOOTSPLASH were also disabled, and those are the only other things requiring CONFIG_BOOT. Could that explain it? Rich.
On Fri, Apr 01, 2016 at 08:15:29PM +0100, Richard W.M. Jones wrote: > On Fri, Apr 01, 2016 at 08:10:48PM +0100, Richard W.M. Jones wrote: > > On Fri, Apr 01, 2016 at 03:04:15PM -0400, Kevin O'Connor wrote: > > > Otherwise, it doesn't make > > > sense that disabling CONFIG_BOOTORDER=n would change the boot time. > > > > Could it be explained by it avoiding slow access to qemu fw_cfg? No, because fw_cfg isn't slow with DMA. It's just one additional memory transfer of a file that's under a kilobyte. > Also, disabling CONFIG_BOOTORDER means that CONFIG_BOOT is disabled, > since CONFIG_BOOTMENU and CONFIG_BOOTSPLASH were also disabled, and > those are the only other things requiring CONFIG_BOOT. Could that > explain it? Disabling CONFIG_BOOTORDER does not disable CONFIG_BOOT - it only controls some internal sorting of bootable devices - of which there are none when CONFIG_DRIVES=n - so I don't see why it would have an impact. My understanding of SeaBIOS times is that it is overwhelmingly dominated by (virtual) hardware accesses. Specifically, when hardware is touched it causes a VM-exit which takes time. That's why debugging is slow (and why serial debugging is slow) - it's nothing in SeaBIOS that causes it to be slow, it's purely the number of IO accesses. The CONFIG_BOOTORDER option doesn't meaningfully alter the number of IO accesses, so it's puzzling that it would have an impact on boot time. Perhaps you could send me the actual seabios .config file of the test run with and without CONFIG_BOOTORDER. I'll also try to reproduce locally. Thanks, -Kevin
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 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. Another consumer of time is ACPI table deployment. I wonder if you could get similar results by running QEMU with "-no-acpi"? 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, -Kevin
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.
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
On 01/04/2016 22:05, Kevin O'Connor wrote: > > 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? No, it's not possible because target numbers are arbitrary. We can submit all 256 requests at the same time perhaps. Paolo
On Fri, Apr 01, 2016 at 06:25:24PM -0400, Kevin O'Connor wrote: > 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. Indeed - I have retested everything in the cold light of day, and it does save time. SeaBIOS master branch from current git: Result: 974.2ms ±2.0ms Result: 988.5ms ±11.3ms Result: 974.9ms ±7.3ms SeaBIOS KevinOConnor/testing branch: Result: 942.5ms ±4.2ms Result: 930.0ms ±2.1ms Result: 934.7ms ±3.4ms (Note these times are not comparable with the previous ones, because in a parallel set of investigations I've disabled libvirt and am running qemu directly, so there is no libvirt overhead.) Thanks, Rich.
diff --git a/Makefile b/Makefile index 1d076a9..c4e939d 100644 --- a/Makefile +++ b/Makefile @@ -389,7 +389,8 @@ common de-ch es fo fr-ca hu ja mk nl-be pt sl tr \ bepo cz ifdef INSTALL_BLOBS -BLOBS=bios.bin bios-256k.bin sgabios.bin vgabios.bin vgabios-cirrus.bin \ +BLOBS=bios.bin bios-256k.bin bios-fast.bin \ +sgabios.bin vgabios.bin vgabios-cirrus.bin \ vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin vgabios-virtio.bin \ acpi-dsdt.aml \ ppc_rom.bin openbios-sparc32 openbios-sparc64 openbios-ppc QEMU,tcx.bin QEMU,cgthree.bin \ diff --git a/roms/Makefile b/roms/Makefile index 7bd1252..26b0586 100644 --- a/roms/Makefile +++ b/roms/Makefile @@ -61,9 +61,11 @@ default: @echo " slof -- update slof.bin" @echo " u-boot.e500 -- update u-boot.e500" -bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k +bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k \ + build-seabios-config-seabios-fast cp seabios/builds/seabios-128k/bios.bin ../pc-bios/bios.bin cp seabios/builds/seabios-256k/bios.bin ../pc-bios/bios-256k.bin + cp seabios/builds/seabios-fast/bios.bin ../pc-bios/bios-fast.bin seavgabios: $(patsubst %,seavgabios-%,$(vgabios_variants)) diff --git a/roms/config.seabios-fast b/roms/config.seabios-fast new file mode 100644 index 0000000..f035b49 --- /dev/null +++ b/roms/config.seabios-fast @@ -0,0 +1,25 @@ +# The fastest SeaBIOS that can boot Linux using -kernel. + +# general stuff +CONFIG_QEMU=y +CONFIG_ROM_SIZE=128 +CONFIG_XEN=n +CONFIG_THREADS=n +CONFIG_WRITABLE_UPPERMEMORY=y + +# no input, no boot menu +CONFIG_MOUSE=n +CONFIG_KEYBOARD=n +CONFIG_BOOTMENU=n +CONFIG_BOOTSPLASH=n + +# hardware support we don't need +CONFIG_LPT=n +CONFIG_SERIAL=n +CONFIG_USB=n +CONFIG_DRIVES=n +CONFIG_TCGBIOS=n +CONFIG_VGAHOOKS=n + +# no logging +CONFIG_DEBUG_LEVEL=0