SeaBIOS

seabios@seabios.org

3783 discussions

Re: [SeaBIOS] [PATCH v2] qemu: fast boot when linuxboot optionrom is used
by Kevin O'Connor 18 Dec '18

18 Dec '18

On Mon, Dec 10, 2018 at 03:18:46PM +0100, Stefano Garzarella wrote: > On Wed, Dec 5, 2018 at 6:00 PM Kevin O'Connor <kevin(a)koconnor.net> wrote: > > On Fri, Nov 30, 2018 at 11:23:30AM +0100, Stefano Garzarella wrote: > > > On Thu, Nov 29, 2018 at 5:55 PM Kevin O'Connor <kevin(a)koconnor.net> wrote: > > > > --- a/src/output.c > > > > +++ b/src/output.c > > > > @@ -74,6 +74,9 @@ static struct putcinfo debuginfo = { debug_putc }; > > > > static void > > > > screenc(char c) > > > > { > > > > + if (!MODESEGMENT && GET_IVT(0x10).segoff == FUNC16(entry_10).segoff) > > > > + // No need to thunk to 16bit mode if vgabios is not present > > > > + return; > > > > struct bregs br; > > > > memset(&br, 0, sizeof(br)); > > > > br.flags = F_IF; > > > > > > Do you plan to commit this patch? > > > > Only if it's useful - does sercon make it not worthwhile? > > Yes, I think it is useful. If I don't use "-nographic" it works as expected. FYI, I committed this change. -Kevin

1 0

Re: [SeaBIOS] [PATCH] qemu: avoid debug prints if debugcon is not enabled
by Kevin O'Connor 18 Dec '18

18 Dec '18

On Tue, Dec 11, 2018 at 10:10:33AM +0100, Stefano Garzarella wrote: > On Tue, Dec 11, 2018 at 4:08 AM Kevin O'Connor <kevin(a)koconnor.net> wrote: > > > > On Sun, Dec 02, 2018 at 02:10:13PM +0100, Stefano Garzarella wrote: > > > In order to speed up the boot phase, we can check the QEMU > > > debugcon device, and disable the writes if it is not recognized. > > > > > > This patch allow us to save around 10 msec (time measured > > > between SeaBIOS entry point and "linuxboot" entry point) > > > when CONFIG_DEBUG_LEVEL=1 and debugcon is not enabled. > > > > Thanks. In order to properly track reboots, the HaveRunPost variable > > must always be the first global variable to be modified. So, the qemu > > debug init must come later in the boot. How about the patch below > > instead? > > Thanks for the explanation! It looks good! Thanks. I committed this change. -Kevin

1 0

[PATCH] qemu: avoid debug prints if debugcon is not enabled
by Stefano Garzarella 11 Dec '18

11 Dec '18

In order to speed up the boot phase, we can check the QEMU debugcon device, and disable the writes if it is not recognized. This patch allow us to save around 10 msec (time measured between SeaBIOS entry point and "linuxboot" entry point) when CONFIG_DEBUG_LEVEL=1 and debugcon is not enabled. Signed-off-by: Stefano Garzarella <sgarzare(a)redhat.com> --- src/fw/paravirt.h | 3 +++ src/hw/serialio.c | 16 ++++++++++++++-- src/hw/serialio.h | 1 + src/post.c | 3 +++ 4 files changed, 21 insertions(+), 2 deletions(-) diff --git a/src/fw/paravirt.h b/src/fw/paravirt.h index a14d83e..f7e1d4c 100644 --- a/src/fw/paravirt.h +++ b/src/fw/paravirt.h @@ -49,6 +49,9 @@ static inline int runningOnKVM(void) { // QEMU_CFG_DMA ID bit #define QEMU_CFG_VERSION_DMA 2 +// QEMU debugcon read value +#define QEMU_DEBUGCON_READBACK 0xe9 + int qemu_cfg_enabled(void); int qemu_cfg_dma_enabled(void); void qemu_preinit(void); diff --git a/src/hw/serialio.c b/src/hw/serialio.c index 319a85c..d9acd3c 100644 --- a/src/hw/serialio.c +++ b/src/hw/serialio.c @@ -103,11 +103,23 @@ serial_debug_flush(void) u16 DebugOutputPort VARFSEG = 0x402; +void +qemu_debug_postram_preinit(void) +{ + /* Check if the QEMU debug output port is active */ + if (CONFIG_DEBUG_IO && + inb(GET_GLOBAL(DebugOutputPort)) != QEMU_DEBUGCON_READBACK) + DebugOutputPort = 0; +} + // Write a character to the special debugging port. void qemu_debug_putc(char c) { - if (CONFIG_DEBUG_IO && runningOnQEMU()) + u16 port; + + if (CONFIG_DEBUG_IO && runningOnQEMU() && + (port = GET_GLOBAL(DebugOutputPort))) // Send character to debug port. - outb(c, GET_GLOBAL(DebugOutputPort)); + outb(c, port); } diff --git a/src/hw/serialio.h b/src/hw/serialio.h index 88296fe..31fbea3 100644 --- a/src/hw/serialio.h +++ b/src/hw/serialio.h @@ -24,6 +24,7 @@ void serial_debug_preinit(void); void serial_debug_putc(char c); void serial_debug_flush(void); extern u16 DebugOutputPort; +void qemu_debug_postram_preinit(void); void qemu_debug_putc(char c); #endif // serialio.h diff --git a/src/post.c b/src/post.c index f93106a..650a314 100644 --- a/src/post.c +++ b/src/post.c @@ -332,6 +332,9 @@ handle_post(void) // Allow writes to modify bios area (0xf0000) make_bios_writable(); + // Setup QEMU debug output port + qemu_debug_postram_preinit(); + // Now that memory is read/writable - start post process. dopost(); } -- 2.19.2

2 2

Re: [SeaBIOS] [PATCH v2] qemu: fast boot when linuxboot optionrom is used
by Kevin O'Connor 10 Dec '18

10 Dec '18

On Fri, Nov 30, 2018 at 11:23:30AM +0100, Stefano Garzarella wrote: > On Thu, Nov 29, 2018 at 5:55 PM Kevin O'Connor <kevin(a)koconnor.net> wrote: > > Interesting. I tracked down this printf delay - it's due to the > > save/restore of cpu state when thunking to 16bit mode. (For every > > character displayed on the screen the code enters 16bit mode to invoke > > the vgabios and it saves/restores the cr0, gdt, fs, gs, a20, nmi > > states during that process.) It's trivial to eliminate the calls when > > there is no vgabios though (see patch below). > > Thanks, the patch works, but unfortunately, when I use qemu > -nographic, the /etc/sercon-port is set to PORT_SERIAL1 (in > src/fw/paravirt.c:623), bypassing the patch. > Maybe in QEMU is better to set /etc/sercom-port to 0 when there is no > serial port, or when we want a fast boot. You should be able to use "-device VGA,romfile=" instead. > > --- a/src/output.c > > +++ b/src/output.c > > @@ -74,6 +74,9 @@ static struct putcinfo debuginfo = { debug_putc }; > > static void > > screenc(char c) > > { > > + if (!MODESEGMENT && GET_IVT(0x10).segoff == FUNC16(entry_10).segoff) > > + // No need to thunk to 16bit mode if vgabios is not present > > + return; > > struct bregs br; > > memset(&br, 0, sizeof(br)); > > br.flags = F_IF; > > Do you plan to commit this patch? Only if it's useful - does sercon make it not worthwhile? -Kevin

2 1

Re: [SeaBIOS] [PATCH] ramdisk: search for all available floppy images instead of one
by Kevin O'Connor 07 Dec '18

07 Dec '18

On Sat, Nov 24, 2018 at 11:46:53PM +0300, Mike Banon wrote: > Dear Kevin, > > Please could you tell me, why the memory allocation functions like > malloc_tmphigh() are failing at do_boot() stage? (boot.c) . Because of > this "VARVERIFY32INIT" problem described in my letter above - > https://mail.coreboot.org/pipermail/seabios/2018-November/012575.html > - I rewrote all my code to allocate the RAM for one floppy only (space > equal to max floppy size, which could be used by any selected floppy) > . But when I'm trying to boot that selected floppy - it is failing, > because these floppies are LZMA compressed inside CBFS and to > decompress them another malloc_tmphigh() is needed (from > cbfs_copyfile() / coreboot.c) / Although this code compiles fine (no > VARVERIFY32INIT problem) - this malloc_tmphigh() function is always > failing and SeaBIOS is freezing. > > Spent all my weekend debugging this problem and really stuck, any help > will be highly appreciated Hi, Only the "post" stage is able to allocate ram. Once the "boot" phase starts executing, areas of memory are locked down, and it's possible for 3rd party software to become resident in various areas of ram. SeaBIOS thus can't touch those areas of ram or modify the e820 map. The VARVERIFY32INIT flag is there to catch this type of common error. There's some info on this in the docs at: https://www.seabios.org/Memory_Model#Memory_available_during_initialization and: https://www.seabios.org/Execution_and_code_flow So, any type of allocation would have to occur before the boot stage. It should be possible (though not necessarily easy) to perform the allocation in the map_floppy_drive() phase of the code. -Kevin

2 1

Re: [SeaBIOS] [PATCH v2] qemu: fast boot when linuxboot optionrom is used
by Kevin O'Connor 05 Dec '18

05 Dec '18

On Fri, Nov 30, 2018 at 03:27:21PM +0100, Stefano Garzarella wrote: > On Fri, Nov 30, 2018 at 2:06 PM Gerd Hoffmann <kraxel(a)redhat.com> wrote: > > > > Note: All these tests are done with CONFIG_DEBUG_LEVEL=0, using > > > > CONFIG_DEBUG_LEVEL=1 the boot time grows up to 24 ms, maybe we should > > > > put CONFIG_DEBUG_LEVEL=0 in the SeaBIOS configuration used in QEMU. > > > > > > I think the main seabios binary should have CONFIG_DEBUG_LEVEL=1 as it > > > helps with debug reports. I suppose an additional binary could be > > > made for those looking for the fastest possible speed. (The sole cost > > > of the debugging is the additional hardware accesses that results from > > > those debug messages.) > > > > The qemu debugcon (CONFIG_DEBUG_IO) is detecable at runtime, it returns > > 0xe9 on port reads. So we should be able to skip that too. IIRC it > > isn't *that* straightforward as seabios is initially mapped read/only so > > a simple probe-on-first-putchar, then cache the result in a variable > > doesn't work. We could probe after make_bios_writable though which > > should still avoid printing most of the messages. > > Great! I just tried the patch below and it works as you said. If I > don't have debugcon in QEMU the outs are avoided and the speed is not > bad (11.4 ms). > If I have debugcon (iobase=0x402), I can see the output. > > Do you think can be an acceptable trade-off? Makes sense to me. > index 0770c47..31c080e 100644 > --- a/src/fw/paravirt.c > +++ b/src/fw/paravirt.c > @@ -121,6 +121,10 @@ qemu_preinit(void) > kvm_detect(); > } > > + // Detect qemu debugcon > + if (inb(GET_GLOBAL(DebugOutputPort)) != QEMU_DEBUGCON_READBACK) > + DebugOutputPort = 0; As a minor quibble, this needs to be "if (CONFIG_DEBUG_IO && ...)" to ensure it gets compiled out if debug io is not in use. Also, I think it would be preferable to introduce a serial_debug_postram_preinit() method in src/hw/serialio.c that does this check. > --- a/src/hw/serialio.c > +++ b/src/hw/serialio.c > @@ -107,7 +107,7 @@ u16 DebugOutputPort VARFSEG = 0x402; > void > qemu_debug_putc(char c) > { > - if (CONFIG_DEBUG_IO && runningOnQEMU()) > + if (CONFIG_DEBUG_IO && runningOnQEMU() && GET_GLOBAL(DebugOutputPort)) > // Send character to debug port. > outb(c, GET_GLOBAL(DebugOutputPort)); > } As a minor nit, it would be preferable to invoke GET_GLOBAL(DebugOutputPort) only once in the success case. -Kevin

2 1

RFC: Add support for virt machine to Seabios
by Rob Bradford 05 Dec '18

05 Dec '18

The virt machine in the NEMU project has the ambition to be a platform that has no emulated legacy hardware. This patch series enables support for that machine type in Seabios. The impact that this has for a Seabios port is that the CMOS is not available to query details of CPUs or memory configuration; instead this patch series modifies the code that queries those details to prefer those from QEMU FW CFG over CMOS. I've tested this patch series with pc, Q35 and virt as part of our automated testing for NEMU. Rob

2 12

[PATCH] Revert "mptable: Don't describe pci-to-pci bridges."
by Liran Alon 04 Dec '18

04 Dec '18

From: Arbel Moshe <arbel.moshe(a)oracle.com> This reverts commit 3c3a3fa6522f ("mptable: Don't describe pci-to-pci bridges.”) The reverted commit removed the description of non-root PCI busses from the MPTable in claim they are not necessary. However, it seems that some guests rely on this information in order to correclty configure IOAPIC redirection-table entries for interrupts originated from PCI devices on non-root PCI busses. One such guest is "Extreme Networks OS". We observed that if this guest is setup with an E1000 NIC behind a PCI bridge, the OS wouldn't configure the IOAPIC redirection-table entry for the IRQ that the E1000 PIN is connected to. Therefore, interrupts from the NIC were not delivered to OS which caused guest to not have network connectivity. Fixes: 3c3a3fa6522f ("mptable: Don't describe pci-to-pci bridges.”) Reviewed-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Mark Kanda <mark.kanda(a)oracle.com> Signed-off-by: Arbel Moshe <arbel.moshe(a)oracle.com> --- src/fw/mptable.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/src/fw/mptable.c b/src/fw/mptable.c index 47385cc5d32d..27686369e98c 100644 --- a/src/fw/mptable.c +++ b/src/fw/mptable.c @@ -72,25 +72,30 @@ mptable_setup(void) } int entrycount = cpu - cpus; - // PCI bus + // PCI buses struct mpt_bus *buses = (void*)cpu, *bus = buses; - if (!hlist_empty(&PCIDevices)) { + int lastbus = -1; + struct pci_device *pci; + foreachpci(pci) { + int curbus = pci_bdf_to_bus(pci->bdf); + if (curbus == lastbus) + continue; + lastbus = curbus; memset(bus, 0, sizeof(*bus)); bus->type = MPT_TYPE_BUS; - bus->busid = 0; + bus->busid = curbus; memcpy(bus->bustype, "PCI ", sizeof(bus->bustype)); bus++; - entrycount++; } /* isa bus */ - int isabusid = bus - buses; + int isabusid; memset(bus, 0, sizeof(*bus)); bus->type = MPT_TYPE_BUS; - bus->busid = isabusid; + isabusid = bus->busid = lastbus + 1; memcpy(bus->bustype, "ISA ", sizeof(bus->bustype)); bus++; - entrycount++; + entrycount += bus - buses; /* ioapic */ u8 ioapic_id = BUILD_IOAPIC_ID; @@ -108,11 +113,8 @@ mptable_setup(void) int dev = -1; unsigned short pinmask = 0; - struct pci_device *pci; foreachpci(pci) { u16 bdf = pci->bdf; - if (pci_bdf_to_bus(bdf) != 0) - break; int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN); int irq = pci_config_readb(bdf, PCI_INTERRUPT_LINE); if (pin == 0) -- 2.16.1

2 5

[PATCH] mpt-scsi: Align MPT request to 8 bytes
by Liran Alon 03 Dec '18

03 Dec '18

From: Nikita Leshchenko <nikita.leshchenko(a)oracle.com> When mpt-scsi receives a SCSI message, it wraps it in a MPT request message and writes it's address to an IO port to be added to the request queue. This MPT request is allocated on the stack. Previous to this commit, the request is aligned to 4 bytes. However, VirtualBox LSI53c1030 device emulation aligns the request address to 8 bytes. Therefore, this commit change alignment of request to 8 bytes. VirtualBox source code which handles this is at Devices/Storage/DevLsiLogicSCSI.cpp. lsilogicRegisterWrite() LSILOGIC_REG_REQUEST_QUEUE handler adds the request to the queue (pRequestQueueBase). lsilogicR3Worker() reads request from pRequestQueueBase and aligns it to 8 bytes (u32RequestMessageFrameDesc & ~0x07). Reviewed-by: Liran Alon <liran.alon(a)oracle.com> Reviewed-by: Mark Kanda <mark.kanda(a)oracle.com> Signed-off-by: Nikita Leshchenko <nikita.leshchenko(a)oracle.com> --- src/hw/mpt-scsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw/mpt-scsi.c b/src/hw/mpt-scsi.c index 1faede6aec6f..9966ca28054f 100644 --- a/src/hw/mpt-scsi.c +++ b/src/hw/mpt-scsi.c @@ -124,7 +124,7 @@ mpt_scsi_cmd(u32 iobase, struct disk_op_s *op, struct scsi_req { MptSCSIIORequest_t scsi_io; MptSGEntrySimple32_t sge; - } __attribute__((packed, aligned(4))) req = { + } __attribute__((packed, aligned(8))) req = { .scsi_io = { .TargetID = target, .Bus = 0, -- 2.16.1

2 4

Re: [SeaBIOS] [PATCH v2] qemu: fast boot when linuxboot optionrom is used
by Kevin O'Connor 30 Nov '18

30 Nov '18

On Thu, Nov 29, 2018 at 03:16:39PM +0100, Stefano Garzarella wrote: > On Wed, Nov 28, 2018 at 3:38 PM Kevin O'Connor <kevin(a)koconnor.net> wrote: > > It would be good to understand what the source of the delay is. It > > might be possible to avoid the delay without adding a new config > > setting. For example, the patch above will prevent the vga rom from > > being run, but it should be possible to accomplish the same with > > "-device VGA,romfile=". The other change this patch makes is to skip > > device_hardware_setup() - is it known which items in that function add > > to the delay? > > Hi Kevin, > thanks for your advice. > > I tried to understand what are the sources of the delay, and I found > that most of the time is spent because of QEMU default devices (eg > e1000 ROM PCI, mouse, keyboard, etc) > At this point, (without the patch above) I disabled the default QEMU > devices (-nodefaults) and I reached 12.5 ms of SeaBIOS boot time > (compared to 22 ms, where 4 ms is taken by the loading of e1000 ROM). > > Other 2 ms is taken by enable_vga_console(), where simply comment out > the printf("SeaBIOS (version %s)\n", VERSION) I reached 10.7 ms of > boot time. > Do you think is acceptable to use dprintf(1, ...) instead of printf()? > Or maybe check if we found the VGA. Interesting. I tracked down this printf delay - it's due to the save/restore of cpu state when thunking to 16bit mode. (For every character displayed on the screen the code enters 16bit mode to invoke the vgabios and it saves/restores the cr0, gdt, fs, gs, a20, nmi states during that process.) It's trivial to eliminate the calls when there is no vgabios though (see patch below). > Note: All these tests are done with CONFIG_DEBUG_LEVEL=0, using > CONFIG_DEBUG_LEVEL=1 the boot time grows up to 24 ms, maybe we should > put CONFIG_DEBUG_LEVEL=0 in the SeaBIOS configuration used in QEMU. I think the main seabios binary should have CONFIG_DEBUG_LEVEL=1 as it helps with debug reports. I suppose an additional binary could be made for those looking for the fastest possible speed. (The sole cost of the debugging is the additional hardware accesses that results from those debug messages.) > > Also, what is the target boot time that is considered acceptable? > > I'm using qboot as a reference (6/7 ms). It is very minimal, so 10 ms > I think is considered acceptable for SeaBIOS Thanks, -Kevin --- a/src/output.c +++ b/src/output.c @@ -74,6 +74,9 @@ static struct putcinfo debuginfo = { debug_putc }; static void screenc(char c) { + if (!MODESEGMENT && GET_IVT(0x10).segoff == FUNC16(entry_10).segoff) + // No need to thunk to 16bit mode if vgabios is not present + return; struct bregs br; memset(&br, 0, sizeof(br)); br.flags = F_IF;

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS