December 2015 - SeaBIOS - mail.coreboot.org

5 basic features provided by CSM, which SeaBIOS does provide?
by Stojsavljevic, Zoran Dec. 18, 2015

Dec. 18, 2015

Hello both lists, Jiming, There are 5 basic features, provided by CSM SeaBIOS payload, and I am looking to list of these features. Could you, please, provide to me list of these features, and some description, and/or pointer to these descriptions? Thank you in advance, Zoran Stojsavljevic _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928

1 0

[PATCH 0/6] seabios: update to release 1.9.0
by Gerd Hoffmann Dec. 18, 2015

Dec. 18, 2015

Hi, seabios 1.9.0 was released in November, missing hard freeze by a few days. Now 2.5 is out of the door and the master branch is open, time to care about the update now, so here we go. The patch series carries the seabios update itself, a few build and config adjustments and acpi cleanups. The update is also available here: git://git.kraxel.org/qemu work/seabios Please test & review, Gerd PS: Pull request will most likely have to wait until january, when I'm back online after xmas and newyear vacation. Gerd Hoffmann (6): seabios: update submodule to release 1.9.0 seabios: update 128k bios config seabios: use new EXTRAVERSION to tag qemu builds seabios: stop updating aml files seabios: update binaries to release 1.9.0 q35: skip q35-acpi-dsdt.aml load if not needed hw/i386/pc_q35.c | 5 ++++- pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes pc-bios/bios.bin | Bin 131072 -> 131072 bytes pc-bios/vgabios-cirrus.bin | Bin 38400 -> 38400 bytes pc-bios/vgabios-qxl.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios-stdvga.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios-virtio.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios-vmware.bin | Bin 38400 -> 38912 bytes pc-bios/vgabios.bin | Bin 38400 -> 38400 bytes roms/Makefile | 7 +++---- roms/config.seabios-128k | 2 ++ roms/seabios | 2 +- 12 files changed, 10 insertions(+), 6 deletions(-) -- 1.8.3.1

3 8

Re: [SeaBIOS] SeaBIOS Digest, Vol 73, Issue 11
by jwang＠whu.edu.cn Dec. 18, 2015

Dec. 18, 2015

