| Message ID | 20160401112027.GD19398@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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.
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
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.
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
> > 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.
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 --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