SeaBIOS

seabios@seabios.org

3783 discussions

[PATCH RFC] x86: use volatile asm for read/write{b, w, l} implementations
by Vitaly Kuznetsov 23 Jan '18

23 Jan '18

QEMU/KVM guests running nested on top of Hyper-V fail to boot with virtio-blk-pci disks, the debug log ends with Booting from Hard Disk... call32_smm 0x000edd01 e97a0 handle_smi cmd=b5 smbase=0x000a0000 vp notify fe007000 (2) -- 0x0 vp read fe005000 (1) -> 0x0 handle_smi cmd=b5 smbase=0x000a0000 call32_smm done 0x000edd01 0 Booting from 0000:7c00 call32_smm 0x000edd01 e97a4 handle_smi cmd=b5 smbase=0x000a0000 vp notify fe007000 (2) -- 0x0 In resume (status=0) In 32bit resume Attempting a hard reboot ... I bisected the breakage to the following commit: commit f46739b1a819750c63fb5849844d99cc2ab001e8 Author: Kevin O'Connor <kevin(a)koconnor.net> Date: Tue Feb 2 22:34:27 2016 -0500 virtio: Convert to new PCI BAR helper functions But the commit itself appears to be correct. The problem is in how writew() function compiles into vp_notify(). For example, if we drop 'volatile' qualifier from the current writew() implementation everything starts to work. If we disassemble these two versions (as of f46739b1a) the difference will be: 00000000 <vp_notify>: With 'volatile' (current) Without 'volatile' 0: push %ebx 0: push %ebx 1: mov %eax,%ecx 1: mov %eax,%ecx 3: mov 0x1518(%edx),%eax 3: mov 0x1518(%edx),%eax 9: cmpb $0x0,0x2c(%ecx) 9: cmpb $0x0,0x2c(%ecx) d: je 2f <vp_notify+0x2f> d: je 2e <vp_notify+0x2e> f: mov 0x151c(%edx),%edx f: mov 0x151c(%edx),%edx 15: mov 0x28(%ecx),%ebx 18: imul %edx,%ebx 15: imul 0x28(%ecx),%edx 1b: mov 0x8(%ecx),%edx 19: mov 0x8(%ecx),%ebx 1e: add %ebx,%edx 20: cmpb $0x0,0xe(%ecx) 1c: cmpb $0x0,0xe(%ecx) 24: je 2a <vp_notify+0x2a> 20: je 28 <vp_notify+0x28> 22: add %ebx,%edx 26: out %ax,(%dx) 24: out %ax,(%dx) 28: jmp 48 <vp_notify+0x48> 26: jmp 47 <vp_notify+0x47> 2a: mov %ax,(%edx) 28: mov %ax,(%ebx,%edx,1) 2d: jmp 48 <vp_notify+0x48> 2c: jmp 47 <vp_notify+0x47> 2f: lea 0x20(%ecx),%ebx 2e: lea 0x20(%ecx),%ebx 32: cltd 31: cltd 33: push %edx 32: push %edx 34: push %eax 33: push %eax 35: mov $0x2,%ecx 34: mov $0x2,%ecx 3a: mov $0x10,%edx 39: mov $0x10,%edx 3f: mov %ebx,%eax 3e: mov %ebx,%eax 41: call 42 <vp_notify+0x42> 40: call 41 <vp_notify+0x41> 46: pop %eax 45: pop %eax 47: pop %edx 46: pop %edx 48: pop %ebx 47: pop %ebx 49: ret 48: ret My eyes fail to see an obvious compiler flaw here but probably the mov difference (at '2a' old, '28' new) is to blame. Doing some other subtle changes (e.g. adding local variables to the function) help in some cases too. At this point I got a bit lost with my debug so I looked at how Linux does this stuff and it seems we're not using '*(volatile u16) = ' there. Rewriting write/read{b,w,l} with volatile asm help. Signed-off-by: Vitaly Kuznetsov <vkuznets(a)redhat.com> --- RFC: This is rather an ongoing debug as I'm not able to point finger at the real culprit yet, I'd be grateful for any help and suggestions. In particular, I don't quite understand why nested virtualization makes a difference here. --- src/x86.h | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/src/x86.h b/src/x86.h index 53378e9..d45122c 100644 --- a/src/x86.h +++ b/src/x86.h @@ -199,30 +199,27 @@ static inline void smp_wmb(void) { } static inline void writel(void *addr, u32 val) { - barrier(); - *(volatile u32 *)addr = val; + asm volatile("movl %0, %1" : : "d"(val), "m"(*(u32 *)addr) : "memory"); } static inline void writew(void *addr, u16 val) { - barrier(); - *(volatile u16 *)addr = val; + asm volatile("movw %0, %1" : : "d"(val), "m"(*(u16 *)addr) : "memory"); } static inline void writeb(void *addr, u8 val) { - barrier(); - *(volatile u8 *)addr = val; + asm volatile("movb %0, %1" : : "d"(val), "m"(*(u8 *)addr) : "memory"); } static inline u32 readl(const void *addr) { - u32 val = *(volatile const u32 *)addr; - barrier(); + u32 val; + asm volatile("movl %1, %0" : "=d"(val) : "m"(*(u32 *)addr) : "memory"); return val; } static inline u16 readw(const void *addr) { - u16 val = *(volatile const u16 *)addr; - barrier(); + u16 val; + asm volatile("movw %1, %0" : "=d"(val) : "m"(*(u16 *)addr) : "memory"); return val; } static inline u8 readb(const void *addr) { - u8 val = *(volatile const u8 *)addr; - barrier(); + u8 val; + asm volatile("movb %1, %0" : "=d"(val) : "m"(*(u8 *)addr) : "memory"); return val; } -- 2.14.3

2 6

[PATCH] paravirt: Allow both Red Hat and Amazon PCI HB subsystem vendor and device ids
by Filippo Sironi 20 Jan '18

20 Jan '18

Signed-off-by: Filippo Sironi <sironi(a)amazon.de> --- src/fw/paravirt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c index 0770c47b12e7..163b70c6473f 100644 --- a/src/fw/paravirt.c +++ b/src/fw/paravirt.c @@ -83,8 +83,8 @@ static void qemu_detect(void) u16 sv = pci_config_readw(0, PCI_SUBSYSTEM_VENDOR_ID); u16 sd = pci_config_readw(0, PCI_SUBSYSTEM_ID); - if (sv != 0x1af4 || /* Red Hat, Inc */ - sd != 0x1100) /* Qemu virtual machine */ + if (!(sv == 0x1af4 && sd == 0x1100) && /* Red Hat, Inc. QEMU VM */ + !(sv == 0x1d0f && sd == 0x1237)) /* Amazon.com, Inc. i440fx VM */ return; PlatformRunningOn |= PF_QEMU; -- 2.7.4

5 4

Serial input / output with SeaBIOS 1.11.0
by Piotr Kubaj 19 Jan '18

19 Jan '18

Hi, I've upgraded my coreboot to tag 4.7. As a payload I use SeaBIOS. I want to use the new feature of serial communication from SeaBIOS. The issue I have is that there's only serial output (meaning I can see the SeaBIOS menu on serial), but pressing any key on keyboard via serial doesn't do anything - I can only control SeaBIOS via keyboard plugged directly to the board, not via serial. Does anyone have the same issue? I use AsRock E350M1 board. I didn't create a custum SeaBIOS config, I just use the default one. -- ________________________ / Accordion, n.: \ | | \ A bagpipe with pleats. / ------------------------ \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||

1 0

[PATCH v2 0/3] Add support for TPM Physical Presence interface
by Stefan Berger 17 Jan '18

17 Jan '18

The following 3 patches add support for the TPM's Physical Presence interface (PPI). The patches require the recently posted QEMU patch for support of PPI (PATCH v2): http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg03652.html We assume a device at 0xfffe f000 - 0xfffe f3ff where the OS can write a code into that SeaBIOS needs to find and act upon after a reboot. Stefan Stefan Berger (3): tcgbios: pass returnCode through many functions tcgbios: Add TPM Physical Presence interface support tcgbios: extend Physical Presence interface with more functions src/hw/tpm_drivers.c | 8 +- src/hw/tpm_drivers.h | 2 +- src/post.c | 4 + src/std/acpi.h | 10 ++ src/std/tcg.h | 38 +++++++ src/tcgbios.c | 305 +++++++++++++++++++++++++++++++++++++++------------ src/tcgbios.h | 3 + 7 files changed, 299 insertions(+), 71 deletions(-) -- 2.5.5

3 12

[PATCH] pci: fix 'io hints' capability for RedHat PCI bridges
by Marcel Apfelbaum 17 Jan '18

17 Jan '18

Commit ec6cb17f (pci: enable RedHat PCI bridges to reserve additional resources on PCI init) added a new vendor specific PCI capability for RedHat PCI bridges allowing them to reserve additional buses and/or IO/MEM space. When adding the IO hints PCI capability to the pcie-root-port without specifying a value for bus reservation, the subordinate bus computation is wrong and the guest kernel gets messed up. Fix it by returning to prev code if the value for bus reservation is not set. Removed also a wrong debug print "PCI: invalid QEMU resource reserve cap offset" which appears if the 'IO hints' capability is not present. Signed-off-by: Marcel Apfelbaum <marcel(a)redhat.com> --- src/fw/pciinit.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 7f0e439..3a2f747 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -540,8 +540,6 @@ static u8 pci_find_resource_reserve_capability(u16 bdf) dprintf(1, "PCI: QEMU resource reserve cap length %d is invalid\n", cap_len); } - } else { - dprintf(1, "PCI: invalid QEMU resource reserve cap offset\n"); } return cap; } else { @@ -619,13 +617,11 @@ pci_bios_init_bus_rec(int bus, u8 *pci_bus) res_bus); res_bus = 0; } - } - if (secbus + res_bus > *pci_bus) { - dprintf(1, "PCI: QEMU resource reserve cap: bus = %u\n", - res_bus); - res_bus = secbus + res_bus; - } else { - res_bus = *pci_bus; + if (secbus + res_bus > *pci_bus) { + dprintf(1, "PCI: QEMU resource reserve cap: bus = %u\n", + res_bus); + res_bus = secbus + res_bus; + } } } dprintf(1, "PCI: subordinate bus = 0x%x -> 0x%x\n", -- 2.13.5

4 3

[PATCH] Show the real IRQ number in the debug, produced by the unused, IRQ handler
by Nikolay Nikolov 15 Jan '18

15 Jan '18

Show the IRQ number from the actual interrupt vector in addition to the value read from the ISR (the In-Service Register of the 8259A PIC) in the debug output, generated by the unused IRQ handlers. This helps e.g. distinguishing real IRQs from spurious interrupts, generated by buggy (or badly configured) hardware. Signed-off-by: Nikolay Nikolov <nickysn(a)users.sourceforge.net> --- src/hw/pic.c | 108 +++++++++++++++++++++++++++++++++++++++++++++++++++++--- src/post.c | 20 ++++++++--- src/romlayout.S | 18 ++++++++-- 3 files changed, 135 insertions(+), 11 deletions(-) diff --git a/src/hw/pic.c b/src/hw/pic.c index a13564a..dc9fe21 100644 --- a/src/hw/pic.c +++ b/src/hw/pic.c @@ -99,17 +99,115 @@ pic_isr2_read(void) return inb(PORT_PIC2_CMD); } -// Handler for otherwise unused hardware irqs. +// Handlers for otherwise unused hardware irqs. void VISIBLE16 -handle_hwpic1(void) +handle_hwpic1_irq0(void) { - dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=%x\n", pic_isr1_read()); + dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=0 isr=%x\n", pic_isr1_read()); pic_eoi1(); } void VISIBLE16 -handle_hwpic2(void) +handle_hwpic1_irq1(void) { - dprintf(DEBUG_ISR_hwpic2, "handle_hwpic2 irq=%x\n", pic_isr2_read()); + dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=1 isr=%x\n", pic_isr1_read()); + pic_eoi1(); +} + +void VISIBLE16 +handle_hwpic1_irq2(void) +{ + dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=2 isr=%x\n", pic_isr1_read()); + pic_eoi1(); +} + +void VISIBLE16 +handle_hwpic1_irq3(void) +{ + dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=3 isr=%x\n", pic_isr1_read()); + pic_eoi1(); +} + +void VISIBLE16 +handle_hwpic1_irq4(void) +{ + dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=4 isr=%x\n", pic_isr1_read()); + pic_eoi1(); +} + +void VISIBLE16 +handle_hwpic1_irq5(void) +{ + dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=5 isr=%x\n", pic_isr1_read()); + pic_eoi1(); +} + +void VISIBLE16 +handle_hwpic1_irq6(void) +{ + dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=6 isr=%x\n", pic_isr1_read()); + pic_eoi1(); +} + +void VISIBLE16 +handle_hwpic1_irq7(void) +{ + dprintf(DEBUG_ISR_hwpic1, "handle_hwpic1 irq=7 isr=%x\n", pic_isr1_read()); + pic_eoi1(); +} + +void VISIBLE16 +handle_hwpic2_irq8(void) +{ + dprintf(DEBUG_ISR_hwpic2, "handle_hwpic2 irq=8 isr=%x\n", pic_isr2_read()); + pic_eoi2(); +} + +void VISIBLE16 +handle_hwpic2_irq9(void) +{ + dprintf(DEBUG_ISR_hwpic2, "handle_hwpic2 irq=9 isr=%x\n", pic_isr2_read()); + pic_eoi2(); +} + +void VISIBLE16 +handle_hwpic2_irq10(void) +{ + dprintf(DEBUG_ISR_hwpic2, "handle_hwpic2 irq=10 isr=%x\n", pic_isr2_read()); + pic_eoi2(); +} + +void VISIBLE16 +handle_hwpic2_irq11(void) +{ + dprintf(DEBUG_ISR_hwpic2, "handle_hwpic2 irq=11 isr=%x\n", pic_isr2_read()); + pic_eoi2(); +} + +void VISIBLE16 +handle_hwpic2_irq12(void) +{ + dprintf(DEBUG_ISR_hwpic2, "handle_hwpic2 irq=12 isr=%x\n", pic_isr2_read()); + pic_eoi2(); +} + +void VISIBLE16 +handle_hwpic2_irq13(void) +{ + dprintf(DEBUG_ISR_hwpic2, "handle_hwpic2 irq=13 isr=%x\n", pic_isr2_read()); + pic_eoi2(); +} + +void VISIBLE16 +handle_hwpic2_irq14(void) +{ + dprintf(DEBUG_ISR_hwpic2, "handle_hwpic2 irq=14 isr=%x\n", pic_isr2_read()); + pic_eoi2(); +} + +void VISIBLE16 +handle_hwpic2_irq15(void) +{ + dprintf(DEBUG_ISR_hwpic2, "handle_hwpic2 irq=15 isr=%x\n", pic_isr2_read()); pic_eoi2(); } diff --git a/src/post.c b/src/post.c index f93106a..12aa4f8 100644 --- a/src/post.c +++ b/src/post.c @@ -40,10 +40,22 @@ ivt_init(void) SET_IVT(i, FUNC16(entry_iret_official)); // Initialize all hw vectors to a default hw handler. - for (i=BIOS_HWIRQ0_VECTOR; i<BIOS_HWIRQ0_VECTOR+8; i++) - SET_IVT(i, FUNC16(entry_hwpic1)); - for (i=BIOS_HWIRQ8_VECTOR; i<BIOS_HWIRQ8_VECTOR+8; i++) - SET_IVT(i, FUNC16(entry_hwpic2)); + SET_IVT(BIOS_HWIRQ0_VECTOR, FUNC16(entry_hwpic1_irq0)); + SET_IVT(BIOS_HWIRQ0_VECTOR+1, FUNC16(entry_hwpic1_irq1)); + SET_IVT(BIOS_HWIRQ0_VECTOR+2, FUNC16(entry_hwpic1_irq2)); + SET_IVT(BIOS_HWIRQ0_VECTOR+3, FUNC16(entry_hwpic1_irq3)); + SET_IVT(BIOS_HWIRQ0_VECTOR+4, FUNC16(entry_hwpic1_irq4)); + SET_IVT(BIOS_HWIRQ0_VECTOR+5, FUNC16(entry_hwpic1_irq5)); + SET_IVT(BIOS_HWIRQ0_VECTOR+6, FUNC16(entry_hwpic1_irq6)); + SET_IVT(BIOS_HWIRQ0_VECTOR+7, FUNC16(entry_hwpic1_irq7)); + SET_IVT(BIOS_HWIRQ8_VECTOR, FUNC16(entry_hwpic2_irq8)); + SET_IVT(BIOS_HWIRQ8_VECTOR+1, FUNC16(entry_hwpic2_irq9)); + SET_IVT(BIOS_HWIRQ8_VECTOR+2, FUNC16(entry_hwpic2_irq10)); + SET_IVT(BIOS_HWIRQ8_VECTOR+3, FUNC16(entry_hwpic2_irq11)); + SET_IVT(BIOS_HWIRQ8_VECTOR+4, FUNC16(entry_hwpic2_irq12)); + SET_IVT(BIOS_HWIRQ8_VECTOR+5, FUNC16(entry_hwpic2_irq13)); + SET_IVT(BIOS_HWIRQ8_VECTOR+6, FUNC16(entry_hwpic2_irq14)); + SET_IVT(BIOS_HWIRQ8_VECTOR+7, FUNC16(entry_hwpic2_irq15)); // Initialize software handlers. SET_IVT(0x02, FUNC16(entry_02)); diff --git a/src/romlayout.S b/src/romlayout.S index c4a4635..50a44b9 100644 --- a/src/romlayout.S +++ b/src/romlayout.S @@ -568,8 +568,22 @@ irqentry_arg: DECL_IRQ_ENTRY 70 DECL_IRQ_ENTRY 74 DECL_IRQ_ENTRY 75 - DECL_IRQ_ENTRY hwpic1 - DECL_IRQ_ENTRY hwpic2 + DECL_IRQ_ENTRY hwpic1_irq0 + DECL_IRQ_ENTRY hwpic1_irq1 + DECL_IRQ_ENTRY hwpic1_irq2 + DECL_IRQ_ENTRY hwpic1_irq3 + DECL_IRQ_ENTRY hwpic1_irq4 + DECL_IRQ_ENTRY hwpic1_irq5 + DECL_IRQ_ENTRY hwpic1_irq6 + DECL_IRQ_ENTRY hwpic1_irq7 + DECL_IRQ_ENTRY hwpic2_irq8 + DECL_IRQ_ENTRY hwpic2_irq9 + DECL_IRQ_ENTRY hwpic2_irq10 + DECL_IRQ_ENTRY hwpic2_irq11 + DECL_IRQ_ENTRY hwpic2_irq12 + DECL_IRQ_ENTRY hwpic2_irq13 + DECL_IRQ_ENTRY hwpic2_irq14 + DECL_IRQ_ENTRY hwpic2_irq15 // int 18/19 are special - they reset stack and call into 32bit mode. DECLFUNC entry_19 -- 2.14.3

