diff mbox

Why is SeaBIOS used with -kernel?

Message ID 20160401112027.GD19398@redhat.com
State New
Headers show

Commit Message

Richard W.M. Jones April 1, 2016, 11:20 a.m. UTC 
My patch, plus the configuration and comments from your patch,
combined.  Plus I tested it with libguestfs boot-analysis and it works
and is still fast.

Integrating this so it happens automatically when the user adds
-kernel on x86 seems quite complicated.  The only way I could do it
was by adding #ifdef defined(__x86_64__) etc to vl.c, which doesn't
seem very nice.  The problem is the machine type code doesn't know
that you're using -kernel.

Rich.

Comments

Paolo Bonzini April 1, 2016, 11:21 a.m. UTC | #1 
On 01/04/2016 13:20, Richard W.M. Jones wrote:
> +# MPTABLE is required by Linux kernel, the others add only a
> +# couple of milliseconds so we might as well have them
> +CONFIG_PIRTABLE=y
> +CONFIG_MPTABLE=y
> +CONFIG_SMBIOS=y
> +CONFIG_ACPI=y
> +

MPTABLE is only required is you don't have ACPI.

Paolo
Richard W.M. Jones April 1, 2016, 11:26 a.m. UTC | #2 
On Fri, Apr 01, 2016 at 01:21:38PM +0200, Paolo Bonzini wrote:
> 
> 
> On 01/04/2016 13:20, Richard W.M. Jones wrote:
> > +# MPTABLE is required by Linux kernel, the others add only a
> > +# couple of milliseconds so we might as well have them
> > +CONFIG_PIRTABLE=y
> > +CONFIG_MPTABLE=y
> > +CONFIG_SMBIOS=y
> > +CONFIG_ACPI=y
> > +
> 
> MPTABLE is only required is you don't have ACPI.

True .. however for speed reasons libguestfs uses acpi=off.  It saves
us about 190 ms.  So we need MPTABLE.

Rich.
Kevin Wolf April 5, 2016, 4:38 a.m. UTC | #3 
Am 01.04.2016 um 13:20 hat Richard W.M. Jones geschrieben:
> 
> My patch, plus the configuration and comments from your patch,
> combined.  Plus I tested it with libguestfs boot-analysis and it works
> and is still fast.
> 
> Integrating this so it happens automatically when the user adds
> -kernel on x86 seems quite complicated.  The only way I could do it
> was by adding #ifdef defined(__x86_64__) etc to vl.c, which doesn't
> seem very nice.  The problem is the machine type code doesn't know
> that you're using -kernel.

I would actually find it rather surprising to get differernt BIOSes and
therefore potentially different behaviour for -kernel and for booting
from an image. Even if we made sure that Linux really never touches the
parts that you disable in bios-fast.bin, remember that -kernel is not
only for Linux, but for arbitrary kernels.

Requiring an explicit -bios option like you do now seems to make most
sense to me: The default behaves the same as a normal boot, but if you
are one of the cases that do need that additional boot speed, you can do
that and consciously sacrifice the features.

Kevin
Richard W.M. Jones April 5, 2016, 8:04 a.m. UTC | #4 
On Tue, Apr 05, 2016 at 06:38:36AM +0200, Kevin Wolf wrote:
> Am 01.04.2016 um 13:20 hat Richard W.M. Jones geschrieben:
> > 
> > My patch, plus the configuration and comments from your patch,
> > combined.  Plus I tested it with libguestfs boot-analysis and it works
> > and is still fast.
> > 
> > Integrating this so it happens automatically when the user adds
> > -kernel on x86 seems quite complicated.  The only way I could do it
> > was by adding #ifdef defined(__x86_64__) etc to vl.c, which doesn't
> > seem very nice.  The problem is the machine type code doesn't know
> > that you're using -kernel.
> 
> I would actually find it rather surprising to get differernt BIOSes and
> therefore potentially different behaviour for -kernel and for booting
> from an image. Even if we made sure that Linux really never touches the
> parts that you disable in bios-fast.bin, remember that -kernel is not
> only for Linux, but for arbitrary kernels.
> 
> Requiring an explicit -bios option like you do now seems to make most
> sense to me: The default behaves the same as a normal boot, but if you
> are one of the cases that do need that additional boot speed, you can do
> that and consciously sacrifice the features.

