December 2024 - SeaBIOS - mail.coreboot.org

regression: cannot boot from nvme anymore, disabling 64bit pci io window helps
by Marek Marczykowski-Górecki July 7, 2026

July 7, 2026

Hi, After an update some time ago, a VM wit 8GB RAM cannot boot from nvme anymore. QEMU cmdline: /usr/bin/qemu-system-x86_64 \ -chardev ringbuf,id=serial0,logfile=serial0,logappend=on \ -serial chardev:serial0 \ -m 8192 \ -enable-kvm \ -vnc :2,share=force-shared \ -blockdev driver=file,node-name=hd0-file,filename=disk.qcow2,cache.no-flush=on,discard=unmap \ -blockdev driver=qcow2,node-name=hd0,file=hd0-file,cache.no-flush=on,discard=unmap \ -device nvme,id=hd0-device,drive=hd0,serial=hd0 \ -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios \ -bios /home/user/seabios/out/bios.bin There is nothing fancy on the disk, just standard grub2 setup, but also I believe it doesn't matter, as it doesn't even reach grub. When it fails, the seabios log contains: PCI: 64: 0000038000000000 - 0000038040000000 PCI: map device bdf=00:04.0 bar 0, addr 38000000000, size 00004000 [mem] ... Searching bootorder for: /pci@i0cf8/isa@1/fdc@03f0/floppy@0 ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9) ATA controller 2 at 170/374/0 (irq 15 dev 9) Searching bootorder for: HALT Can not map memory bar over 4Gig ... Boot failed: could not read the boot disk Working version has this instead: PCI: map device bdf=00:04.0 bar 0, addr febf0000, size 00004000 [mem] ... Booting from Hard Disk... Booting from 0000:7c00 00:04.0 is the nvme. I'm attaching full logs for both cases. Bisect shows: 96a8d130a8c2e908e357ce62cd713f2cc0b0a2eb is the first bad commit commit 96a8d130a8c2e908e357ce62cd713f2cc0b0a2eb (HEAD) Author: Gerd Hoffmann <kraxel(a)redhat.com> Date: Fri Sep 9 10:17:15 2022 +0200 be less conservative with the 64bit pci io window Current seabios code will only enable and use the 64bit pci io window in case it runs out of space in the 32bit pci mmio window below 4G. This patch will also enable the 64bit pci io window when (a) RAM above 4G is present, and (b) the physical address space size is known, and (c) seabios is running on a 64bit capable processor. This operates with the assumption that guests which are ok with memory above 4G most likely can handle mmio above 4G too. In case the 64bit pci io window is enabled also assign more memory to prefetchable pci bridge windows and the complete 64bit pci io window. The total mmio window size is 1/8 of the physical address space. Minimum bridge windows size is 1/256 of the total mmio window size. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> I've tried the recent "[PATCH] limit address space used for pci devices, part two" patch from the ML, but it doesn't help. OTOH, the series with "only enable 64bit pci io window when RAM >64G" does help. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

3 6

[PATCH v2 0/2] add guest hint for memory layout, take three
by Gerd Hoffmann June 3, 2025

June 3, 2025

Gerd Hoffmann (2): add romfile_loadbool() update pci_pad_mem64 handling src/romfile.h | 1 + src/fw/pciinit.c | 13 ++++++++++--- src/romfile.c | 23 +++++++++++++++++++++++ 3 files changed, 34 insertions(+), 3 deletions(-) -- 2.47.0

3 10

[PATCH 0/2] drop acpi support for qemu 1.6 and older.
by Gerd Hoffmann Jan. 16, 2025

Jan. 16, 2025