1 0

[RFC PATCH 0/2] Add support for the TPM physical presence interface
by Stefan Berger 11 Jan '18

11 Jan '18

The following 2 patches add support for the TPM's physial presence interface (PPI). The patches require the recently posted QEMU patch for support of PPI: http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg01884.html We assume a device at 0xffff 0000 - 0xffff 00ff where the OS can write a code into that SeaBIOS needs to find and act upon after a reboot. I have previously tried to use a memory location allocated within the ACPI stream but that causes problems for finding the location after reboot since the ACPI is completely rewritten and all memory it covers erased, thus leaving no trace of the code the OS wrote into the memory. Per Kevin's suggestion we are now using a device at that well known address. The patches are functional with Linux. One missing part is that the result code from the last TPM operation should be put into the shared memory block so that the user can see the code. However, currently the TPM error code from the responses are not passed back from the function calls, so in case of failure I am simply returning 0x0badc0de. Stefan Stefan Berger (2): tcgbios: Add physical presence interface support tcgbios: extend physical presence interface with more functions src/post.c | 4 ++ src/std/tcg.h | 25 +++++++++++++ src/tcgbios.c | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++- src/tcgbios.h | 3 ++ 4 files changed, 145 insertions(+), 2 deletions(-) -- 2.5.5

1 2