> -----原始邮件----- > 发件人: seabios-request(a)seabios.org > 发送时间: 2015年12月18日星期五 > 收件人: seabios(a)seabios.org > 抄送: > 主题: SeaBIOS Digest, Vol 73, Issue 11 > > Send SeaBIOS mailing list submissions to > seabios(a)seabios.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.seabios.org/mailman/listinfo/seabios > or, via email, send a message with subject or body 'help' to > seabios-request(a)seabios.org > > You can reach the person managing the list at > seabios-owner(a)seabios.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SeaBIOS digest..." > > > Today's Topics: > > 1. Re: [Qemu-devel] [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load > if not needed (Marcel Apfelbaum) > 2. Re: [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load if not > needed (Eduardo Habkost) > 3. Re: SeaBIOS recognising USB 3.0 on boot works - partly > (Kevin O'Connor) > 4. Re: SeaBIOS Digest, Vol 72, Issue 33 (Kevin O'Connor) > 5. Re: Qemu-kvm VM halt at allocate VGA stack when continuously > reset VM (Kevin O'Connor) > 6. Re: Qemu-kvm VM halt at allocate VGA stack when continuously > reset VM (Xulei (Stone)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 Dec 2015 18:49:05 +0200 > From: Marcel Apfelbaum <marcel.apfelbaum(a)gmail.com> > To: Gerd Hoffmann <kraxel(a)redhat.com>, qemu-devel(a)nongnu.org > Cc: Eduardo Habkost <ehabkost(a)redhat.com>, "Michael S. Tsirkin" > <mst(a)redhat.com>, seabios(a)seabios.org, Paolo Bonzini > <pbonzini(a)redhat.com>, Richard Henderson <rth(a)twiddle.net> > Subject: Re: [SeaBIOS] [Qemu-devel] [PATCH 6/6] q35: skip > q35-acpi-dsdt.aml load if not needed > Message-ID: <5672E781.1010802(a)gmail.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > M > On 12/17/2015 12:40 PM, Gerd Hoffmann wrote: > > Only old machine types which don't use the acpi builder (qemu 1.7 + older) > > have to load that file for proper acpi support. > > > > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> > > --- > > hw/i386/pc_q35.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c > > index 133bc68..727269e 100644 > > --- a/hw/i386/pc_q35.c > > +++ b/hw/i386/pc_q35.c > > @@ -129,7 +129,10 @@ static void pc_q35_init(MachineState *machine) > > } > > > > pc_cpus_init(pcms); > > - pc_acpi_init("q35-acpi-dsdt.aml"); > > + if (!has_acpi_build) { > > + /* only machine types 1.7 & older need this */ > > Actually 1.6 and older, right? (I might be wrong) > > > + pc_acpi_init("q35-acpi-dsdt.aml"); > > + } > > > > kvmclock_create(); > > > > > > It looks OK to me. > > Reviewed-by: Marcel Apfelbaum <marcel(a)redhat.com> > > Thanks, > Marcel > > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Dec 2015 15:22:46 -0200 > From: Eduardo Habkost <ehabkost(a)redhat.com> > To: Gerd Hoffmann <kraxel(a)redhat.com> > Cc: qemu-devel(a)nongnu.org, seabios(a)seabios.org, Paolo Bonzini > <pbonzini(a)redhat.com>, Richard Henderson <rth(a)twiddle.net>, "Michael > S. Tsirkin" <mst(a)redhat.com>, Igor Mammedov <imammedo(a)redhat.com> > Subject: Re: [SeaBIOS] [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load if > not needed > Message-ID: <20151217172246.GQ3774(a)thinpad.lan.raisama.net> > Content-Type: text/plain; charset=us-ascii > > On Thu, Dec 17, 2015 at 11:40:49AM +0100, Gerd Hoffmann wrote: > > Only old machine types which don't use the acpi builder (qemu 1.7 + older) > > have to load that file for proper acpi support. > > > > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> > > --- > > hw/i386/pc_q35.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c > > index 133bc68..727269e 100644 > > --- a/hw/i386/pc_q35.c > > +++ b/hw/i386/pc_q35.c > > @@ -129,7 +129,10 @@ static void pc_q35_init(MachineState *machine) > > } > > > > pc_cpus_init(pcms); > > - pc_acpi_init("q35-acpi-dsdt.aml"); > > + if (!has_acpi_build) { > > + /* only machine types 1.7 & older need this */ > > + pc_acpi_init("q35-acpi-dsdt.aml"); > > + } > > This conflicts with: > > Subject: [Qemu-devel] [PATCH v3 0/6] pc: Initialization and compat function cleanup > Date: Tue, 1 Dec 2015 20:58:02 -0200 > Message-Id: <1449010688-19205-1-git-send-email-ehabkost(a)redhat.com> > > But rebasing it is very simple (just replace has_acpi_build with > pcmc->has_acpi_build). > > But I would prefer to finally apply the series that deletes > pc-q35-2.3 and older (submitted in August), so we just can delete > this code. > > -- > Eduardo > > > > ------------------------------ > > Message: 3 > Date: Thu, 17 Dec 2015 17:17:17 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: edward wandasiewicz <0.w3ntd(a)gmail.com> > Cc: seabios(a)seabios.org, John Lewis <jlewis(a)johnlewis.ie> > Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - > partly > Message-ID: <20151217221717.GA8967(a)morn.lan> > Content-Type: text/plain; charset=us-ascii > > On Mon, Dec 14, 2015 at 07:02:14PM -0500, Kevin O'Connor wrote: > > The double detection looks like the controller doing something weird. > > I need to look closer at the spec, but I don't think I'll be able to > > do that until later in the week. > > After reviewing the spec I have a guess to what is occurring. Can you > pull the "testing" branch again and retry? > > -Kevin > > > > ------------------------------ > > Message: 4 > Date: Thu, 17 Dec 2015 17:22:56 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: Wim Vervoorn <wvervoorn(a)eltan.com> > Cc: "seabios(a)seabios.org" <seabios(a)seabios.org>, Stefan Berger > <stefanb(a)us.ibm.com> > Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33 > Message-ID: <20151217222256.GA9447(a)morn.lan> > Content-Type: text/plain; charset=us-ascii > > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote: > > Hello, > > > > I noticed that a lot of work is going on for the TPM support in SeaBIOS. > > > > All of this work is TPM 1.2 based. I was wondering if there are any > > plans to support TPM 2.0 in the future. > > I'm not aware of any plans. > > -Kevin > > > > ------------------------------ > > Message: 5 > Date: Thu, 17 Dec 2015 17:28:52 -0500 > From: Kevin O'Connor <kevin(a)koconnor.net> > To: "Xulei (Stone)" <stone.xulei(a)huawei.com> > Cc: "seabios(a)seabios.org" <seabios(a)seabios.org> > Subject: Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when > continuously reset VM > Message-ID: <20151217222851.GB9447(a)morn.lan> > Content-Type: text/plain; charset=us-ascii > > On Thu, Dec 17, 2015 at 05:28:23AM +0000, Xulei (Stone) wrote: > > 1. This problem seems have relations with PIC irq0 and host CPU feature: > > On one of my host, this problem never happens while on another, it's > > very easy to happen (both of hosts have the same kmod,qemu,libvirt and > > SeaBIOS, SeaVGABIOS, except for the CPU feature). > > > > 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something > > wrong printing handle_smp log. > > > > 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, > > and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. > > > > For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly > > when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). > > At first glance, this sounds like there is a level based interrupt > enabled somewhere and after a reset the apic isn't disabled. It > doesn't seem like a seabios issue - as seabios doesn't really use the > apic. I'd raise it on the qemu list. > > -Kevin > > > > ------------------------------ > > Message: 6 > Date: Fri, 18 Dec 2015 00:02:04 +0000 > From: "Xulei (Stone)" <stone.xulei(a)huawei.com> > To: Mohammed Gamal <mohammed.gamal(a)profitbricks.com>, "Kevin O'Connor" > <kevin(a)koconnor.net> > Cc: "seabios(a)seabios.org" <seabios(a)seabios.org> > Subject: Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when > continuously reset VM > Message-ID: > <8E78D212B8C25246BE4CE7EA0E645FE52E0888(a)SZXEMI504-MBS.china.huawei.com> > > Content-Type: text/plain; charset="utf-8" > > Thanks for Gamal's and Kevin's reply. > Here i'd like to provide more information: > - My VM is running under KVM (KMOD 3.6); > - qmp returns: > virsh # qemu-monitor-command hrg_sles11_sp3_64_2U_ide --pretty '{"execute":"query-kvm"}' > { > "return": { > "enabled": true, > "present": true > }, > "id": "libvirt-18099" > } > - kmod ftrace returns: > > <...>-113789 [014] 858323.684996: kvm_emulate_insn: f0000:9:ff ff (real) > <...>-113789 [014] 858323.684996: kvm_inj_exception: #UD (0x0) > <...>-113789 [014] 858323.684996: kvm_entry: vcpu 0 > <...>-113789 [014] 858323.684997: kvm_exit: reason EXCEPTION_NMI rip 0x9 info 0 80000306 > > <...>-113789 [014] 858323.684997: kvm_emulate_insn: f0000:9:ff ff (real) > <...>-113789 [014] 858323.684997: kvm_inj_exception: #UD (0x0) > <...>-113789 [014] 858323.684998: kvm_entry: vcpu 0 > <...>-113789 [014] 858323.684998: kvm_exit: reason EXCEPTION_NMI rip 0x9 info 0 80000306 > > So, it seems at some points, guest executes an invalid opcode triggering kmod injects exception UD > and seabios handle this exception through handle_hwpic1. > > Any idea? > >Hi Xulei, > > > >i have a few questions about the problem you're experiencing, since I do see something similar: > > > >- Is your VM running under KVM? > >- If yes, does the KVM process show any register dumps or failure messages? > >- What's the output of: > >$ virsh qemu-monitor-command devstack --pretty '{"execute":"query-kvm"}' > >when seabios fails to load? > > > >Regards, > >Mohammed > > > > > > > >On Thu, Dec 17, 2015 at 6:28 AM, Xulei (Stone) <stone.xulei(a)huawei.com> wrote: > > > > > > > > >On Wed, Dec 02, 2015 at 07:09:36AM +0000, Xulei (Stone) wrote: > > >> I move HaveRunPost = 1 to handle_post() (after make_bios_writable()), and > > >> I have tested for 1 day with continuously resetting, it seems works well! > > >> Does following patch have some side effects? > > > > > >Thanks. I'll be traveling for the next two weeks. I'll take a look > > >when I return. > > > > > > > Hi, Kevin: > > Welcome journey back! I keep on this problem for about 1 month. Here, > > I provide some detail information and wish you could pay a little time > > thinking about this. > > > > My test script is very easy: > > > > #!/bin/bash > > vmname=$1 > > while [ 1 ] > > do > > virsh reset $vmname & > > virsh reset $vmname & > > sleep 5 > > done > > > > > > 1. This problem seems have relations with PIC irq0 and host CPU feature: > > On one of my host, this problem never happens while on another, it's > > very easy to happen (both of hosts have the same kmod,qemu,libvirt and > > SeaBIOS, SeaVGABIOS, except for the CPU feature). > > > > 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something > > wrong printing handle_smp log. > > > > 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, > > and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. > > > > For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly > > when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). > > > > ==========bad SeaBIOS log========= > > [2015-12-17 12:37:30] In 32bit resume > > [2015-12-17 12:37:30] =====Attempting a hard reboot==== > > [2015-12-17 12:37:30] SeaBIOS (version rel-1.8.1-0-g4adadbd-20151217_104405-linux-emBwNn) > > [2015-12-17 12:37:30] No Xen hypervisor found. > > [2015-12-17 12:37:30] Running on QEMU (i440fx) > > [2015-12-17 12:37:30] Running on KVM > > [2015-12-17 12:37:30] RamSize: 0x80000000 [cmos] > > [2015-12-17 12:37:30] Relocating init from 0x000db230 to 0x7ffad360 (size 76768) > > [2015-12-17 12:37:30] Found QEMU fw_cfg > > [2015-12-17 12:37:30] RamBlock: addr 0x0000000000000000 len 0x0000000080000000 [e820] > > [2015-12-17 12:37:30] Moving pm_base to 0x600 > > [2015-12-17 12:37:30] boot order: > > [2015-12-17 12:37:30] 1: /pci@i0cf8/ide@1,1/drive@0/disk@0 > > [2015-12-17 12:37:30] 2: HALT > > [2015-12-17 12:37:30] maininit > > [2015-12-17 12:37:30] platform_hardware_setup > > [2015-12-17 12:37:30] init pic > > [2015-12-17 12:37:30] pic_setup > > [2015-12-17 12:37:30] pic_reset > > [2015-12-17 12:37:30] enable_hwirq > > [2015-12-17 12:37:30] CPU Mhz=3304 > > [2015-12-17 12:37:30] enable_hwirq > > [2015-12-17 12:37:30] enable_hwirq > > [2015-12-17 12:37:30] === PCI bus & bridge init === > > [2015-12-17 12:37:30] PCI: pci_bios_init_bus_rec bus = 0x0 > > [2015-12-17 12:37:30] === PCI device probing === > > [2015-12-17 12:37:30] Found 6 PCI devices (max PCI bus is 00) > > [2015-12-17 12:37:30] === PCI new allocation pass #1 === > > [2015-12-17 12:37:30] PCI: check devices > > [2015-12-17 12:37:30] === PCI new allocation pass #2 === > > [2015-12-17 12:37:30] PCI: IO: c000 - c02f > > [2015-12-17 12:37:30] PCI: 32: 0000000080000000 - 00000000fec00000 > > [2015-12-17 12:37:30] PCI: map device bdf=00:01.2 bar 4, addr 0000c000, size 00000020 [io] > > [2015-12-17 12:37:30] PCI: map device bdf=00:01.1 bar 4, addr 0000c020, size 00000010 [io] > > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 6, addr febe0000, size 00010000 [mem] > > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 1, addr febf0000, size 00001000 [mem] > > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 0, addr fc000000, size 02000000 [prefmem] > > [2015-12-17 12:37:30] PCI: init bdf=00:00.0 id=8086:1237 > > [2015-12-17 12:37:30] PCI: init bdf=00:01.0 id=8086:7000 > > [2015-12-17 12:37:30] PIIX3/PIIX4 init: elcr=00 0c > > [2015-12-17 12:37:30] PCI: init bdf=00:01.1 id=8086:7010 > > [2015-12-17 12:37:30] PCI: init bdf=00:01.2 id=8086:7020 > > [2015-12-17 12:37:30] PCI: init bdf=00:01.3 id=8086:7113 > > [2015-12-17 12:37:30] Using pmtimer, ioport 0x608 > > [2015-12-17 12:37:30] PCI: init bdf=00:02.0 id=1013:00b8 > > [2015-12-17 12:37:30] PCI: Using 00:02.0 for primary VGA > > [2015-12-17 12:37:30] handle_hshamanpnd:dl leae_p_sismcmp_p:i: d a=ap3 <<======= here, seems abnormal! > > [2015-12-17 12:37:30] i?f[cf_^ifd_=f3 > > [2015-12-17 12:37:30] ?f[f^f_f]f??^X?<90>Found 4 cpu(s) max supported 4 cpu(s) > > [2015-12-17 12:37:30] Copying PIR from 0x7ffbea18 to 0x000f5700 > > [2015-12-17 12:37:30] Copying MPTABLE from 0x00006e30/7ffa42c0 to 0x000f55e0 > > [2015-12-17 12:37:30] Copying SMBIOS entry point from 0x00006e11 to 0x000f55c0 > > [2015-12-17 12:37:31] Scan for VGA option rom > > [2015-12-17 12:37:31] Running option rom at c000:0003 > > [2015-12-17 12:37:31] Start SeaVGABIOS (version rel-1.8.1-0-g4adadbd-20150316_085902-nilsson.home.kraxel.org) > > [2015-12-17 12:37:31] enter vga_post: > > [2015-12-17 12:37:31] a=00000010 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000 > > [2015-12-17 12:37:31] si=00000000 di=000057e0 bp=00000000 sp=00006dbe cs=f000 ip=d1fb f=0000 > > [2015-12-17 12:37:31] cirrus init > > [2015-12-17 12:37:31] cirrus init 2 > > [2015-12-17 12:37:31] Attempting to allocate VGA stack via pmm call to f000:d2a0 <<====== here stuck, loop handle PIC irq0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > > ... always hanle_hwpic1 irq=0, never ends anymore... > > > > >-Kevin > > _______________________________________________ > > SeaBIOS mailing list > > SeaBIOS(a)seabios.org > > http://www.seabios.org/mailman/listinfo/seabios > > > > > > > > > >-- > > > >Mohammed Gamal > >Software Engineer > > > >ProfitBricks GmbH > >Greifswalder Stra?e 207 > >D - 10405 Berlin > > > >Tel: +49 30 577 008 20 > >Email: mohammed.gamal(a)profitbricks.com <mailto:axel.herr@profitbricks.com> > > > >Web: http://www.profitbricks.de > > > >Sitz der Gesellschaft: Berlin. > >Registergericht: Amtsgericht Charlottenburg, HRB 125506B. > >Gesch?ftsf?hrer: Andreas Gauger, Achim Weiss. > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > > ------------------------------ > > End of SeaBIOS Digest, Vol 73, Issue 11 > *************************************** -- Best Wishes! *********************************************************************************************** Juan Wang Computer School, Wuhan University Key Laboratory of Aerospace Information Security and Trusted Computing, Ministry of Education Mobile Phone : 18986213038 E-Mail : jwang(a)whu.edu.cn ***********************************************************************************************

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) Dec. 18, 2015