Gerd Hoffmann (2): drop obsolete acpi table code drop acpi tables and hex includes Makefile | 15 - src/fw/acpi.c | 668 +------------------------------ src/Kconfig | 10 - src/fw/acpi-dsdt-cpu-hotplug.dsl | 78 ---- src/fw/acpi-dsdt-dbug.dsl | 26 -- src/fw/acpi-dsdt-hpet.dsl | 36 -- src/fw/acpi-dsdt-isa.dsl | 102 ----- src/fw/acpi-dsdt-pci-crs.dsl | 90 ----- src/fw/acpi-dsdt.dsl | 342 ---------------- src/fw/acpi-dsdt.hex | 554 ------------------------- src/fw/q35-acpi-dsdt.dsl | 450 --------------------- src/fw/ssdt-misc.dsl | 104 ----- src/fw/ssdt-misc.hex | 88 ---- src/fw/ssdt-pcihp.dsl | 36 -- src/fw/ssdt-pcihp.hex | 38 -- src/fw/ssdt-proc.dsl | 48 --- src/fw/ssdt-proc.hex | 35 -- 17 files changed, 1 insertion(+), 2719 deletions(-) delete mode 100644 src/fw/acpi-dsdt-cpu-hotplug.dsl delete mode 100644 src/fw/acpi-dsdt-dbug.dsl delete mode 100644 src/fw/acpi-dsdt-hpet.dsl delete mode 100644 src/fw/acpi-dsdt-isa.dsl delete mode 100644 src/fw/acpi-dsdt-pci-crs.dsl delete mode 100644 src/fw/acpi-dsdt.dsl delete mode 100644 src/fw/acpi-dsdt.hex delete mode 100644 src/fw/q35-acpi-dsdt.dsl delete mode 100644 src/fw/ssdt-misc.dsl delete mode 100644 src/fw/ssdt-misc.hex delete mode 100644 src/fw/ssdt-pcihp.dsl delete mode 100644 src/fw/ssdt-pcihp.hex delete mode 100644 src/fw/ssdt-proc.dsl delete mode 100644 src/fw/ssdt-proc.hex -- 2.47.0

3 7

[PATCH] Support multiple USB HID keyboards/mice
by Daniel Khodabakhsh Jan. 7, 2025

Jan. 7, 2025

This change allows the use of multiple USB HID keyboards and mice. It's similar to the change by Stef van Os from this thread: https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/O6Y4LU… however this new change uses the linked list approach instead of a fixed array. Tested on QEMU and an Asus KGPE-D16 with 2 keyboards and one mice

3 13

BUG REPORT: PCI-e address window overlaps with AMD_HT_START
by Li, Yunxiang (Teddy) Jan. 2, 2025

Jan. 2, 2025

[Public] Hi all, I've ran into an issue where the 64 bit address window allocated for one of the PCI-e host devices overlaps with a BIOS reserved range of fd00000000-ffffffffff, making that device unusable. 4000000000-7bfffffffff : PCI Bus 0000:00 4000000000-bfffffffff : PCI Bus 0000:0c 4000000000-7fffffffff : 0000:0c:00.0 8000000000-80001fffff : 0000:0c:00.0 c000000000-13fffffffff : PCI Bus 0000:0b c000000000-ffffffffff : 0000:0b:00.0 fd00000000-ffffffffff : Reserved 10000000000-100001fffff : 0000:0b:00.0 8000000000-7ffffffffff : PCI Bus 0000:00 8000000000-ffffffffff : PCI Bus 0000:0c 8000000000-bfffffffff : 0000:0c:00.0 c000000000-c0001fffff : 0000:0c:00.0 fd00000000-ffffffffff : Reserved 10000000000-17fffffffff : PCI Bus 0000:0b 10000000000-13fffffffff : 0000:0b:00.0 14000000000-140001fffff : 0000:0b:00.0 I found that increasing the system ram of the VM to ~256G changes the address window and avoids the issue, and with some digging I think I found the root cause To begin, QEMU set this address range to be reserved here, and this is passed to Seabios via "etc/e820". https://gitlab.com/qemu-project/qemu/-/blob/master/hw/i386/pc.c#L865 Separately QEMU pass to Seabios "etc/reserved-memory-end" here which is derived from machine->device_memory https://gitlab.com/qemu-project/qemu/-/blob/master/hw/i386/pc.c#L1007 In Seabios, "etc/e820" is consumed here, which sets RamSizeOver4G only using the E820_RAM entries, ignoring any E820_RESERVED entries. https://gitlab.com/qemu-project/seabios/-/blob/master/src/fw/paravirt.c#L782 Later "etc/reserved-memory-end" and RamSizeOver4G is used to determine the start of the PCI-e address window. https://gitlab.com/qemu-project/seabios/-/blob/master/src/fw/pciinit.c#L1138 I think either QEMU should set etc/reserved-memory-end to be after both physical memory and the reserved ranges, or Seabios need to check both etc/820 and etc/reserved-memory-end. But I'm not sure which would be the correct move and indeed how to patch them. Regards, Yunxiang Li (Teddy)

2 2

[PATCH] pciinit: use the 32-bit MMIO address space preferred
by Hulang Jan. 2, 2025

Jan. 2, 2025

Currently, pci region on busses[0] may be migrate to 64-bit mmio space. this will cause a mistake to read/write device config space example: A modern virtio device map to 64-bit mmio space will set mode to VP_ACCESS_PCICFG, But the real device cap is VIRTIO_PCI_CAP_COMMON_CFG, we can not access the cap rightly. If this is a virtio blk/scsi device as system disk, VM will not be booted on the device. A simple solution is make device use the 32-bit address space as much as possible. This patch changes the placement of the PCI bars. [1] commit 0e21548b15e2 ("virtio: pci cfg access") Signed-off-by: hulang <hulang13(a)huawei.com> --- src/fw/pciinit.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index b3e359d7..2e9544dc 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -1100,8 +1100,12 @@ static void pci_region_map_entries(struct pci_bus *busses, struct pci_region *r) { struct hlist_node *n; struct pci_region_entry *entry; + u64 r_end = r->base + pci_region_sum(r) + hlist_for_each_entry_safe(entry, n, &r->list, node) { u64 addr = r->base; + if (addr + entry->size >= r_end) + continue; r->base += entry->size; if (entry->bar == -1) // Update bus base address if entry is a bridge region @@ -1114,6 +1118,8 @@ static void pci_region_map_entries(struct pci_bus *busses, struct pci_region *r) static void pci_bios_map_devices(struct pci_bus *busses) { + int bus; + if (pci_bios_init_root_regions_io(busses)) panic("PCI: out of I/O address space\n"); @@ -1122,6 +1128,15 @@ static void pci_bios_map_devices(struct pci_bus *busses) struct pci_region r64_mem, r64_pref; r64_mem.list.first = NULL; r64_pref.list.first = NULL; + + // try map pci region to 32bit + for (bus = 0; bus<=MaxPCIBus; bus++) { + int type; + for (type = 0; type < PCI_REGION_TYPE_COUNT; type++) + pci_region_map_entries(busses, &busses[bus].r[type]); + } + + // map remaining pci region to 64bit pci_region_migrate_64bit_entries(&busses[0].r[PCI_REGION_TYPE_MEM], &r64_mem); pci_region_migrate_64bit_entries(&busses[0].r[PCI_REGION_TYPE_PREFMEM], @@ -1166,7 +1181,6 @@ static void pci_bios_map_devices(struct pci_bus *busses) pcimem64_start = 0; } // Map regions on each device. - int bus; for (bus = 0; bus<=MaxPCIBus; bus++) { int type; for (type = 0; type < PCI_REGION_TYPE_COUNT; type++) -- 2.33.0 Best Regards！胡浪 Hu Lang 华为云计算公司德科软件开发工程师 Espace：h30028282 Mobile：+86 18212092054 E-mail： hulang11(a)huawei.com<mailto:jinmeng11@huawei.com> www.fescoadecco.com<http://www.fescoadecco.com/> 办公地址：杭州市滨江区江淑路华为研究所Z6-4-B06R-087S

2 1

[PATCH] fw/mptable: fix smp core initialization per cpu package
by Anthony Iliopoulos Dec. 26, 2024

Dec. 26, 2024

Currently the mptable setup code only considers one core per cpu package for populating the cpu tables. The detection logic goes back to machines where the cpuid would signify the presence of multiple logical cores (HT) and presumably this change was made to prevent creating vcpus for each hyperthread. In practice this restriction is not required any longer especially since current processors feature many physical cores per socket, and it is preventing QEMU guests that don't enable ACPI from seeing more than one cores, unless those cores are explicitly placed across multiple sockets (one core per socket, specifically). During v6.2 QEMU changed the default cpu topology arrangement preference from arranging multiple cores spreaded across multiple sockets to placing them within the same socket [1]. In practice this means that without specifing explicitly the cpu topology and assuming QEMU defaults, a guest without ACPI will not be able to instantiate more than one core. Fix this by lifting the restriction of only populating the mptable with the first logical processor per package. [1] commit 4a0af2930a4e ("machine: Prefer cores over sockets in smp parsing since 6.2") Fixes: c0ad0e8febe5 ("Only add the first logical CPU in each physical CPU to the MPS tables.") Signed-off-by: Anthony Iliopoulos <ailiop(a)suse.com> --- src/fw/mptable.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/src/fw/mptable.c b/src/fw/mptable.c index 47385cc5d32d..a939743691c9 100644 --- a/src/fw/mptable.c +++ b/src/fw/mptable.c @@ -47,19 +47,13 @@ mptable_setup(void) cpuid_signature = 0x600; cpuid_features = 0x201; } - int pkgcpus = 1; - if (cpuid_features & (1 << 28)) { - /* Only populate the MPS tables with the first logical CPU in - each package */ - pkgcpus = (ebx >> 16) & 0xff; - pkgcpus = 1 << (__fls(pkgcpus - 1) + 1); /* round up to power of 2 */ - } + u8 apic_version = readl((u8*)BUILD_APIC_ADDR + 0x30) & 0xff; // CPU definitions. struct mpt_cpu *cpus = (void*)&config[1], *cpu = cpus; int i; - for (i = 0; i < MaxCountCPUs; i+=pkgcpus) { + for (i = 0; i < MaxCountCPUs; i++) { memset(cpu, 0, sizeof(*cpu)); cpu->type = MPT_TYPE_CPU; cpu->apicid = i; -- 2.47.0

2 3

[PATCH] Add force-boot-menu runtime configuration
by Daniel Khodabakhsh Dec. 24, 2024

Dec. 24, 2024

This change adds a 'force-boot-menu' runtime configuration such that if a non-zero value is set and 'show-boot-menu' is also non-zero, SeaBIOS will show the boot menu without a timeout. This is similar to GRUB having a timeout set to '-1' and originally I wanted to implement it that way but the function to retrieve an integer retrieves an unsigned one so I thought this "boolean" configuration is a good way to implement it. Tested on ASUS KGPE-D16. From b1d69c8da90ab9ec25cc3f35ed5ee651e8405ff1 Mon Sep 17 00:00:00 2001 From: Daniel Khodabakhsh <d.khodabakhsh(a)gmail.com> Date: Thu, 7 Nov 2024 18:46:16 -0800 Subject: [PATCH] Add force-boot-menu runtime configuration. --- docs/Runtime_config.md | 1 + src/boot.c | 32 +++++++++++++++++++------------- 2 files changed, 20 insertions(+), 13 deletions(-) diff --git a/docs/Runtime_config.md b/docs/Runtime_config.md index 5795382b..af4da96a 100644 --- a/docs/Runtime_config.md +++ b/docs/Runtime_config.md @@ -177,6 +177,7 @@ There are several additional configuration options available in the | boot-menu-message | Customize the text boot menu message. Normally, when in text mode SeaBIOS will report the string "\\nPress ESC for boot menu.\\n\\n". This field allows the string to be changed. (This is a string field, and is added as a file containing the raw string.) | boot-menu-key | Controls which key activates the boot menu. The value stored is the DOS scan code (eg, 0x86 for F12, 0x01 for Esc). If this field is set, be sure to also customize the **boot-menu-message** field above. | boot-menu-wait | Amount of time (in milliseconds) to wait at the boot menu prompt before selecting the default boot. +| force-boot-menu | Forces the display of the boot menu unless the value is 0. **show-boot-menu** must also be set to 1. The default is 0. | boot-fail-wait | If no boot devices are found SeaBIOS will reboot after 60 seconds. Set this to the amount of time (in milliseconds) to customize the reboot delay or set to -1 to disable rebooting when no boot devices are found | extra-pci-roots | If the target machine has multiple independent root buses set this to a positive value. The SeaBIOS PCI probe will then search for the given number of extra root buses. | ps2-keyboard-spinup | Some laptops that emulate PS2 keyboards don't respond to keyboard commands immediately after powering on. One may specify the amount of time (in milliseconds) here to allow as additional time for the keyboard to become responsive. When this field is set, SeaBIOS will repeatedly attempt to detect the keyboard until the keyboard is found or the specified timeout is reached. diff --git a/src/boot.c b/src/boot.c index 1effd802..9bcb2480 100644 --- a/src/boot.c +++ b/src/boot.c @@ -708,20 +708,26 @@ interactive_bootmenu(void) return; } - while (get_keystroke(0) >= 0) - ; - - char *bootmsg = romfile_loadfile("etc/boot-menu-message", NULL); + // Show boot splash and proceed with booting if force_boot_menu == 0 (default), + // otherwise force display menu + int force_boot_menu = romfile_loadint("etc/force-boot-menu", 0); int menukey = romfile_loadint("etc/boot-menu-key", 1); - printf("%s", bootmsg ?: "\nPress ESC for boot menu.\n\n"); - free(bootmsg); - - u32 menutime = romfile_loadint("etc/boot-menu-wait", DEFAULT_BOOTMENU_WAIT); - enable_bootsplash(); - int scan_code = get_keystroke(menutime); - disable_bootsplash(); - if (scan_code != menukey) - return; + int scan_code; + if (force_boot_menu == 0) { + while (get_keystroke(0) >= 0) + ; + + char *bootmsg = romfile_loadfile("etc/boot-menu-message", NULL); + printf("%s", bootmsg ?: "\nPress ESC for boot menu.\n\n"); + free(bootmsg); + + u32 menutime = romfile_loadint("etc/boot-menu-wait", DEFAULT_BOOTMENU_WAIT); + enable_bootsplash(); + scan_code = get_keystroke(menutime); + disable_bootsplash(); + if (scan_code != menukey) + return; + } while (get_keystroke(0) >= 0) ; -- 2.46.0

3 6