Commit d6728f301d7e ("add serial console support") causes double-printing
by Omar Sandoval 11 Jan '18

11 Jan '18

Hello, I found that QEMU v2.11.0 double prints to the console when running the Arch Linux installation ISO. I bisected this to seabios commit d6728f301d7e ("add serial console support"). The expected output is this: ┌────────────────────────────────────────────────────────────────────┐ │ Arch Linux │ ├────────────────────────────────────────────────────────────────────┤ │ Boot Arch Linux (x86_64) │ │ Boot existing OS │ │ Run Memtest86+ (RAM test) │ │ Hardware Information (HDT) │ │ Reboot │ │ Power Off │ │ │ └────────────────────────────────────────────────────────────────────┘ But instead I get the following mess: ┌┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Arch Linux ││ ├├────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤┤ │ BBoooott AArrcchh LLiinnuuxx ((xx8866__6644)) ││ │ BBoooott eexxiissttiinngg OOSS ││ │ RRuunn MMeemmtteesstt8866++ ((RRAAMM tteesstt)) ││ │ HHaarrddwwaarree IInnffoorrmmaattiioonn ((HHDDTT)) ││ │ RReebboooott ││ │ PPoowweerr OOffff ││ │ ││ └└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘┘ To reproduce this, download the latest ISO from https://www.archlinux.org/download/, then run qemu-system-x86_64 -nodefaults -nographic -serial mon:stdio -cpu kvm64 -enable-kvm -boot d -no-reboot -cdrom archlinux-2018.01.01-x86_64.iso Thanks! Omar