Dec. 18, 2015

Thanks for Gamal's and Kevin's reply. Here i'd like to provide more information: - My VM is running under KVM (KMOD 3.6); - qmp returns: virsh # qemu-monitor-command hrg_sles11_sp3_64_2U_ide --pretty '{"execute":"query-kvm"}' { "return": { "enabled": true, "present": true }, "id": "libvirt-18099" } - kmod ftrace returns: <...>-113789 [014] 858323.684996: kvm_emulate_insn: f0000:9:ff ff (real) <...>-113789 [014] 858323.684996: kvm_inj_exception: #UD (0x0) <...>-113789 [014] 858323.684996: kvm_entry: vcpu 0 <...>-113789 [014] 858323.684997: kvm_exit: reason EXCEPTION_NMI rip 0x9 info 0 80000306 <...>-113789 [014] 858323.684997: kvm_emulate_insn: f0000:9:ff ff (real) <...>-113789 [014] 858323.684997: kvm_inj_exception: #UD (0x0) <...>-113789 [014] 858323.684998: kvm_entry: vcpu 0 <...>-113789 [014] 858323.684998: kvm_exit: reason EXCEPTION_NMI rip 0x9 info 0 80000306 So, it seems at some points, guest executes an invalid opcode triggering kmod injects exception UD and seabios handle this exception through handle_hwpic1. Any idea? >Hi Xulei, > >i have a few questions about the problem you're experiencing, since I do see something similar: > >- Is your VM running under KVM? >- If yes, does the KVM process show any register dumps or failure messages? >- What's the output of: >$ virsh qemu-monitor-command devstack --pretty '{"execute":"query-kvm"}' >when seabios fails to load? > >Regards, >Mohammed > > > >On Thu, Dec 17, 2015 at 6:28 AM, Xulei (Stone) <stone.xulei(a)huawei.com> wrote: > > > > >On Wed, Dec 02, 2015 at 07:09:36AM +0000, Xulei (Stone) wrote: > >> I move HaveRunPost = 1 to handle_post() (after make_bios_writable()), and > >> I have tested for 1 day with continuously resetting, it seems works well! > >> Does following patch have some side effects? > > > >Thanks. I'll be traveling for the next two weeks. I'll take a look > >when I return. > > > > Hi, Kevin: > Welcome journey back! I keep on this problem for about 1 month. Here, > I provide some detail information and wish you could pay a little time > thinking about this. > > My test script is very easy: > > #!/bin/bash > vmname=$1 > while [ 1 ] > do > virsh reset $vmname & > virsh reset $vmname & > sleep 5 > done > > > 1. This problem seems have relations with PIC irq0 and host CPU feature: > On one of my host, this problem never happens while on another, it's > very easy to happen (both of hosts have the same kmod,qemu,libvirt and > SeaBIOS, SeaVGABIOS, except for the CPU feature). > > 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something > wrong printing handle_smp log. > > 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, > and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. > > For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly > when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). > > ==========bad SeaBIOS log========= > [2015-12-17 12:37:30] In 32bit resume > [2015-12-17 12:37:30] =====Attempting a hard reboot==== > [2015-12-17 12:37:30] SeaBIOS (version rel-1.8.1-0-g4adadbd-20151217_104405-linux-emBwNn) > [2015-12-17 12:37:30] No Xen hypervisor found. > [2015-12-17 12:37:30] Running on QEMU (i440fx) > [2015-12-17 12:37:30] Running on KVM > [2015-12-17 12:37:30] RamSize: 0x80000000 [cmos] > [2015-12-17 12:37:30] Relocating init from 0x000db230 to 0x7ffad360 (size 76768) > [2015-12-17 12:37:30] Found QEMU fw_cfg > [2015-12-17 12:37:30] RamBlock: addr 0x0000000000000000 len 0x0000000080000000 [e820] > [2015-12-17 12:37:30] Moving pm_base to 0x600 > [2015-12-17 12:37:30] boot order: > [2015-12-17 12:37:30] 1: /pci@i0cf8/ide@1,1/drive@0/disk@0 > [2015-12-17 12:37:30] 2: HALT > [2015-12-17 12:37:30] maininit > [2015-12-17 12:37:30] platform_hardware_setup > [2015-12-17 12:37:30] init pic > [2015-12-17 12:37:30] pic_setup > [2015-12-17 12:37:30] pic_reset > [2015-12-17 12:37:30] enable_hwirq > [2015-12-17 12:37:30] CPU Mhz=3304 > [2015-12-17 12:37:30] enable_hwirq > [2015-12-17 12:37:30] enable_hwirq > [2015-12-17 12:37:30] === PCI bus & bridge init === > [2015-12-17 12:37:30] PCI: pci_bios_init_bus_rec bus = 0x0 > [2015-12-17 12:37:30] === PCI device probing === > [2015-12-17 12:37:30] Found 6 PCI devices (max PCI bus is 00) > [2015-12-17 12:37:30] === PCI new allocation pass #1 === > [2015-12-17 12:37:30] PCI: check devices > [2015-12-17 12:37:30] === PCI new allocation pass #2 === > [2015-12-17 12:37:30] PCI: IO: c000 - c02f > [2015-12-17 12:37:30] PCI: 32: 0000000080000000 - 00000000fec00000 > [2015-12-17 12:37:30] PCI: map device bdf=00:01.2 bar 4, addr 0000c000, size 00000020 [io] > [2015-12-17 12:37:30] PCI: map device bdf=00:01.1 bar 4, addr 0000c020, size 00000010 [io] > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 6, addr febe0000, size 00010000 [mem] > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 1, addr febf0000, size 00001000 [mem] > [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 0, addr fc000000, size 02000000 [prefmem] > [2015-12-17 12:37:30] PCI: init bdf=00:00.0 id=8086:1237 > [2015-12-17 12:37:30] PCI: init bdf=00:01.0 id=8086:7000 > [2015-12-17 12:37:30] PIIX3/PIIX4 init: elcr=00 0c > [2015-12-17 12:37:30] PCI: init bdf=00:01.1 id=8086:7010 > [2015-12-17 12:37:30] PCI: init bdf=00:01.2 id=8086:7020 > [2015-12-17 12:37:30] PCI: init bdf=00:01.3 id=8086:7113 > [2015-12-17 12:37:30] Using pmtimer, ioport 0x608 > [2015-12-17 12:37:30] PCI: init bdf=00:02.0 id=1013:00b8 > [2015-12-17 12:37:30] PCI: Using 00:02.0 for primary VGA > [2015-12-17 12:37:30] handle_hshamanpnd:dl leae_p_sismcmp_p:i: d a=ap3 <<======= here, seems abnormal! > [2015-12-17 12:37:30] ièf[cf_^ifd_=f3 > [2015-12-17 12:37:30] èf[f^f_f]fÃÍ^XË<90>Found 4 cpu(s) max supported 4 cpu(s) > [2015-12-17 12:37:30] Copying PIR from 0x7ffbea18 to 0x000f5700 > [2015-12-17 12:37:30] Copying MPTABLE from 0x00006e30/7ffa42c0 to 0x000f55e0 > [2015-12-17 12:37:30] Copying SMBIOS entry point from 0x00006e11 to 0x000f55c0 > [2015-12-17 12:37:31] Scan for VGA option rom > [2015-12-17 12:37:31] Running option rom at c000:0003 > [2015-12-17 12:37:31] Start SeaVGABIOS (version rel-1.8.1-0-g4adadbd-20150316_085902-nilsson.home.kraxel.org) > [2015-12-17 12:37:31] enter vga_post: > [2015-12-17 12:37:31] a=00000010 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000 > [2015-12-17 12:37:31] si=00000000 di=000057e0 bp=00000000 sp=00006dbe cs=f000 ip=d1fb f=0000 > [2015-12-17 12:37:31] cirrus init > [2015-12-17 12:37:31] cirrus init 2 > [2015-12-17 12:37:31] Attempting to allocate VGA stack via pmm call to f000:d2a0 <<====== here stuck, loop handle PIC irq0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > [2015-12-17 12:37:35] handle_hwpic1 irq=0 > ... always hanle_hwpic1 irq=0, never ends anymore... > > >-Kevin > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios > > > > >-- > >Mohammed Gamal >Software Engineer > >ProfitBricks GmbH >Greifswalder Straße 207 >D - 10405 Berlin > >Tel: +49 30 577 008 20 >Email: mohammed.gamal(a)profitbricks.com <mailto:axel.herr@profitbricks.com> > >Web: http://www.profitbricks.de > >Sitz der Gesellschaft: Berlin. >Registergericht: Amtsgericht Charlottenburg, HRB 125506B. >Geschäftsführer: Andreas Gauger, Achim Weiss.

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Kevin O'Connor Dec. 17, 2015

