SeaBIOS

seabios@seabios.org

4 participants
3800 discussions

"PCI: out of address space" with two video cards
by marek dudek 13 Oct '11

13 Oct '11

Hello, I am experimenting with video card PCI pass-through under KVM. I am trying to get a KVM guest to work with (up to) TWO video cards assigned to it. The goal is to have flexibility of using a single quest with two monitors, or two guests with a single monitor each, etc. Note that using a single “dual-headed” video card is not a preferred option, since it can be assigned only to one guest. So far I was successful (Debian guest OS booting ok, graphics works fine) when using a single video card (see point 3 below). However, when assigning two video cards to a guest, SeaBIOS fails with "PCI: out of address space" error during PCI new allocation pass #1 (see point 4 below). Notice that both video cards were properly detected and assigned to requested guest PCI slots 00:06.0 and 00:07.0. Any ideas how to fix or get around this problem? My coding expertise is rudimentary, but I am willing to experiment with any suggestions, try patches you might provide, etc. Is there additional info I could provide to help in the testing process? Thanks, Marek Dudek -------------------------- My setup is a follows: 1) Using latest version of Seabios (rel-1.6.3); compiled with debug level 8. As an experiment, I also tried recent “PCI init code refactoring” patch by Kevin O'Connor, with same result. 2) Both video cards are of same type (old NVidia GeForce 7300); the cards are located in the host PCI slots 02:00.0 and 03:00.0. $ sudo lspci -v -s 02:00.0 02:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce 7300 SE/7200 GS] (rev a1) (prog-if 00 [VGA controller]) Subsystem: eVga.com. Corp. Device c429 Flags: bus master, fast devsel, latency 0, IRQ 36 Memory at f8000000 (32-bit, non-prefetchable) [size=16M] Memory at b0000000 (64-bit, prefetchable) [size=256M] Memory at f7000000 (64-bit, non-prefetchable) [size=16M] Expansion ROM at f6fe0000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting <?> Kernel driver in use: pci-stub 3) When using a SINGLE video card, SeaBIOS reports as follows: $sudo kvm -drive file=/dev/sdc -device pci-assign,host=02:00.0,addr=0x6 -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios 2>&1 ------------------------ Start bios (version 1.6.3-20111012_174214-rock) enabling shadow ram qemu_cfg_present=1 Find memory size Add to e820 map: 00000000 08000000 1 Add to e820 map: 00000000 00000000 1 Add to e820 map: fffc0000 00040000 2 Add to e820 map: 000a0000 00050000 -1 Add to e820 map: 000f0000 00010000 2 Add to e820 map: feffc000 00004000 2 Ram Size=0x08000000 (0x0000000000000000 high) malloc setup Add to e820 map: 07ff0000 00010000 2 pmm_malloc zone=0x000f0930 handle=ffffffff size=63248 align=10 ret=0x07fe07d0 (detail=0x07fefee0) Relocating init from 0x000e12d0 to 0x07fe07d0 (size 63248) malloc fixup reloc init ivt init bda Add to e820 map: 0009fc00 00000400 2 init pic init timer tsc calibrate start=1004667100 end=1011214380 diff=6547280 CPU Mhz=3814 math cp init init mtrr pci setup === PCI bus & bridge init === PCI: pci_bios_init_bus_rec bus = 0x0 === PCI device probing === PCI probe pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0700 (detail=0x07fe0770) PCI device 00:00.0 (vd=8086:1237 c=0600) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0660 (detail=0x07fe06d0) PCI device 00:01.0 (vd=8086:7000 c=0601) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe05c0 (detail=0x07fe0630) PCI device 00:01.1 (vd=8086:7010 c=0101) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0520 (detail=0x07fe0590) PCI device 00:01.3 (vd=8086:7113 c=0680) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0480 (detail=0x07fe04f0) PCI device 00:02.0 (vd=1013:00b8 c=0300) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe03e0 (detail=0x07fe0450) PCI device 00:03.0 (vd=10ec:8139 c=0200) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0340 (detail=0x07fe03b0) PCI device 00:06.0 (vd=10de:01d3 c=0300) Found 7 PCI devices (max PCI bus is 00) === PCI new allocation pass #1 === pmm_malloc zone=0x07fefe30 handle=ffffffff size=528 align=10 ret=0x07fe0100 (detail=0x07fe0310) PCI: check devices bus 0 === PCI new allocation pass #2 === PCI: init bases bus 0 (primary) type io max 100 sum 110 base c000 size 100: 1 bar(s), c000 -> c0ff size 10: 1 bar(s), c100 -> c10f type mem max 10000000 sum 12022000 base e0000000 size 10000000: 1 bar(s), e0000000 -> efffffff size 1000000: 2 bar(s), f0000000 -> f1ffffff size 10000: 2 bar(s), f2000000 -> f201ffff size 1000: 2 bar(s), f2020000 -> f2021fff type prefmem max 2000000 sum 2000000 base fc000000 size 2000000: 1 bar(s), fc000000 -> fdffffff PCI: map device bus 0, bfd 0x0 PCI: map device bus 0, bfd 0x8 PCI: map device bus 0, bfd 0x9 bar 4, addr c100, size 10 [io] PCI: map device bus 0, bfd 0xb PCI: map device bus 0, bfd 0x10 bar 0, addr fc000000, size 2000000 [mem] bar 1, addr f2020000, size 1000 [mem] bar 6, addr f2000000, size 10000 [mem] PCI: map device bus 0, bfd 0x18 bar 0, addr c000, size 100 [io] bar 1, addr f2021000, size 100 [mem] bar 6, addr f2010000, size 10000 [mem] PCI: map device bus 0, bfd 0x30 bar 0, addr f0000000, size 1000000 [mem] bar 1, addr e0000000, size 10000000 [mem] bar 3, addr f1000000, size 1000000 [mem] PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139 PCI: bus=0 devfn=0x30: vendor_id=0x10de device_id=0x01d3 PIIX3/PIIX4 init: elcr=00 0c pmm_free 0x07fe0100 (detail=0x07fe0310) init smm Found 1 cpu(s) max supported 1 cpu(s) init bios32 init PMM init PNPBIOS table init keyboard init mouse init PIR table init MPTable pmm_malloc zone=0x07fefe30 handle=ffffffff size=32768 align=10 ret=0x07fd8310 (detail=0x07fe0310) pmm_malloc zone=0x07fefe2c handle=ffffffff size=224 align=10 ret=0x000fdb10 (detail=0x07fd82e0) pmm_malloc zone=0x07fefe2c handle=ffffffff size=16 align=10 ret=0x000fdb00 (detail=0x07fd82b0) pmm_free 0x07fd8310 (detail=0x07fe0310) MP table addr=0x000fdb00 MPC table addr=0x000fdb10 size=224 init SMBIOS tables pmm_malloc zone=0x07fefe30 handle=ffffffff size=32768 align=10 ret=0x07fd8310 (detail=0x07fe0310) pmm_malloc zone=0x07fefe2c handle=ffffffff size=31 align=10 ret=0x000fdae0 (detail=0x07fd8280) pmm_malloc zone=0x07fefe2c handle=ffffffff size=263 align=10 ret=0x000fd9d0 (detail=0x07fd8250) SMBIOS ptr=0x000fdae0 table=0x000fd9d0 size=263 pmm_free 0x07fd8310 (detail=0x07fe0310) init ACPI tables pmm_malloc zone=0x07fefe34 handle=ffffffff size=116 align=10 ret=0x07ffff80 (detail=0x07fe0310) pmm_malloc zone=0x07fefe34 handle=ffffffff size=64 align=40 ret=0x07ffff40 (detail=0x07fe02e0) pmm_malloc zone=0x07fefe34 handle=ffffffff size=9609 align=10 ret=0x07ffd9b0 (detail=0x07fe02b0) pmm_malloc zone=0x07fefe34 handle=ffffffff size=158 align=10 ret=0x07ffd910 (detail=0x07fe0280) pmm_malloc zone=0x07fefe34 handle=ffffffff size=224 align=10 ret=0x07ffd830 (detail=0x07fe0250) pmm_malloc zone=0x07fefe34 handle=ffffffff size=56 align=10 ret=0x07ffd7f0 (detail=0x07fe0220) pmm_malloc zone=0x07fefe34 handle=ffffffff size=52 align=10 ret=0x07ffd7b0 (detail=0x07fe01f0) pmm_malloc zone=0x07fefe2c handle=ffffffff size=36 align=10 ret=0x000fd9a0 (detail=0x07fe01c0) ACPI tables: RSDP=0x000fd9a0 RSDT=0x07ffd7b0 Scan for VGA option rom Attempting to init PCI bdf 00:02.0 (vd 1013:00b8) Attempting to map option rom on dev 00:02.0 Option rom sizing returned f2000000 ffff0000 Inspecting possible rom at 0xf2000000 (vd=1013:00b8 bdf=00:02.0) Copying option rom (size 35840) from 0xf2000000 to c0000 Checking rom 0x000c0000 (sig aa55 size 70) Running option rom at c000:0003 Turning on vga text mode console SeaBIOS (version 1.6.3-20111012_174214-rock) (..cut here..) 4) When using TWO video cards, SeaBIOS reports as follows: $ sudo kvm -drive file=/dev/sdc -device pci-assign,host=02:00.0,addr=0x6 -device pci-assign,host=03:00.0,addr=0x7 -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios 2>&1 -------------------- Start bios (version 1.6.3-20111012_174214-rock) enabling shadow ram qemu_cfg_present=1 Find memory size Add to e820 map: 00000000 08000000 1 Add to e820 map: 00000000 00000000 1 Add to e820 map: fffc0000 00040000 2 Add to e820 map: 000a0000 00050000 -1 Add to e820 map: 000f0000 00010000 2 Add to e820 map: feffc000 00004000 2 Ram Size=0x08000000 (0x0000000000000000 high) malloc setup Add to e820 map: 07ff0000 00010000 2 pmm_malloc zone=0x000f0930 handle=ffffffff size=63248 align=10 ret=0x07fe07d0 (detail=0x07fefee0) Relocating init from 0x000e12d0 to 0x07fe07d0 (size 63248) malloc fixup reloc init ivt init bda Add to e820 map: 0009fc00 00000400 2 init pic init timer tsc calibrate start=2127316692 end=2133865272 diff=6548580 CPU Mhz=3815 math cp init init mtrr pci setup === PCI bus & bridge init === PCI: pci_bios_init_bus_rec bus = 0x0 === PCI device probing === PCI probe pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0700 (detail=0x07fe0770) PCI device 00:00.0 (vd=8086:1237 c=0600) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0660 (detail=0x07fe06d0) PCI device 00:01.0 (vd=8086:7000 c=0601) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe05c0 (detail=0x07fe0630) PCI device 00:01.1 (vd=8086:7010 c=0101) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0520 (detail=0x07fe0590) PCI device 00:01.3 (vd=8086:7113 c=0680) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0480 (detail=0x07fe04f0) PCI device 00:02.0 (vd=1013:00b8 c=0300) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe03e0 (detail=0x07fe0450) PCI device 00:03.0 (vd=10ec:8139 c=0200) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe0340 (detail=0x07fe03b0) PCI device 00:06.0 (vd=10de:01d3 c=0300) pmm_malloc zone=0x07fefe30 handle=ffffffff size=112 align=10 ret=0x07fe02a0 (detail=0x07fe0310) PCI device 00:07.0 (vd=10de:01d3 c=0300) Found 8 PCI devices (max PCI bus is 00) === PCI new allocation pass #1 === pmm_malloc zone=0x07fefe30 handle=ffffffff size=528 align=10 ret=0x07fe0060 (detail=0x07fe0270) PCI: check devices bus 0 PCI: out of address space

1 0

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS