Re: [SeaBIOS] SeaBIOS Digest, Vol 73, Issue 11

> -----原始邮件-----
> 发件人: [e-mail]
> 发送时间: 2015年12月18日 星期五
> 收件人: [e-mail]
> 抄送: 
> 主题: SeaBIOS Digest, Vol 73, Issue 11
>
> Send SeaBIOS mailing list submissions to
>    [e-mail]
>
> 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
>    [e-mail]
>
> You can reach the person managing the list at
>    [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SeaBIOS digest..."
>
> Today's Topics:
> Re: [Qemu-devel] [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load
> if not needed (Marcel Apfelbaum)
> Re: [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load if not
> needed (Eduardo Habkost)
> Re: SeaBIOS recognising USB 3.0 on boot works - partly
> (Kevin O'Connor)
> Re: SeaBIOS Digest, Vol 72, Issue 33 (Kevin O'Connor)
> Re: Qemu-kvm VM halt at allocate VGA stack when	continuously
> reset VM (Kevin O'Connor)
> 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 
> To: Gerd Hoffmann , [e-mail]
> Cc: Eduardo Habkost , "Michael S. Tsirkin"
>    , [e-mail], Paolo Bonzini
>    , Richard Henderson 
> Subject: Re: [SeaBIOS] [Qemu-devel] [PATCH 6/6] q35: skip
>    q35-acpi-dsdt.aml load if not needed
> Message-ID: 
> 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
> >
> > 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
>
> Thanks,
> Marcel
>
> Message: 2
> Date: Thu, 17 Dec 2015 15:22:46 -0200
> From: Eduardo Habkost 
> To: Gerd Hoffmann 
> Cc: [e-mail], [e-mail], Paolo Bonzini
>    , Richard Henderson , "Michael
>    S. Tsirkin" , Igor Mammedov 
> Subject: Re: [SeaBIOS] [PATCH 6/6] q35: skip q35-acpi-dsdt.aml load if
>    not	needed
> Message-ID: 
> 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
> >
> > 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:
>
> 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.
>
> Message: 3
> Date: Thu, 17 Dec 2015 17:17:17 -0500
> From: Kevin O'Connor 
> To: edward wandasiewicz 
> Cc: [e-mail], John Lewis 
> Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works -
>    partly
> Message-ID: 
> 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 
> To: Wim Vervoorn 
> Cc: "[e-mail]" , Stefan Berger
>    
> Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
> Message-ID: 
> 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 
> To: "Xulei (Stone)" 
> Cc: "[e-mail]" 
> Subject: Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when
>    continuously reset VM
> Message-ID: 
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Dec 17, 2015 at 05:28:23AM +0000, Xulei (Stone) wrote:
> > 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).
> > SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something
> >
> > wrong printing handle_smp log.
> > 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)" 
> To: Mohammed Gamal , "Kevin O'Connor"
>    
> Cc: "[e-mail]" 
> Subject: Re: [SeaBIOS] Qemu-kvm VM halt at allocate VGA stack when
>    continuously reset VM
> Message-ID:
>
> 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)  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
> > 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).
> > SeaBIOS log tells me once VM halts at allocate VGA stack, it also has something
> >
> > wrong printing handle_smp log.
> > 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
> >    [e-mail]
> >    http://www.seabios.org/mailman/listinfo/seabios
> >
> > Mohammed Gamal
> > Software Engineer
> >
> > ProfitBricks GmbH
> > Greifswalder Stra?e 207 
> > D - 10405 Berlin
> >
> > Tel: [phone]
> > Email:       [e-mail]
> >
> > 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
> [e-mail]
> 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 :  [phone]
E-Mail       :  [e-mail]
***********************************************************************************************