SeaBIOS October 2011

seabios@seabios.org

33 participants
56 discussions

usb boot issue
by Wolfgang Kamp - datakamp 13 Oct '11

13 Oct '11

Hi, is there any solution for the usb boot issue of the AMD SB800 Persimmon platform with SeaBIOS 1.6.3 and actual Coreboot version? Wolfgang Email: wmkamp(a)datakamp.de<mailto:wmkamp@datakamp.de>

1 0

Help with struct disk_op_s and block drives
by Daniel Castro 13 Oct '11

13 Oct '11

Hello, I am working on the PV block drivers for Xen. I am in the point where I must write to my PV ring the requests and responses. I need a little help to understand how this works :) The operation comes wrapped in this structure: struct disk_op_s { u64 lba; void *buf_fl; struct drive_s *drive_g; u16 count; lba is the sector I need to read or write to, right? count is how many sectors I am going to move, right? buf_fl is the pointer to the buffer where I will put the info in case of write, or I will get the info in case of read, right? command is either read or write. drive_s contains the descriptor of the drive. How does seabios handle more than one drive? My case, right now is only one drive but there will be more. Thanks for the help, Daniel -- +-=====---------------------------+ | +---------------------------------+ | This space intentionally blank for notetaking. | | | Daniel Castro, | | | | Consultant/Programmer.| | | | U Andes | +-------------------------------------+

1 0

Re: [SeaBIOS] [PATCHv3 4/4] acpi: automatically generated ssdt proc
by Kevin O'Connor 13 Oct '11

13 Oct '11

On Tue, Oct 04, 2011 at 03:26:19PM +0200, Michael S. Tsirkin wrote: > Get rid of manually cut and pasted ssdt_proc, > use ssdt compiled by iasl and offsets extracted > by acpi_extract instead. > > Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> FYI - I pushed the "ACPI DSDT simplifications" series and patch 1 and 4 from this series. -Kevin

1 0

Re: [SeaBIOS] POST Memory Manager emulation in SeaBIOS
by Darmawan Salihun 12 Oct '11

12 Oct '11

I forgot to mention that the serial output "print" the PMM "responses" from SeaBIOS like this: ----------- pmm call arg1=0 pmm00: length=8000 handle=ffffffff flags=6 pmm call arg1=2 pmm02: buffer=7f00000 pmm call arg1=0 pmm00: length=10000 handle=ffffffff flags=6 ----------- I also have another question. What is the maximum logging level in SeaBIOS? Is it 8? I built the SeaBIOS binary independently and combine it to Coreboot as ELF payload because its settings are custom, including the debugging level (which I set to 4). Regards, Darmawan On 10/13/11, Darmawan Salihun <darmawan.salihun(a)gmail.com> wrote: > Hi, > > My reply inline. > > On 10/11/11, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Mon, Oct 10, 2011 at 03:32:06PM +0700, Darmawan Salihun wrote: >>> Hi guys, >>> >>> I'm currently debugging a generic PCI Option ROM >>> (seen as legacy ROM since there is no PnP header). >>> This is the setup: >>> >>> a. The Option ROM "merged" to coreboot binary as CBFS component >>> (./cbfstool <option-rom-path> genroms/option-rom.rom raw) >>> >>> b. SeaBIOS would recognize the Option ROM and execute it. The execution >>> seems to take place after most PnP option ROM. >>> >>> c. Coreboot+Seabios is running inside qemu. >>> >>> d. The entire process (qemu with coreboot as "BIOS") is debugged >>> remotely >>> using IDA Pro. The connection is through GDB remote debugging "plugin" >>> in IDA Pro. >>> Therefore, from Qemu persepective, its being debugged remotely by GDB. >>> >>> Now, my question: >>> In this particular option ROM, a call to POST Memory Manager (PMM) is >>> made >>> to allocate 64KB of memory. What "reaction" SeaBIOS would carry-out to >>> such request? >> >> Calls to PMM start at romlayout.S:entry_pmm which will transition the >> cpu to 32bit mode and call pmm.c:handle_pmm(). An allocation call >> should reserve the memory and return a pointer to it. >> >> PMM debug info is on by default, so you should see SeaBIOS write debug >> info to the serial port. >> > > I observed the output in the redirected serial port output and I found > that the PMM memory allocation for another PCI ROM > (VID:DevID --> 8086:100e) is just fine. > > >>> I've trying to debug this call but nothing seems to happen as I see it >>> from inside IDA Pro. >>> >>> Any clues? or where should I peek in the source code? >> >> I suggest getting serial debugging working, and post the full log. >> > > The full log is in the attachment. > Anyway, I observed that the PCI ROM that I'm working with > always got it's 3rd byte set to zero prior to being executed. > I've just found where it's being modified but have yet to find > the corresponding code in the entire "debugging system" > > In the meantime I'm doing further debugging. > > Thanks, > > Darmawan > -- > -------------------------------------------------------------------- > -= Human knowledge belongs to the world =- > -- -------------------------------------------------------------------- -= Human knowledge belongs to the world =-

1 0

Re: [SeaBIOS] POST Memory Manager emulation in SeaBIOS
by Kevin O'Connor 12 Oct '11

12 Oct '11

On Mon, Oct 10, 2011 at 03:32:06PM +0700, Darmawan Salihun wrote: > Hi guys, > > I'm currently debugging a generic PCI Option ROM > (seen as legacy ROM since there is no PnP header). > This is the setup: > > a. The Option ROM "merged" to coreboot binary as CBFS component > (./cbfstool <option-rom-path> genroms/option-rom.rom raw) > > b. SeaBIOS would recognize the Option ROM and execute it. The execution > seems to take place after most PnP option ROM. > > c. Coreboot+Seabios is running inside qemu. > > d. The entire process (qemu with coreboot as "BIOS") is debugged remotely > using IDA Pro. The connection is through GDB remote debugging "plugin" > in IDA Pro. > Therefore, from Qemu persepective, its being debugged remotely by GDB. > > Now, my question: > In this particular option ROM, a call to POST Memory Manager (PMM) is made > to allocate 64KB of memory. What "reaction" SeaBIOS would carry-out to > such request? Calls to PMM start at romlayout.S:entry_pmm which will transition the cpu to 32bit mode and call pmm.c:handle_pmm(). An allocation call should reserve the memory and return a pointer to it. PMM debug info is on by default, so you should see SeaBIOS write debug info to the serial port. > I've trying to debug this call but nothing seems to happen as I see it > from inside IDA Pro. > > Any clues? or where should I peek in the source code? I suggest getting serial debugging working, and post the full log. -Kevin > > TIA, > > Darmawan

2 1

[PATCH] kernel/kvm: fix improper nmi emulation (was: Re: [Qemu-devel] [PATCH] qemu: Fix inject-nmi)
by Lai Jiangshan 12 Oct '11

12 Oct '11

From: Kenji Kaneshige <kaneshige.kenji(a)jp.fujitsu.com> Currently, NMI interrupt is blindly sent to all the vCPUs when NMI button event happens. This doesn't properly emulate real hardware on which NMI button event triggers LINT1. Because of this, NMI is sent to the processor even when LINT1 is maskied in LVT. For example, this causes the problem that kdump initiated by NMI sometimes doesn't work on KVM, because kdump assumes NMI is masked on CPUs other than CPU0. With this patch, KVM_NMI ioctl is handled as follows. - When in-kernel irqchip is enabled, KVM_NMI ioctl is handled as a request of triggering LINT1 on the processor. LINT1 is emulated in in-kernel irqchip. - When in-kernel irqchip is disabled, KVM_NMI ioctl is handled as a request of injecting NMI to the processor. This assumes LINT1 is already emulated in userland. Signed-off-by: Kenji Kaneshige <kaneshige.kenji(a)jp.fujitsu.com> Tested-by: Lai Jiangshan <laijs(a)cn.fujitsu.com> --- arch/x86/kvm/irq.h | 1 + arch/x86/kvm/lapic.c | 8 ++++++++ arch/x86/kvm/x86.c | 14 ++++---------- 3 files changed, 13 insertions(+), 10 deletions(-) Index: linux/arch/x86/kvm/irq.h =================================================================== --- linux.orig/arch/x86/kvm/irq.h +++ linux/arch/x86/kvm/irq.h @@ -95,6 +95,7 @@ void kvm_pic_reset(struct kvm_kpic_state void kvm_inject_pending_timer_irqs(struct kvm_vcpu *vcpu); void kvm_inject_apic_timer_irqs(struct kvm_vcpu *vcpu); void kvm_apic_nmi_wd_deliver(struct kvm_vcpu *vcpu); +void kvm_apic_lint1_deliver(struct kvm_vcpu *vcpu); void __kvm_migrate_apic_timer(struct kvm_vcpu *vcpu); void __kvm_migrate_pit_timer(struct kvm_vcpu *vcpu); void __kvm_migrate_timers(struct kvm_vcpu *vcpu); Index: linux/arch/x86/kvm/lapic.c =================================================================== --- linux.orig/arch/x86/kvm/lapic.c +++ linux/arch/x86/kvm/lapic.c @@ -1039,6 +1039,14 @@ void kvm_apic_nmi_wd_deliver(struct kvm_ kvm_apic_local_deliver(apic, APIC_LVT0); } +void kvm_apic_lint1_deliver(struct kvm_vcpu *vcpu) +{ + struct kvm_lapic *apic = vcpu->arch.apic; + + if (apic) + kvm_apic_local_deliver(apic, APIC_LVT1); +} + static struct kvm_timer_ops lapic_timer_ops = { .is_periodic = lapic_is_periodic, }; Index: linux/arch/x86/kvm/x86.c =================================================================== --- linux.orig/arch/x86/kvm/x86.c +++ linux/arch/x86/kvm/x86.c @@ -2729,13 +2729,6 @@ static int kvm_vcpu_ioctl_interrupt(stru return 0; } -static int kvm_vcpu_ioctl_nmi(struct kvm_vcpu *vcpu) -{ - kvm_inject_nmi(vcpu); - - return 0; -} - static int vcpu_ioctl_tpr_access_reporting(struct kvm_vcpu *vcpu, struct kvm_tpr_access_ctl *tac) { @@ -3038,9 +3031,10 @@ long kvm_arch_vcpu_ioctl(struct file *fi break; } case KVM_NMI: { - r = kvm_vcpu_ioctl_nmi(vcpu); - if (r) - goto out; + if (irqchip_in_kernel(vcpu->kvm)) + kvm_apic_lint1_deliver(vcpu); + else + kvm_inject_nmi(vcpu); r = 0; break; }

4 5

[PATCH] qemu-kvm: fix improper nmi emulation (was: Re: [Qemu-devel] [PATCH] qemu: Fix inject-nmi)
by Lai Jiangshan 11 Oct '11

11 Oct '11

From: Kenji Kaneshige <kaneshige.kenji(a)jp.fujitsu.com> Currently, NMI interrupt is blindly sent to all the vCPUs when NMI button event happens. This doesn't properly emulate real hardware on which NMI button event triggers LINT1. Because of this, NMI is sent to the processor even when LINT1 is maskied in LVT. For example, this causes the problem that kdump initiated by NMI sometimes doesn't work on KVM, because kdump assumes NMI is masked on CPUs other than CPU0. With this patch, inject-nmi request is handled as follows. - When in-kernel irqchip is disabled, inject LINT1 instead of NMI interrupt. - When in-kernel irqchip is enabled, send nmi event to kernel as the current code does. LINT1 should be emulated in kernel. Signed-off-by: Kenji Kaneshige <kaneshige.kenji(a)jp.fujitsu.com> Tested-by: Lai Jiangshan <laijs(a)cn.fujitsu.com> --- hw/apic.c | 16 ++++++++++++++++ hw/apic.h | 1 + monitor.c | 5 ++--- 3 files changed, 19 insertions(+), 3 deletions(-) Index: qemu-kvm/hw/apic.c =================================================================== --- qemu-kvm.orig/hw/apic.c +++ qemu-kvm/hw/apic.c @@ -205,6 +205,22 @@ void apic_deliver_pic_intr(DeviceState * } } +void apic_deliver_nmi(CPUState *env) +{ + APICState *apic; + + if (kvm_enabled() && kvm_irqchip_in_kernel()) { + cpu_interrupt(env, CPU_INTERRUPT_NMI); + return; + } + + apic = DO_UPCAST(APICState, busdev.qdev, env->apic_state); + if (!apic) + cpu_interrupt(env, CPU_INTERRUPT_NMI); + else + apic_local_deliver(apic, APIC_LVT_LINT1); +} + #define foreach_apic(apic, deliver_bitmask, code) \ {\ int __i, __j, __mask;\ Index: qemu-kvm/hw/apic.h =================================================================== --- qemu-kvm.orig/hw/apic.h +++ qemu-kvm/hw/apic.h @@ -10,6 +10,7 @@ void apic_deliver_irq(uint8_t dest, uint uint8_t trigger_mode); int apic_accept_pic_intr(DeviceState *s); void apic_deliver_pic_intr(DeviceState *s, int level); +void apic_deliver_nmi(CPUState *env); int apic_get_interrupt(DeviceState *s); void apic_reset_irq_delivered(void); int apic_get_irq_delivered(void); Index: qemu-kvm/monitor.c =================================================================== --- qemu-kvm.orig/monitor.c +++ qemu-kvm/monitor.c @@ -2615,9 +2615,8 @@ static int do_inject_nmi(Monitor *mon, c { CPUState *env; - for (env = first_cpu; env != NULL; env = env->next_cpu) { - cpu_interrupt(env, CPU_INTERRUPT_NMI); - } + for (env = first_cpu; env != NULL; env = env->next_cpu) + apic_deliver_nmi(env); return 0; }

3 4

Hack integrating SeaBios / LinuxBoot option rom with QEMU trace backends
by Daniel P. Berrange 11 Oct '11

11 Oct '11

I've been investigating where time disappears to when booting Linux guests. Initially I enabled DEBUG_BIOS in QEMU's hw/pc.c, and then hacked it so that it could print a timestamp before each new line of debug output. The problem with that is that it slowed down startup, so the timings I was examining all changed. What I really wanted was to use QEMU's trace infrastructure with a simple SystemTAP script. This is easy enough in the QEMU layer, but I also need to see where time goes to inside the various BIOS functions, and the options ROMs such as LinuxBoot. So I came up with a small hack to insert "probes" into SeaBios and LinuxBoot, which trigger a special IO port (0x404), which then cause QEMU to emit a trace event. The implementation is really very crude and does not allow any arguments to be passed each probes, but since all I care about is timing information, it is good enough for my needs. I'm not really expecting these patches to be merged into QEMU/SeaBios since they're just a crude hack & I don't have time to write something better. I figure they might be useful for someone else though... With the attached patches applied to QEMU and SeaBios, the attached systemtap script can be used to debug timings in QEMU startup. For example, one execution of QEMU produced the following log: $ stap qemu-timing.stp 0.000 Start 0.036 Run 0.038 BIOS post 0.180 BIOS int 19 0.181 BIOS boot OS 0.181 LinuxBoot copy kernel 1.371 LinuxBoot copy initrd 1.616 LinuxBoot boot OS 2.489 Shutdown request 2.490 Stop showing that LinuxBoot is responsible for by far the most execution time (~1500ms), in my test which runs for 2500ms in total. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

5 6

Re: [SeaBIOS] [Qemu-devel] Hang when using 9p mounts after last Seabios update
by Kevin O'Connor 11 Oct '11

11 Oct '11

On Thu, Sep 22, 2011 at 12:45:11PM +0100, Daniel P. Berrange wrote: > On 0.14, 0.15 releaes, this all works just fine. On current GIT master, > the guest OS will hang during boot. [...] > To reproduce this you will need my custom initrd for mounting 9p filesystems > as the root FS. You can get that here: > > http://berrange.com/~dan/qemu-serial-hang-demo.tar.gz Thanks for the detailed report. I've confirmed the issue and tracked it down. The current SeaBIOS code gets confused during alignment checking if there are no prefmem regions found. The patch below should fix the issue. Richard, can you also check to see if this seabios patch fixes your issue? -Kevin Author: Kevin O'Connor <kevin(a)koconnor.net> Date: Sat Oct 1 12:35:32 2011 -0400 Fix alignment bug in pci_bios_init_root_regions(). If there are no memory allocations for a given type then the "max" bar size is zero. However, ALIGN_DOWN does not handle an alignment of zero properly. Catch and handle the zero case. Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net> diff --git a/src/pciinit.c b/src/pciinit.c index a857da0..0d8758e 100644 --- a/src/pciinit.c +++ b/src/pciinit.c @@ -536,7 +536,7 @@ static void pci_bios_init_bus_bases(struct pci_bus *bus) } } -#define ROOT_BASE(top, sum, align) ALIGN_DOWN((top)-(sum),(align)) +#define ROOT_BASE(top, sum, max) ALIGN_DOWN((top)-(sum),(max) ?: 1) static int pci_bios_init_root_regions(u32 start, u32 end) {

3 2

[PATCH] Probe PCI existence
by Jan Kiszka 10 Oct '11

10 Oct '11

From: Jan Kiszka <jan.kiszka(a)siemens.com> This prevents lockups when trying to allocate PCI resources on an ISA-only system like QEMU can emulate. Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> --- src/pci.c | 14 +++++++++++++- src/pci.h | 3 ++- src/pciinit.c | 7 +++++-- 3 files changed, 20 insertions(+), 4 deletions(-) diff --git a/src/pci.c b/src/pci.c index 49698ac..6031c9f 100644 --- a/src/pci.c +++ b/src/pci.c @@ -88,9 +88,21 @@ pci_next(int bdf, int bus) struct pci_device *PCIDevices; int MaxPCIBus VAR16VISIBLE; +// Check if PCI is available at all +int +pci_probe_host(void) +{ + outl(0x80000000, PORT_PCI_CMD); + if (inl(PORT_PCI_CMD) != 0x80000000) { + dprintf(1, "Detected non-PCI system\n"); + return -1; + } + return 0; +} + // Find all PCI devices and populate PCIDevices linked list. void -pci_probe(void) +pci_probe_devices(void) { dprintf(3, "PCI probe\n"); struct pci_device *busdevs[256]; diff --git a/src/pci.h b/src/pci.h index 3e28af2..a2a5a4c 100644 --- a/src/pci.h +++ b/src/pci.h @@ -62,7 +62,8 @@ struct pci_device { }; extern struct pci_device *PCIDevices; extern int MaxPCIBus; -void pci_probe(void); +int pci_probe_host(void); +void pci_probe_devices(void); static inline u32 pci_classprog(struct pci_device *pci) { return (pci->class << 8) | pci->prog_if; } diff --git a/src/pciinit.c b/src/pciinit.c index 597c8ea..a857da0 100644 --- a/src/pciinit.c +++ b/src/pciinit.c @@ -577,7 +577,7 @@ pci_setup(void) { if (CONFIG_COREBOOT || usingXen()) { // PCI setup already done by coreboot or Xen - just do probe. - pci_probe(); + pci_probe_devices(); return; } @@ -587,10 +587,13 @@ pci_setup(void) u32 end = BUILD_PCIMEM_END; dprintf(1, "=== PCI bus & bridge init ===\n"); + if (pci_probe_host() != 0) { + return; + } pci_bios_init_bus(); dprintf(1, "=== PCI device probing ===\n"); - pci_probe(); + pci_probe_devices(); dprintf(1, "=== PCI new allocation pass #1 ===\n"); busses = malloc_tmp(sizeof(*busses) * busses_count); -- 1.7.3.4

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS October 2011