Dec. 17, 2015

On Thu, Dec 17, 2015 at 05:28:23AM +0000, Xulei (Stone) wrote: > 1. This problem seems have relations with PIC irq0 and host CPU feature: > On one of my host, this problem never happens while on another, it's > very easy to happen (both of hosts have the same kmod,qemu,libvirt and > SeaBIOS, SeaVGABIOS, except for the CPU feature). > > 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something > wrong printing handle_smp log. > > 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, > and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. > > For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly > when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). At first glance, this sounds like there is a level based interrupt enabled somewhere and after a reset the apic isn't disabled. It doesn't seem like a seabios issue - as seabios doesn't really use the apic. I'd raise it on the qemu list. -Kevin

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) Dec. 17, 2015

Dec. 17, 2015

>On Wed, Dec 02, 2015 at 07:09:36AM +0000, Xulei (Stone) wrote: >> I move HaveRunPost = 1 to handle_post() (after make_bios_writable()), and >> I have tested for 1 day with continuously resetting, it seems works well! >> Does following patch have some side effects? > >Thanks. I'll be traveling for the next two weeks. I'll take a look >when I return. > Hi, Kevin: Welcome journey back! I keep on this problem for about 1 month. Here, I provide some detail information and wish you could pay a little time thinking about this. My test script is very easy: #!/bin/bash vmname=$1 while [ 1 ] do virsh reset $vmname & virsh reset $vmname & sleep 5 done 1. This problem seems have relations with PIC irq0 and host CPU feature: On one of my host, this problem never happens while on another, it's very easy to happen (both of hosts have the same kmod,qemu,libvirt and SeaBIOS, SeaVGABIOS, except for the CPU feature). 2. SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something wrong printing handle_smp log. 3. If i disconfig CONFIG_VGA_ALLOCATE_EXTRA_STACK, the VM will halt at Grub stage, and SeaVGABIOS log stop at printing "set VGA mode 114", then BIOS will loop handle_pwhic1. For now, i guess whether if SeaBIOS can not handle the hardware interrupt correctly when a host CPU has some advanced feature (x2apic? avx? xsave? tsc-deadline?). ==========bad SeaBIOS log========= [2015-12-17 12:37:30] In 32bit resume [2015-12-17 12:37:30] =====Attempting a hard reboot==== [2015-12-17 12:37:30] SeaBIOS (version rel-1.8.1-0-g4adadbd-20151217_104405-linux-emBwNn) [2015-12-17 12:37:30] No Xen hypervisor found. [2015-12-17 12:37:30] Running on QEMU (i440fx) [2015-12-17 12:37:30] Running on KVM [2015-12-17 12:37:30] RamSize: 0x80000000 [cmos] [2015-12-17 12:37:30] Relocating init from 0x000db230 to 0x7ffad360 (size 76768) [2015-12-17 12:37:30] Found QEMU fw_cfg [2015-12-17 12:37:30] RamBlock: addr 0x0000000000000000 len 0x0000000080000000 [e820] [2015-12-17 12:37:30] Moving pm_base to 0x600 [2015-12-17 12:37:30] boot order: [2015-12-17 12:37:30] 1: /pci@i0cf8/ide@1,1/drive@0/disk@0 [2015-12-17 12:37:30] 2: HALT [2015-12-17 12:37:30] maininit [2015-12-17 12:37:30] platform_hardware_setup [2015-12-17 12:37:30] init pic [2015-12-17 12:37:30] pic_setup [2015-12-17 12:37:30] pic_reset [2015-12-17 12:37:30] enable_hwirq [2015-12-17 12:37:30] CPU Mhz=3304 [2015-12-17 12:37:30] enable_hwirq [2015-12-17 12:37:30] enable_hwirq [2015-12-17 12:37:30] === PCI bus & bridge init === [2015-12-17 12:37:30] PCI: pci_bios_init_bus_rec bus = 0x0 [2015-12-17 12:37:30] === PCI device probing === [2015-12-17 12:37:30] Found 6 PCI devices (max PCI bus is 00) [2015-12-17 12:37:30] === PCI new allocation pass #1 === [2015-12-17 12:37:30] PCI: check devices [2015-12-17 12:37:30] === PCI new allocation pass #2 === [2015-12-17 12:37:30] PCI: IO: c000 - c02f [2015-12-17 12:37:30] PCI: 32: 0000000080000000 - 00000000fec00000 [2015-12-17 12:37:30] PCI: map device bdf=00:01.2 bar 4, addr 0000c000, size 00000020 [io] [2015-12-17 12:37:30] PCI: map device bdf=00:01.1 bar 4, addr 0000c020, size 00000010 [io] [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 6, addr febe0000, size 00010000 [mem] [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 1, addr febf0000, size 00001000 [mem] [2015-12-17 12:37:30] PCI: map device bdf=00:02.0 bar 0, addr fc000000, size 02000000 [prefmem] [2015-12-17 12:37:30] PCI: init bdf=00:00.0 id=8086:1237 [2015-12-17 12:37:30] PCI: init bdf=00:01.0 id=8086:7000 [2015-12-17 12:37:30] PIIX3/PIIX4 init: elcr=00 0c [2015-12-17 12:37:30] PCI: init bdf=00:01.1 id=8086:7010 [2015-12-17 12:37:30] PCI: init bdf=00:01.2 id=8086:7020 [2015-12-17 12:37:30] PCI: init bdf=00:01.3 id=8086:7113 [2015-12-17 12:37:30] Using pmtimer, ioport 0x608 [2015-12-17 12:37:30] PCI: init bdf=00:02.0 id=1013:00b8 [2015-12-17 12:37:30] PCI: Using 00:02.0 for primary VGA [2015-12-17 12:37:30] handle_hshamanpnd:dl leae_p_sismcmp_p:i: d a=ap3 <<======= here, seems abnormal! [2015-12-17 12:37:30] ièf[cf_^ifd_=f3 [2015-12-17 12:37:30] èf[f^f_f]fÃÍ^XË<90>Found 4 cpu(s) max supported 4 cpu(s) [2015-12-17 12:37:30] Copying PIR from 0x7ffbea18 to 0x000f5700 [2015-12-17 12:37:30] Copying MPTABLE from 0x00006e30/7ffa42c0 to 0x000f55e0 [2015-12-17 12:37:30] Copying SMBIOS entry point from 0x00006e11 to 0x000f55c0 [2015-12-17 12:37:31] Scan for VGA option rom [2015-12-17 12:37:31] Running option rom at c000:0003 [2015-12-17 12:37:31] Start SeaVGABIOS (version rel-1.8.1-0-g4adadbd-20150316_085902-nilsson.home.kraxel.org) [2015-12-17 12:37:31] enter vga_post: [2015-12-17 12:37:31] a=00000010 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000 [2015-12-17 12:37:31] si=00000000 di=000057e0 bp=00000000 sp=00006dbe cs=f000 ip=d1fb f=0000 [2015-12-17 12:37:31] cirrus init [2015-12-17 12:37:31] cirrus init 2 [2015-12-17 12:37:31] Attempting to allocate VGA stack via pmm call to f000:d2a0 <<====== here stuck, loop handle PIC irq0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 [2015-12-17 12:37:35] handle_hwpic1 irq=0 ... always hanle_hwpic1 irq=0, never ends anymore... >-Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz Dec. 13, 2015