2 2

[PATCH] Don't select SERCON when target is coreboot
by Arthur Heymans 08 Jan '18

08 Jan '18

CONFIG_SERCON=y breaks coreboot S3 (boots into payload instead of OS reset vector). Signed-off-by: Arthur Heymans <arthur(a)aheymans.xyz> diff --git a/src/Kconfig b/src/Kconfig index 55a87cb..597d4ce 100644 --- a/src/Kconfig +++ b/src/Kconfig @@ -308,6 +308,7 @@ menu "Hardware support" Support serial ports. This also enables int 14 serial port calls. config SERCON bool "Serial console" + depends on !COREBOOT default y help Support redirecting vga output to the serial console. -- 2.15.1

2 1

[PATCH 0/2] Allow creation of EK and SRK for TPM 2
by Stefan Berger 29 Dec '17

29 Dec '17

The following two patches add functionality to create EK and SRK keys to the TPM 2 menu. We follow TCG specifications for how to create those as RSA keys. Regards, Stefan Stefan Berger (2): tcbios: Add menu item to create an EK for TPM 2 tcbios: Add menu item to create a primary storage key for TPM 2 src/std/tcg.h | 63 +++++++++++ src/tcgbios.c | 341 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 388 insertions(+), 16 deletions(-) -- 2.5.5

2 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS