[SeaBIOS] Reducing SeaBIOS kernel entry time
Hi, qboot (https://github.com/bonzini/qboot) is a stripped down firmware providing only what is needed to boot a Linux kernel on x86. I wonder if there is room to achieve similar results with SeaBIOS for the lightweight virtual machine use case. The goal is to enter the kernel within 20 milliseconds. (That's the number I measured with qboot.) Kevin: Have you looked at SeaBIOS startup time and do you think this use case is within the scope of what SeaBIOS is intended for? Marc is beginning to profile boot times and any pointers would be helpful. Thanks, Stefan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
Stefan Hajnoczi wrote: > Hi, > qboot (https://github.com/bonzini/qboot) is a stripped down firmware > providing only what is needed to boot a Linux kernel on x86. Incredible, you have re-invented coreboot! Well, maybe not, it is Red Hat after all. How about putting your efforts into the existing project instead, that way you can also draw on the significant experience within that project. If you want to optimize for the Linux special case then you should not be using anything BIOS-related at all. Try coreboot with kernel as payload. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On 03/07/2015 11:43, Peter Stuge wrote: > > Hi, > > qboot (https://github.com/bonzini/qboot) is a stripped down firmware > > providing only what is needed to boot a Linux kernel on x86. > > Incredible, you have re-invented coreboot! I'm pretty sure I didn't, unless you count reusing the cbfs format as reinventing coreboot. > Well, maybe not, it is Red Hat after all. > > How about putting your efforts into the existing project instead, > that way you can also draw on the significant experience within > that project. > > If you want to optimize for the Linux special case then you should > not be using anything BIOS-related at all. Indeed qboot is not a BIOS, it only provides a couple 16-bit services that Linux needs (e820 and int 10h tty write). > Try coreboot with kernel as payload. Tried that. Coreboot takes about 250 ms to pass control to the payload, and there's hardly any option to remove unnecessary hardware setup. SeaBIOS takes 165 ms with a vanilla configuration, but there are options to remove unnecessary drivers. qboot takes 20 ms. Paolo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On Fri, Jul 03, 2015 at 10:33:56AM +0100, Stefan Hajnoczi wrote: > Hi, > qboot (https://github.com/bonzini/qboot) is a stripped down firmware > providing only what is needed to boot a Linux kernel on x86. I wonder > if there is room to achieve similar results with SeaBIOS for the > lightweight virtual machine use case. > > The goal is to enter the kernel within 20 milliseconds. (That's the > number I measured with qboot.) > > Kevin: Have you looked at SeaBIOS startup time and do you think this > use case is within the scope of what SeaBIOS is intended for? > > Marc is beginning to profile boot times and any pointers would be helpful. Hi Stefan, I took a look a month or so ago: http://article.gmane.org/gmane.comp.emulators.kvm.devel/136207 Last test I ran I had SeaBIOS down to 16ms (not including the time to deploy or jump to the linux kernel). More reductions are also possible - the above was just with Kconfig settings. Let me know if you want more info on how I did that. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On Fri, Jul 03, 2015 at 11:43:22AM +0200, Peter Stuge wrote: > If you want to optimize for the Linux special case then you should > not be using anything BIOS-related at all. There seems to be a common misunderstanding that supporting the BIOS negatively impacts boot times. This is not so - the BIOS is just a library of functions in memory - they do not materially impact the boot time if they are not used. Instead, boot times are dominated by hardware initialization delays. (I've run many tests, and I've found the core SeaBIOS code does not add more than 1 or 2 ms to the boot time - at most.) And, SeaBIOS is actually quite good at optimizing hardware initialization time by using its "thread" system (really coroutines). -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On Fri, Jul 3, 2015 at 10:43 AM, Peter Stuge wrote: > If you want to optimize for the Linux special case then you should > not be using anything BIOS-related at all. Good idea. The 32-bit or 64-bit kernel entry point should be used instead of the 16-bit entry point. My reading of Linux Documentation/x86/boot.txt and arch/x86/boot/ is that the 32-bit entry point bypasses the BIOS interrupts. The loader must provide the e820 map and edd info in the Linux boot_params struct. > Try coreboot with kernel as payload. Coreboot does seem more appropriate than SeaBIOS if the BIOS interface is avoided entirely. The question is how much the 250 ms kernel entry time that Paolo mentioned can be reduced... Stefan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On Fri, Jul 3, 2015 at 2:13 PM, Kevin O'Connor wrote: > On Fri, Jul 03, 2015 at 10:33:56AM +0100, Stefan Hajnoczi wrote: >> Hi, >> qboot (https://github.com/bonzini/qboot) is a stripped down firmware >> providing only what is needed to boot a Linux kernel on x86. I wonder >> if there is room to achieve similar results with SeaBIOS for the >> lightweight virtual machine use case. >> >> The goal is to enter the kernel within 20 milliseconds. (That's the >> number I measured with qboot.) >> >> Kevin: Have you looked at SeaBIOS startup time and do you think this >> use case is within the scope of what SeaBIOS is intended for? >> >> Marc is beginning to profile boot times and any pointers would be helpful. > > Hi Stefan, > > I took a look a month or so ago: > > http://article.gmane.org/gmane.comp.emulators.kvm.devel/136207 > > Last test I ran I had SeaBIOS down to 16ms (not including the time to > deploy or jump to the linux kernel). More reductions are also > possible - the above was just with Kconfig settings. > > Let me know if you want more info on how I did that. That sounds interesting. Do you have a .config or git branch? Stefan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On Fri, Jul 03, 2015 at 03:12:14PM +0100, Stefan Hajnoczi wrote:
> On Fri, Jul 3, 2015 at 2:13 PM, Kevin O'Connor wrote:
> > I took a look a month or so ago:
> >
> > http://article.gmane.org/gmane.comp.emulators.kvm.devel/136207
> >
> > Last test I ran I had SeaBIOS down to 16ms (not including the time to
> > deploy or jump to the linux kernel). More reductions are also
> > possible - the above was just with Kconfig settings.
> >
> > Let me know if you want more info on how I did that.
>
> That sounds interesting. Do you have a .config or git branch?
See attached SeaBIOS config. I profiled the results following the
directions at:
http://www.seabios.org/Debugging#Timing_debug_messages
The QEMU command line I used is:
qemu-system-x86_64 -k en-us -snapshot -L test -chardev
pipe,path=qemudebugpipe,id=seabios -device
isa-debugcon,iobase=0x402,chardev=seabios -enable-kvm
To get to these low start times (~16ms on my old AMD system) I
disabled debug messages in SeaBIOS. (The debug messages themselves
take a few milliseconds.) So, in order to do profiling via the debug
output, I manually added two small debug port writes (see seabios
patch below). I end up seeing results like this on my machine:
=== Sat Jul 4 13:36:25 2015 (adjust=0.0us)
00.000: 1
00.014: 2
00.015: 2
As discussed in the thread linked to above, these numbers could be
improved further by making code changes (to seabios and/or qemu).
These tests were just with minimal seabios Kconfig changes.
Finally, note that this SeaBIOS setup is so stripped down that it
can't actually boot an OS. The goal of the experiment was to time
SeaBIOS to the point where one could add an optimized Linux deployment
scheme to SeaBIOS - such as Paolo's idea of putting a kernel in a
"flash" based memory mapped region. Thus, the seabios numbers above
would also need to include the cost of the kernel deployment and
launching, as well as the qemu startup costs, in order for them to be
truly meaningful.
-Kevin
--- a/src/boot.c
+++ b/src/boot.c
@@ -714,6 +714,7 @@ do_boot(int seq_nr)
if (seq_nr >= BEVCount)
boot_fail();
+outb('2', 0x402); outb('\n', 0x402);
// Boot the given BEV type.
struct bev_s *ie = &BEV[seq_nr];
switch (ie->type) {
diff --git a/src/post.c b/src/post.c
index 6157b50..9fd5f8f 100644
--- a/src/post.c
+++ b/src/post.c
@@ -329,6 +329,7 @@ handle_post(void)
{
if (!CONFIG_QEMU && !CONFIG_COREBOOT)
return;
+outb('1', 0x402); outb('\n', 0x402);
serial_debug_preinit();
debug_banner();
#
# Automatically generated file; DO NOT EDIT.
# SeaBIOS Configuration
#
#
# General Features
#
# CONFIG_COREBOOT is not set
CONFIG_QEMU=y
# CONFIG_CSM is not set
CONFIG_QEMU_HARDWARE=y
# CONFIG_XEN is not set
# CONFIG_THREADS is not set
# CONFIG_RELOCATE_INIT is not set
# CONFIG_BOOTMENU is not set
# CONFIG_BOOTORDER is not set
CONFIG_ENTRY_EXTRASTACK=y
CONFIG_MALLOC_UPPERMEMORY=y
CONFIG_ROM_SIZE=0
#
# Hardware support
#
# CONFIG_ATA is not set
# CONFIG_AHCI is not set
# CONFIG_SDCARD is not set
# CONFIG_VIRTIO_BLK is not set
# CONFIG_VIRTIO_SCSI is not set
# CONFIG_PVSCSI is not set
# CONFIG_ESP_SCSI is not set
# CONFIG_LSI_SCSI is not set
# CONFIG_MEGASAS is not set
# CONFIG_FLOPPY is not set
# CONFIG_PS2PORT is not set
# CONFIG_USB is not set
# CONFIG_SERIAL is not set
# CONFIG_LPT is not set
# CONFIG_USE_SMM is not set
CONFIG_MTRR_INIT=y
CONFIG_PMTIMER=y
#
# BIOS interfaces
#
CONFIG_DRIVES=y
CONFIG_CDROM_BOOT=y
CONFIG_CDROM_EMU=y
CONFIG_PCIBIOS=y
CONFIG_APMBIOS=y
CONFIG_PNPBIOS=y
# CONFIG_OPTIONROMS is not set
CONFIG_BOOT=y
CONFIG_KEYBOARD=y
CONFIG_KBD_CALL_INT15_4F=y
CONFIG_MOUSE=y
CONFIG_S3_RESUME=y
# CONFIG_VGAHOOKS is not set
# CONFIG_DISABLE_A20 is not set
CONFIG_WRITABLE_UPPERMEMORY=y
# CONFIG_TCGBIOS is not set
#
# BIOS Tables
#
# CONFIG_PIRTABLE is not set
# CONFIG_MPTABLE is not set
# CONFIG_SMBIOS is not set
# CONFIG_ACPI is not set
# CONFIG_FW_ROMFILE_LOAD is not set
#
# VGA ROM
#
CONFIG_NO_VGABIOS=y
# CONFIG_VGA_STANDARD_VGA is not set
# CONFIG_VGA_CIRRUS is not set
# CONFIG_VGA_BOCHS is not set
# CONFIG_VGA_GEODEGX2 is not set
# CONFIG_VGA_GEODELX is not set
# CONFIG_BUILD_VGABIOS is not set
CONFIG_VGA_EXTRA_STACK_SIZE=512
#
# Debugging
#
CONFIG_DEBUG_LEVEL=0
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On Sat, Jul 4, 2015 at 6:57 PM, Kevin O'Connor wrote: > On Fri, Jul 03, 2015 at 03:12:14PM +0100, Stefan Hajnoczi wrote: >> On Fri, Jul 3, 2015 at 2:13 PM, Kevin O'Connor wrote: >> > I took a look a month or so ago: >> > >> > http://article.gmane.org/gmane.comp.emulators.kvm.devel/136207 >> > >> > Last test I ran I had SeaBIOS down to 16ms (not including the time to >> > deploy or jump to the linux kernel). More reductions are also >> > possible - the above was just with Kconfig settings. >> > >> > Let me know if you want more info on how I did that. >> >> That sounds interesting. Do you have a .config or git branch? > > See attached SeaBIOS config. I profiled the results following the > directions at: > > http://www.seabios.org/Debugging#Timing_debug_messages Thanks, we'll share the results we get. Stefan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On Wed, 8 Jul 2015 09:10:14 +0100 Stefan Hajnoczi wrote: > On Sat, Jul 4, 2015 at 6:57 PM, Kevin O'Connor > wrote: > > On Fri, Jul 03, 2015 at 03:12:14PM +0100, Stefan Hajnoczi wrote: > >> On Fri, Jul 3, 2015 at 2:13 PM, Kevin O'Connor > >> wrote: > >> > I took a look a month or so ago: > >> > > >> > http://article.gmane.org/gmane.comp.emulators.kvm.devel/136207 > >> > > >> > Last test I ran I had SeaBIOS down to 16ms (not including the > >> > time to deploy or jump to the linux kernel). More reductions > >> > are also possible - the above was just with Kconfig settings. > >> > I've been measuring the time for different configurations and setups. The conclusion is that the main bottleneck to boot QEMU is fw_cfg. Running a default SeaBIOS configuration gives these times (in seconds): (QEMU startup time is the time between the execution and the first kvm_entry, BIOS startup time is the time between the first kvm_entry and the ROM booting, and fw_cfg is the time between the ROM booting and the jump to the Linux kernel). QEMU startup time: .033 BIOS startup time: .154 fw_cfg setup time: .375 And these results are more or less the same in QBoot, when using fw_cfg: QEMU startup time: .026 BIOS startup time: .013 fw_cfg setup time: .373 The difference between SeaBIOS and QBoot is big, but, as I said, this SeaBIOS is not stripped-down. Using the .config that Kevin sent, I can get .01 seconds, but I cannot boot a ROM (I still have to play with the configuration options until it boots). Probably it can do it in less than 20 msec, which not far from QBoot. On the other side, QBoot with cbfs can boot really fast: QEMU startup time: .027 Kernel setup time: .017 Total time: .045 And I'll check CoreBoot once more, to try to figure out why it takes so long. Thanks Marc ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On Wed, Jul 08, 2015 at 03:44:33PM +0200, Marc Marí wrote:
> On Wed, 8 Jul 2015 09:10:14 +0100
> Stefan Hajnoczi wrote:
>
> > On Sat, Jul 4, 2015 at 6:57 PM, Kevin O'Connor
> > wrote:
> > > On Fri, Jul 03, 2015 at 03:12:14PM +0100, Stefan Hajnoczi wrote:
> > >> On Fri, Jul 3, 2015 at 2:13 PM, Kevin O'Connor
> > >> wrote:
> > >> > I took a look a month or so ago:
> > >> >
> > >> > http://article.gmane.org/gmane.comp.emulators.kvm.devel/136207
> > >> >
> > >> > Last test I ran I had SeaBIOS down to 16ms (not including the
> > >> > time to deploy or jump to the linux kernel). More reductions
> > >> > are also possible - the above was just with Kconfig settings.
> > >> >
>
> I've been measuring the time for different configurations and setups.
>
> The conclusion is that the main bottleneck to boot QEMU is fw_cfg.
>
> Running a default SeaBIOS configuration gives these times (in seconds):
>
> (QEMU startup time is the time between the execution and the first
> kvm_entry, BIOS startup time is the time between the first kvm_entry
> and the ROM booting, and fw_cfg is the time between the ROM booting
> and the jump to the Linux kernel).
>
> QEMU startup time: .033
> BIOS startup time: .154
> fw_cfg setup time: .375
>
> And these results are more or less the same in QBoot, when using fw_cfg:
>
> QEMU startup time: .026
> BIOS startup time: .013
> fw_cfg setup time: .373
>
> The difference between SeaBIOS and QBoot is big, but, as I said, this
> SeaBIOS is not stripped-down. Using the .config that Kevin sent, I can
> get .01 seconds, but I cannot boot a ROM (I still have to play with the
> configuration options until it boots). Probably it can do it in less
> than 20 msec, which not far from QBoot.
>
> On the other side, QBoot with cbfs can boot really fast:
>
> QEMU startup time: .027
> Kernel setup time: .017
> Total time: .045
Thanks. Can you try the latest seabios with the patch below and the
attached config? The patch is a complete hack, but with it you should
be able to launch seabios with the same cbfs.rom file generated for
qboot. I see SeaBIOS take about 20ms on my old AMD system (again,
further optimizations could be made with some simple code changes). I
used the following qemu command line:
qemu-system-x86_64 -drive if=pflash,file=../seabios/out/bios.bin,readonly=on
-drive if=pflash,file=cbfs.rom,readonly=on -enable-kvm -serial mon:stdio
As a side note, if there is real interest in placing a kernel in a
"flash" like memory mapped device, it would be nice to do something
like the CBFS simple-elf (SELF) format so that the firmware doesn't
have to parse the bzimage.
-Kevin
diff --git a/src/Kconfig b/src/Kconfig
index 14c38fb..7484782 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -74,7 +74,7 @@ endchoice
"bootorder" file.
config COREBOOT_FLASH
-depends on COREBOOT
+#depends on COREBOOT
bool "coreboot CBFS support"
default y
help
diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c
index 8fd8449..3af67a8 100644
--- a/src/fw/coreboot.c
+++ b/src/fw/coreboot.c
@@ -421,6 +421,9 @@ coreboot_cbfs_init(void)
return;
struct cbfs_header *hdr = *(void **)(CONFIG_CBFS_LOCATION - 4);
+if (CBFS_HEADER_MAGIC && (u32)hdr > CONFIG_CBFS_LOCATION)
+// Looks like the pointer is relative to CONFIG_CBFS_LOCATION
+hdr = (void*)hdr + CONFIG_CBFS_LOCATION;
if (hdr->magic != cpu_to_be32(CBFS_HEADER_MAGIC)) {
dprintf(1, "Unable to find CBFS (ptr=%p; got %x not %x)\n"
, hdr, hdr->magic, cpu_to_be32(CBFS_HEADER_MAGIC));
@@ -464,6 +467,73 @@ coreboot_cbfs_init(void)
process_links_file();
}
+#include "bregs.h"
+struct cbfs_file *File_cmdline, *File_initrd;
+
+void
+cbfs_run_vmlinuz(struct cbfs_file *fhdr)
+{
+dprintf(1, "Loading kernel\n");
+void *kernel_src = (void*)fhdr + be32_to_cpu(fhdr->offset);
+u32 kernel_size = be32_to_cpu(fhdr->len);
+if (readl(kernel_src+0x202) != 0x53726448) {
+dprintf(1, "Not valid kernel\n");
+return;
+}
+u16 protocol = readw(kernel_src+0x206);
+if (protocol < 0x203) {
+dprintf(1, "Old kernel (v %x) not supported\n", protocol);
+return;
+}
+u32 cmdline_size = 0, initrd_size = 0;
+void *initrd_src, *cmdline_src;
+if (File_cmdline) {
+cmdline_size = be32_to_cpu(File_cmdline->len);
+cmdline_src = (void*)File_cmdline + be32_to_cpu(File_cmdline->offset);
+}
+if (File_initrd) {
+initrd_size = be32_to_cpu(File_initrd->len);
+initrd_src = (void*)File_initrd + be32_to_cpu(File_initrd->offset);
+}
+u32 real_addr=0x1, cmdline_addr=0x2;
+u32 prot_addr=0x10, initrd_addr=0;
+if (initrd_size) {
+u32 initrd_max = readl(kernel_src+0x22c);
+if (initrd_max > LegacyRamSize - 1)
+initrd_max = LegacyRamSize - 1;
+initrd_addr = ALIGN_DOWN(initrd_max - initrd_size, 4096);
+}
+u32 setup_siz
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
Hi, > The conclusion is that the main bottleneck to boot QEMU is fw_cfg. https://www.kraxel.org/cgit/qemu/log/?h=rebase/fw-cfg-dma-wip Some experimental (and untested) bits implementing a dma interface for fw_cfg (also some unrelated fw_cfg stuff). You might want try wire that up for x86 and see how it speeds up things ... cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On Wed, 8 Jul 2015 18:57:26 -0400 Kevin O'Connor wrote: > On Wed, Jul 08, 2015 at 03:44:33PM +0200, Marc Marí wrote: > > On Wed, 8 Jul 2015 09:10:14 +0100 > > Stefan Hajnoczi wrote: > > > > > On Sat, Jul 4, 2015 at 6:57 PM, Kevin O'Connor > > > wrote: > > > > On Fri, Jul 03, 2015 at 03:12:14PM +0100, Stefan Hajnoczi wrote: > > > >> On Fri, Jul 3, 2015 at 2:13 PM, Kevin O'Connor > > > >> wrote: > > > >> > I took a look a month or so ago: > > > >> > > > > >> > http://article.gmane.org/gmane.comp.emulators.kvm.devel/136207 > > > >> > > > > >> > Last test I ran I had SeaBIOS down to 16ms (not including the > > > >> > time to deploy or jump to the linux kernel). More reductions > > > >> > are also possible - the above was just with Kconfig settings. > > > >> > > > > > I've been measuring the time for different configurations and > > setups. > > > > The conclusion is that the main bottleneck to boot QEMU is fw_cfg. > > > > Running a default SeaBIOS configuration gives these times (in > > seconds): > > > > (QEMU startup time is the time between the execution and the first > > kvm_entry, BIOS startup time is the time between the first kvm_entry > > and the ROM booting, and fw_cfg is the time between the ROM booting > > and the jump to the Linux kernel). > > > > QEMU startup time: .033 > > BIOS startup time: .154 > > fw_cfg setup time: .375 > > > > And these results are more or less the same in QBoot, when using > > fw_cfg: > > > > QEMU startup time: .026 > > BIOS startup time: .013 > > fw_cfg setup time: .373 > > > > The difference between SeaBIOS and QBoot is big, but, as I said, > > this SeaBIOS is not stripped-down. Using the .config that Kevin > > sent, I can get .01 seconds, but I cannot boot a ROM (I still have > > to play with the configuration options until it boots). Probably it > > can do it in less than 20 msec, which not far from QBoot. > > > > On the other side, QBoot with cbfs can boot really fast: > > > > QEMU startup time: .027 > > Kernel setup time: .017 > > Total time: .045 > > Thanks. Can you try the latest seabios with the patch below and the > attached config? The patch is a complete hack, but with it you should > be able to launch seabios with the same cbfs.rom file generated for > qboot. I see SeaBIOS take about 20ms on my old AMD system (again, > further optimizations could be made with some simple code changes). I > used the following qemu command line: > > qemu-system-x86_64 -drive > if=pflash,file=../seabios/out/bios.bin,readonly=on -drive > if=pflash,file=cbfs.rom,readonly=on -enable-kvm -serial mon:stdio > > As a side note, if there is real interest in placing a kernel in a > "flash" like memory mapped device, it would be nice to do something > like the CBFS simple-elf (SELF) format so that the firmware doesn't > have to parse the bzimage. > > -Kevin > I tested with the given configuration and it boots. And it is faster than QBoot. SeaBIOS: - QEMU startup time: .030 - BIOS startup time: .008 - cbfs setup time: .0021 QBoot: - QEMU startup time: .030 - BIOS startup time: .013 - cbfs setup time: .0045 The profiling points are the same as before. "cbfs setup time" is the time between the call to the cbfs-processing function and the jump to the Linux kernel. This is a great improvement on the original times. Marc ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
On Thu, Jul 09, 2015 at 10:45:23AM +0200, Gerd Hoffmann wrote: > Hi, > > > The conclusion is that the main bottleneck to boot QEMU is fw_cfg. > > https://www.kraxel.org/cgit/qemu/log/?h=rebase/fw-cfg-dma-wip > > Some experimental (and untested) bits implementing a dma interface for > fw_cfg (also some unrelated fw_cfg stuff). > > You might want try wire that up for x86 and see how it speeds up > things ... Interesting. This probably isn't the right place to discuss the implementation, but I have a couple of comments on the dma interface. The interface doesn't have a "skip" field and that's quite helpful in the firmware to avoid having to memmove stuff around. (So, instead of select/addr/len it would be preferable to have select/addr/offset/len.) Have you considered using a transfer descriptor struct and dma'ing that? That is, use just two 32bit IO registers (descriptor addr high / descriptor addr low, active on write to low register) and then define a descriptor struct with the select, target addr, offset, len, and status fields - fw_cfg could then read the descriptor struct, perform the requested action, and then update the descriptor struct upon completion. Cheers, -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