Dec. 13, 2015

On Sun, Dec 13, 2015 at 9:05 PM, edward wandasiewicz <0.w3ntd(a)gmail.com> wrote: > Hooray, it works... minus 2 scenarios :( > > With both Philips USB and Mushkin USB attached, and I perform a cold boot > > 1. YES - USB 3 & USB 3 - once each (Philips & Mushkin) > > cbmem.yes.both.USB3.USB3.gz > > 2. NO - USB 3 & USB 3 - once each (Philips & Muskin) - but double > Philips showing > > cbmem.yes.both.USB3.USB3.DoublePhilips.gz > > 3. YES - USB 3 & Type C - once each (Philips & Mushkin) > > cbmem.yes.both.USB3.TypeC.gz > > I can't get a double Philips to appear > > 4. YES - Type C & Type C - once each (Philips & Mushkin) > > cbmem.yes.both.TypeC.TypeC.gz > > 5. NO - Type C & Type C - one Philiips & no Mushkin > > I forgot to save > > $ cbmem -c > > and now can't replicate it. :( > > When I do, I will post output. When attempting a cold boot - shutdown - cold boot - shutdown - cold boot - shutdown - .... It seems the list of bootable devices can change order, yet the devices are plugged into the same ports all the time, and never unplugged. We can get 1. SSD 2. Philips USB 3. Mushkin USB or 1. SSD 2. Mushkin USB 3. Philips USB I think scenario 5 is special case of the above, former, but no Mushkin 1. SSD 2. Philips USB Hope this helps. Edward. > > Edward. > > On Sun, Dec 13, 2015 at 7:53 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Sun, Dec 13, 2015 at 10:49:30AM +0000, edward wandasiewicz wrote: >>> With both the Philips USB and Mushkin USB plugged in on boot, I'm >>> still getting 4 different scenarios appearing. >>> >>> 1. Philips Only >>> 2. Mushkin Only >>> 3. Both recognised - listed once and once only >>> 4. Both recognised - Mushkin once, but the Philips listed twice >>> >>> I've attached >>> >>> $cbmem -c >>> >>> for each scenario >> >> Thanks. It looks like the usb code wasn't waiting for USB3 devices to >> be "enabled" before trying to talk to them. Can you pull down the >> "testing" branch again and retry? >> >> Also, the logs are quite large and they are exceeding the mailing list >> limits - going forward can you gzip the logs and attach them to your >> emails. >> >> -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 13, 2015

Dec. 13, 2015

On Sun, Dec 13, 2015 at 10:49:30AM +0000, edward wandasiewicz wrote: > With both the Philips USB and Mushkin USB plugged in on boot, I'm > still getting 4 different scenarios appearing. > > 1. Philips Only > 2. Mushkin Only > 3. Both recognised - listed once and once only > 4. Both recognised - Mushkin once, but the Philips listed twice > > I've attached > > $cbmem -c > > for each scenario Thanks. It looks like the usb code wasn't waiting for USB3 devices to be "enabled" before trying to talk to them. Can you pull down the "testing" branch again and retry? Also, the logs are quite large and they are exceeding the mailing list limits - going forward can you gzip the logs and attach them to your emails. -Kevin

2 1

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 10, 2015

Dec. 10, 2015

On Fri, Dec 04, 2015 at 09:04:35PM +0000, edward wandasiewicz wrote: > Here's what happens with x1 Philips USB attached and x1 Mushkin > attached, and we cold boot with Kevin's patched SeaBIOS > > FIXED - when Philips drive is detected, it appears only once and once > only in the list of bootable devices - cbmem -c attached > > BROKE - the Mushkin drive hardly ever gets detected - Google ChromeOS > recovery SeaBIOS would always find it > > BROKEN - when Mushkin drive is detected, only the Mushkin is showing > in the list, no Philips in the list of bootable devices - cbmem -c > attached (reboot following a cold boot with Philips only showing) > > Sometimes Mushkin will appear on a cold boot - not very often, with no > Philips showing in the list, with both devices plugged in on boot up. [...] > |7cddd000| xhci_address: enable slot: got slotid 1 > |7cddd000| xhci_cmd_address_device: slotid 1 > |7cddd000| xhci_trb_queue: ring 0x7ce39d00 [nidx 2, len 0] > |7cddd000| xhci_process_events: ring 0x7ce39d00 [trb 0x7ce39d10, evt > 0x7ce39e00, type 33, eidx 2, cc 4] > |7cddd000| xhci_cmd_disable_slot: slotid 1 > |7cddd000| xhci_trb_queue: ring 0x7ce39d00 [nidx 3, len 0] > |7cddd000| xhci_process_events: ring 0x7ce39d00 [trb 0x7ce39d20, evt > 0x7ce39e00, type 33, eidx 3, cc 1] > |7cddd000| xhci_address: disable failed (cc 1/4) It looks like I messed up the error check on the patch. I uploaded a new patch. Can you clone the "testing" branch again and retry? Thanks, -Kevin

1 0

[PATCH] fw/pci: do not automatically allocate IO region for PCIe bridges
by Marcel Apfelbaum Dec. 7, 2015

Dec. 7, 2015

PCIe downstream ports (Root Ports and switches Downstream Ports) appear to firmware as PCI-PCI bridges and a 4K IO space is allocated for them even if there is no device behind them requesting IO space, all that for hotplug purpose. However, PCIe devices can work without IO, so there is no need to allocate IO space for hotplug. Signed-off-by: Marcel Apfelbaum <marcel(a)redhat.com> --- Notes: - This patch fixes a 15 PCIe Root ports limitation when used with virtio pci-express devices having no IO space requirements: <qemu cmd line> -M q35 `for i in {1..15}; do echo -device ioh3420,chassis=$i,id=b$i -device virtio-net-pci,bus=b$i,disable-legacy=on; done` - There is a patch on QEMU devel list that tackles the problem from another angle by allowing PCIe downstream ports to not forward IO requests. https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04478.html - The mentioned patch is of course not enough and also requires management software intervention. Thanks, Marcel src/fw/pciinit.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c index 7b8aab7..4b37792 100644 --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -736,7 +736,9 @@ static int pci_bios_check_devices(struct pci_bus *busses) if (pci_region_align(&s->r[type]) > align) align = pci_region_align(&s->r[type]); u64 sum = pci_region_sum(&s->r[type]); - if (!sum && hotplug_support) + int res_opt = (type == PCI_REGION_TYPE_IO) && + pci_find_capability(s->bus_dev, PCI_CAP_ID_EXP, 0); + if (!sum && hotplug_support && !res_opt) sum = align; /* reserve min size for hot-plug */ u64 size = ALIGN(sum, align); int is64 = pci_bios_bridge_region_is64(&s->r[type], -- 2.1.0

2 2

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 4, 2015

Dec. 4, 2015

On Fri, Dec 04, 2015 at 07:08:50PM +0000, edward wandasiewicz wrote: > On 4 Dec 2015 7:04 p.m., "Kevin O'Connor" <kevin(a)koconnor.net> wrote: > > > > On Fri, Dec 04, 2015 at 06:36:18PM +0000, edward wandasiewicz wrote: > > > @ John > > > > > > Is the work on SeaVGABIOS for CBFS work under construction for the > > > Broadwell based Pixel 2015? > > > > > > Looking at Kevin's chromeimage.sh - showing relevant parts only > > > > > > CBFSTOOL=cbfstool > > > PAYLOAD=out/bios.bin.elf > > > PAYLOADVGA=out/vgabios.bin > > [...] > > > # > > > # Add SeaVGABIOS to CBFS > > > # > > > $ CBFSTOOL $CBFSFILE add -f $PAYLOADVGA -n vgaroms/seavgabios.rom -t > optionrom > > > > > > Question - if it is work under construction, the above may or may not > > > show any VGA output? i.e. black screen > > > > > > Or give it a whirl, and I may surprise myself? > > > > > > Or stick with > > > > > > ## Extract vgabios from SeaBIOS CBFS area of original image. > > > > > > ORIGCBFSFILE=orig-seabios.cbfs > > > > > > $ dd if=$ORIGIMAGE of=$ORIGCBFSFILE skip=2 bs=2M count=1 2> /dev/null > > > > > > $ CBFSTOOL $ORIGCBFSFILE extract -n pci8086,0406.rom -f pci8086,0406.rom > > > > > > $ CBFSTOOL $CBFSFILE add -f pci8086,0406.rom -n pci8086,0a06.rom -t > optionrom > > > > The logs you sent me seemed to indicate that SeaVGABIOS was running, > > This means use vgaroms/seavgabios.rom > > and leave commented parts in a commented state - no need for > pci8086,0a06.rom parts Yes. -Kevin

2 1

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 4, 2015

Dec. 4, 2015

On Fri, Dec 04, 2015 at 06:36:18PM +0000, edward wandasiewicz wrote: > @ John > > Is the work on SeaVGABIOS for CBFS work under construction for the > Broadwell based Pixel 2015? > > Looking at Kevin's chromeimage.sh - showing relevant parts only > > CBFSTOOL=cbfstool > PAYLOAD=out/bios.bin.elf > PAYLOADVGA=out/vgabios.bin [...] > # > # Add SeaVGABIOS to CBFS > # > $ CBFSTOOL $CBFSFILE add -f $PAYLOADVGA -n vgaroms/seavgabios.rom -t optionrom > > Question - if it is work under construction, the above may or may not > show any VGA output? i.e. black screen > > Or give it a whirl, and I may surprise myself? > > Or stick with > > ## Extract vgabios from SeaBIOS CBFS area of original image. > > ORIGCBFSFILE=orig-seabios.cbfs > > $ dd if=$ORIGIMAGE of=$ORIGCBFSFILE skip=2 bs=2M count=1 2> /dev/null > > $ CBFSTOOL $ORIGCBFSFILE extract -n pci8086,0406.rom -f pci8086,0406.rom > > $ CBFSTOOL $CBFSFILE add -f pci8086,0406.rom -n pci8086,0a06.rom -t optionrom The logs you sent me seemed to indicate that SeaVGABIOS was running, and thus you should use the steps above. -Kevin

2 1

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 4, 2015

Dec. 4, 2015

On Fri, Dec 04, 2015 at 05:50:29PM +0000, edward wandasiewicz wrote: > Looking at the output from Googles ChromeOS shell-ball, I do: > > Write the hardware ID to get future ChromeOS updates > > $ ./gbb_utility --set --hwid="SAMUS XXX-YYY-ZZZ" bios.bin bios.hwid.bin > > # dd out 2 megs of the ROM at 4 megs in > > $ dd bs=1M skip=4 count=2 if=bios.hwid.bin of=rwlegacy.cbfs > > Using the flashrom from John's site as upstream doesn't know anything about > flashmap. > > $ wget https://johnlewis.ie/Chromebook-ROMs/utils/flashrom -O > flashrom.jlewis > > $ sudo ./flashrom.jlewis -w -i RW_LEGACY:rwlegacy.cbfs > > Looking at your script, ORIGIMAGE is my bios.hwid.bin > > Do I run flashrom from the shell-ball > > $ sudo flashrom -w ./newimage.rom -i RW_LEGACY > > Or John Lewis flashrom > > $ sudo flashrom.jlewis.version -w ./newimage.rom -i RW_LEGACY I would guess that either would work. Upstream flashrom is likely not going to work (if it doesn't support flashmap). As long as the flashrom does support flashmap, then it should work. (No guarantees.) -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz Dec. 4, 2015

Dec. 4, 2015

@ John Is the work on SeaVGABIOS for CBFS work under construction for the Broadwell based Pixel 2015? Looking at Kevin's chromeimage.sh - showing relevant parts only CBFSTOOL=cbfstool PAYLOAD=out/bios.bin.elf PAYLOADVGA=out/vgabios.bin # # Build new seabios CBFS image. # CBFSFILE=seabios.cbfs $ dd if=/dev/zero of=bootblock count=1 bs=64 2> /dev/null $CBFSTOOL $CBFSFILE create -s $(( 2*1024*1024 )) -B bootblock -m x86 # # Add SeaVGABIOS to CBFS # $CBFSTOOL $CBFSFILE add-payload -f $PAYLOAD -n payload -c lzma # # Add SeaBIOS payload to CBFS # $ CBFSTOOL $CBFSFILE add -f $PAYLOADVGA -n vgaroms/seavgabios.rom -t optionrom Question - if it is work under construction, the above may or may not show any VGA output? i.e. black screen Or give it a whirl, and I may surprise myself? Or stick with ## Extract vgabios from SeaBIOS CBFS area of original image. ORIGCBFSFILE=orig-seabios.cbfs $ dd if=$ORIGIMAGE of=$ORIGCBFSFILE skip=2 bs=2M count=1 2> /dev/null $ CBFSTOOL $ORIGCBFSFILE extract -n pci8086,0406.rom -f pci8086,0406.rom $ CBFSTOOL $CBFSFILE add -f pci8086,0406.rom -n pci8086,0a06.rom -t optionrom Edward On Fri, Dec 4, 2015 at 5:50 PM, edward wandasiewicz <0.w3ntd(a)gmail.com> wrote: > Looking at the output from Googles ChromeOS shell-ball, I do: > > Write the hardware ID to get future ChromeOS updates > > $ ./gbb_utility --set --hwid="SAMUS XXX-YYY-ZZZ" bios.bin bios.hwid.bin > > # dd out 2 megs of the ROM at 4 megs in > > $ dd bs=1M skip=4 count=2 if=bios.hwid.bin of=rwlegacy.cbfs > > Using the flashrom from John's site as upstream doesn't know anything about > flashmap. > > $ wget https://johnlewis.ie/Chromebook-ROMs/utils/flashrom -O > flashrom.jlewis > > $ sudo ./flashrom.jlewis -w -i RW_LEGACY:rwlegacy.cbfs > > Looking at your script, ORIGIMAGE is my bios.hwid.bin > > Do I run flashrom from the shell-ball > > $ sudo flashrom -w ./newimage.rom -i RW_LEGACY > > Or John Lewis flashrom > > $ sudo flashrom.jlewis.version -w ./newimage.rom -i RW_LEGACY > > Edward > > On 1 Dec 2015 3:39 p.m., "Kevin O'Connor" <kevin(a)koconnor.net> wrote: >> >> On Mon, Nov 30, 2015 at 07:04:55PM +0000, edward wandasiewicz wrote: >> > On 30 Nov 2015 5:35 p.m., "Kevin O'Connor" <kevin(a)koconnor.net> wrote: >> > > Looks like two separate issues are occurring - the Philips drive is >> > > being detected as both a high speed device and as a super speed >> > > device. I need a log with CONFIG_DEBUG_LEVEL=5 to diagnose that. The >> > > second issue appears to be a USB_TRANSACTION_ERROR response from the >> > > set_address command. I think the controller may just be a bit too >> > > picky on stall responses from devices in that situation. I've put up >> > > a patch to try and work around that in the repo at: >> > > >> > > https://github.com/KevinOConnor/seabios/tree/testing >> > > >> > > Are you able to compile SeaBIOS from source and install it on your >> > > Samus? >> > >> > Compile? I could have a go, but don't want to brick my device. Happy >> > to write a RW_LEGACY from John Lewis. >> > >> > Or learn how to - bit risky for a newbie? >> >> If you've never removed the flash read/write screw (and you normally >> hit cntl-L to enter seabios) then bricking shouldn't be a problem. >> (No guarantees.) It may require a full chrome re-install to recover >> should something go wrong though. If you have removed the read/write >> screw then you should only proceed if you know what you are doing, and >> you should have the ability to restore from an external flasher. >> >> Roughly, the steps to build and flash a RW_LEGACY section is as >> follows: >> >> 1 - grab the code: >> >> git clone https://github.com/KevinOConnor/seabios.git -b testing >> >> 2 - build the code: >> >> cd seabios >> echo "CONFIG_COREBOOT=y" > .config >> echo "CONFIG_CBFS_LOCATION=0xffe00000" >> .config >> echo "CONFIG_VGA_COREBOOT=y" >> .config >> echo "CONFIG_DEBUG_LEVEL=5" >> .config >> make olddefconfig >> make >> >> 3 - build the RW_LEGACY image by copying the attached chromeimage.sh >> to the seabios directory, make it executable, and run the script: >> >> ./chromeimage.sh >> >> Be sure to follow the directions in that script for extracting the >> original image and for writing the generated image. >> >> Please review the script and make sure it makes sense before running >> anything. If you don't understand a step then you probably will want >> to hold off until someone can build a tested rom for you. >> >> Cheers, >> -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 4, 2015

Dec. 4, 2015

On Mon, Nov 30, 2015 at 07:04:55PM +0000, edward wandasiewicz wrote: > On 30 Nov 2015 5:35 p.m., "Kevin O'Connor" <kevin(a)koconnor.net> wrote: > > Looks like two separate issues are occurring - the Philips drive is > > being detected as both a high speed device and as a super speed > > device. I need a log with CONFIG_DEBUG_LEVEL=5 to diagnose that. The > > second issue appears to be a USB_TRANSACTION_ERROR response from the > > set_address command. I think the controller may just be a bit too > > picky on stall responses from devices in that situation. I've put up > > a patch to try and work around that in the repo at: > > > > https://github.com/KevinOConnor/seabios/tree/testing > > > > Are you able to compile SeaBIOS from source and install it on your > > Samus? > > Compile? I could have a go, but don't want to brick my device. Happy > to write a RW_LEGACY from John Lewis. > > Or learn how to - bit risky for a newbie? If you've never removed the flash read/write screw (and you normally hit cntl-L to enter seabios) then bricking shouldn't be a problem. (No guarantees.) It may require a full chrome re-install to recover should something go wrong though. If you have removed the read/write screw then you should only proceed if you know what you are doing, and you should have the ability to restore from an external flasher. Roughly, the steps to build and flash a RW_LEGACY section is as follows: 1 - grab the code: git clone https://github.com/KevinOConnor/seabios.git -b testing 2 - build the code: cd seabios echo "CONFIG_COREBOOT=y" > .config echo "CONFIG_CBFS_LOCATION=0xffe00000" >> .config echo "CONFIG_VGA_COREBOOT=y" >> .config echo "CONFIG_DEBUG_LEVEL=5" >> .config make olddefconfig make 3 - build the RW_LEGACY image by copying the attached chromeimage.sh to the seabios directory, make it executable, and run the script: ./chromeimage.sh Be sure to follow the directions in that script for extracting the original image and for writing the generated image. Please review the script and make sure it makes sense before running anything. If you don't understand a step then you probably will want to hold off until someone can build a tested rom for you. Cheers, -Kevin

2 1

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) Dec. 2, 2015

Dec. 2, 2015

> >>On Sat, Nov 28, 2015 at 07:12:47AM +0000, Xulei (Stone) wrote: > >>> Hi, > >>> Recently, i use a script to continuously reset a VM and > >>> i found my VM frequently halts at "Attempting to allocate > >>> VGA stack via pmm call". After analyzing, i think it may > >>> be a problem of SeaBIOS. > >>> > >>> From the log(attached below), we can see handle_post() > >>> executes twice and this makes the destination address of > >>> "Relocating init" change when the 2nd reset command comes. > >>> This also influences on the source address of "Copying MPTABLE". > >>> At last, the VM will be stuck at attempting to allocate VGA > >>> stack via pmm call. > >>> > >>> Could you offer me a solution to fix this problem? > >>> > >>> ==============bad SeaBIOS log====== > >>> SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) > >>> No Xen hypervisor found. > >>> Running on QEMU (i440fx) > >>> Running on KVM > >>> RamSize: 0xc0000000 [cmos] > >>> Now vcpu cpu_id = 0 > >>> Relocating init from 0x000dbb30 to 0xbffad2c0 (size 76928) > >>> Found QEMU fw_cfg > >>> SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) <<========= handle_post() execute again? > >> > >>If seabios resets before it sets HaveRunPost then it probably wont > >>work well, as it will rerun the POST code without resetting the global > >>variables it has modified. > >> > >>Unfortunately, it's not clear to me that we can simply move the > >>setting of HaveRunPost to an earlier point, as the handle_resume() > >>code would need to be audited to ensure it can run even if POST hasn't > >>completed. > > > >I move HaveRunPost = 1 in the very early point of POST phase (begin > >at handle_post()), so that when the 2nd reset comes, HaveRunPost is > >already 1 which makes entry_post jmps to handle_resume() instead of > >handle_post(). As we know, handle_resume() will reset all global variables. > > > >Can you tell me is this solution ok? or, does this have some side effects? > > Sorry, i've tested and this seems not work. Let HaveRunPost = 1 at begin > of handle_post(), will lead the VM to loop forever in the resume phase. > It seems the memcpy() in qemu_prep_reset()can not clear HaveRunPost at > this time. > > Ah! I'm confused! I don't know where is the right place to let HaveRunPost = 1? I move HaveRunPost = 1 to handle_post() (after make_bios_writable()), and I have tested for 1 day with continuously resetting, it seems works well! Does following patch have some side effects? f65091856d257f2c232263ac4bbc29457f356efe src/post.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/post.c b/src/post.c index 49c22b8..f381385 100644 --- a/src/post.c +++ b/src/post.c @@ -41,9 +41,7 @@ ivt_init(void) { dprintf(3, "init ivt\n"); - // Setup reset-vector entry point (controls legacy reboots). - HaveRunPost = 1; - rtc_write(CMOS_RESET_CODE, 0); // Initialize all vectors to the default handler. int i; @@ -335,6 +333,10 @@ handle_post(void) // Allow writes to modify bios area (0xf0000) make_bios_writable(); + // Setup reset-vector entry point (controls legacy reboots). + HaveRunPost = 1; + rtc_write(CMOS_RESET_CODE, 0); + // Now that memory is read/writable - start post process. dopost(); } > >>So, it looks like a fix for this will take some further analysis. > >> > >>-Kevin

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Xulei (Stone) Dec. 1, 2015