OK so this reminds me of the second problem.  How to detect what
bioses are available, given a qemu binary.  It would be nice if qemu
had an option like:

  qemu -bios \?

Of course we can try to scan /usr/share/qemu/bios.*, except that
Fedora installs extra ROMs in /usr/share/seabios/ (I'm not exactly
sure how qemu deals with those), and the path is different for other
distros and other qemu binaries.

Rich.
Kevin Wolf April 5, 2016, 8:11 a.m. UTC | #5 
Am 05.04.2016 um 10:04 hat Richard W.M. Jones geschrieben:
> On Tue, Apr 05, 2016 at 06:38:36AM +0200, Kevin Wolf wrote:
> > Am 01.04.2016 um 13:20 hat Richard W.M. Jones geschrieben:
> > > 
> > > My patch, plus the configuration and comments from your patch,
> > > combined.  Plus I tested it with libguestfs boot-analysis and it works
> > > and is still fast.
> > > 
> > > Integrating this so it happens automatically when the user adds
> > > -kernel on x86 seems quite complicated.  The only way I could do it
> > > was by adding #ifdef defined(__x86_64__) etc to vl.c, which doesn't
> > > seem very nice.  The problem is the machine type code doesn't know
> > > that you're using -kernel.
> > 
> > I would actually find it rather surprising to get differernt BIOSes and
> > therefore potentially different behaviour for -kernel and for booting
> > from an image. Even if we made sure that Linux really never touches the
> > parts that you disable in bios-fast.bin, remember that -kernel is not
> > only for Linux, but for arbitrary kernels.
> > 
> > Requiring an explicit -bios option like you do now seems to make most
> > sense to me: The default behaves the same as a normal boot, but if you
> > are one of the cases that do need that additional boot speed, you can do
> > that and consciously sacrifice the features.
> 
> OK so this reminds me of the second problem.  How to detect what
> bioses are available, given a qemu binary.  It would be nice if qemu
> had an option like:
> 
>   qemu -bios \?
> 
> Of course we can try to scan /usr/share/qemu/bios.*, except that
> Fedora installs extra ROMs in /usr/share/seabios/ (I'm not exactly
> sure how qemu deals with those), and the path is different for other
> distros and other qemu binaries.

At least in RHEL, /usr/share/qemu-kvm/bios.* seems to have symlinks
pointing to the binaries in /usr/share/seabios/. And I would assume that
that's the only directory besides the working directory where qemu looks
for the files.

Kevin
Richard W.M. Jones April 5, 2016, 9:19 a.m. UTC | #6 
> > OK so this reminds me of the second problem.  How to detect what
> > bioses are available, given a qemu binary.  It would be nice if qemu
> > had an option like:
> > 
> >   qemu -bios \?

I didn't really think this one through.  The extra time taken (in the
link loader) to run the above query command will be greater than the
time saved with the faster BIOS.  I'm still looking at the loader
problem.

Rich.
Kevin Wolf April 5, 2016, 9:26 a.m. UTC | #7 
Am 05.04.2016 um 11:19 hat Richard W.M. Jones geschrieben:
> > > OK so this reminds me of the second problem.  How to detect what
> > > bioses are available, given a qemu binary.  It would be nice if qemu
> > > had an option like:
> > > 
> > >   qemu -bios \?
> 
> I didn't really think this one through.  The extra time taken (in the
> link loader) to run the above query command will be greater than the
> time saved with the faster BIOS.  I'm still looking at the loader
> problem.

For all practical matters, why can't you make it a build time option?
The binary would hardcode bios-fast.bin and just set the dependencies of
the libguestfs package to a new enough qemu.

Kevin
diff mbox

Patch

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..fbb1ef8
--- /dev/null
+++ b/roms/config.seabios-fast
@@ -0,0 +1,32 @@ 
+# 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
+
+# MPTABLE is required by Linux kernel, the others add only a
+# couple of milliseconds so we might as well have them
+CONFIG_PIRTABLE=y
+CONFIG_MPTABLE=y
+CONFIG_SMBIOS=y
+CONFIG_ACPI=y
+
+# no logging
+CONFIG_DEBUG_LEVEL=0