Dec. 1, 2015

> > >>On Sat, Nov 28, 2015 at 07:12:47AM +0000, Xulei (Stone) wrote: >>> Hi, >>> Recently, i use a script to continuously reset a VM and >>> i found my VM frequently halts at "Attempting to allocate >>> VGA stack via pmm call". After analyzing, i think it may >>> be a problem of SeaBIOS. >>> >>> From the log(attached below), we can see handle_post() >>> executes twice and this makes the destination address of >>> "Relocating init" change when the 2nd reset command comes. >>> This also influences on the source address of "Copying MPTABLE". >>> At last, the VM will be stuck at attempting to allocate VGA >>> stack via pmm call. >>> >>> Could you offer me a solution to fix this problem? >>> >>> ==============bad SeaBIOS log====== >>> SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) >>> No Xen hypervisor found. >>> Running on QEMU (i440fx) >>> Running on KVM >>> RamSize: 0xc0000000 [cmos] >>> Now vcpu cpu_id = 0 <<========= i add >>> Static seabios entry times =1 <<========= i add >>> Relocating init from 0x000dbb30 to 0xbffad2c0 (size 76928) >>> Found QEMU fw_cfg >>> SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) <<========= handle_post() execute again? >> >>If seabios resets before it sets HaveRunPost then it probably wont >>work well, as it will rerun the POST code without resetting the global >>variables it has modified. >> >>Unfortunately, it's not clear to me that we can simply move the >>setting of HaveRunPost to an earlier point, as the handle_resume() >>code would need to be audited to ensure it can run even if POST hasn't >>completed. > >I move HaveRunPost = 1 in the very early point of POST phase (begin >at handle_post()), so that when the 2nd reset comes, HaveRunPost is >already 1 which makes entry_post jmps to handle_resume() instead of >handle_post(). As we know, handle_resume() will reset all global variables. > >Can you tell me is this solution ok? or, does this have some side effects? Sorry, i've tested and this seems not work. Let HaveRunPost = 1 at begin of handle_post(), will lead the VM to loop forever in the resume phase. It seems the memcpy() in qemu_prep_reset()can not clear HaveRunPost at this time. Ah! I'm confused! I don't know where is the right place to let HaveRunPost = 1? >>So, it looks like a fix for this will take some further analysis. >> >>-Kevin

1 0

Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when continuously reset VM
by Kevin O'Connor Dec. 1, 2015

Dec. 1, 2015

On Sat, Nov 28, 2015 at 07:12:47AM +0000, Xulei (Stone) wrote: > Hi, > Recently, i use a script to continuously reset a VM and > i found my VM frequently halts at "Attempting to allocate > VGA stack via pmm call". After analyzing, i think it may > be a problem of SeaBIOS. > > From the log(attached below), we can see handle_post() > executes twice and this makes the destination address of > "Relocating init" change when the 2nd reset command comes. > This also influences on the source address of "Copying MPTABLE". > At last, the VM will be stuck at attempting to allocate VGA > stack via pmm call. > > Could you offer me a solution to fix this problem? > > ==============bad SeaBIOS log====== > SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) > No Xen hypervisor found. > Running on QEMU (i440fx) > Running on KVM > RamSize: 0xc0000000 [cmos] > Now vcpu cpu_id = 0 <<========= i add > Static seabios entry times =1 <<========= i add > Relocating init from 0x000dbb30 to 0xbffad2c0 (size 76928) > Found QEMU fw_cfg > SeaBIOS (version rel-1.8.1-0-g4adadbd-20151127_220019-UVP) <<========= handle_post() execute again? If seabios resets before it sets HaveRunPost then it probably wont work well, as it will rerun the POST code without resetting the global variables it has modified. Unfortunately, it's not clear to me that we can simply move the setting of HaveRunPost to an earlier point, as the handle_resume() code would need to be audited to ensure it can run even if POST hasn't completed. So, it looks like a fix for this will take some further analysis. -Kevin

2 1