From patchwork Fri Aug 5 02:32:19 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Xulei (Stone, Euler)" X-Patchwork-Id: 656016 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3s59pd1SKyz9t0j for ; Fri, 5 Aug 2016 12:33:29 +1000 (AEST) Received: from localhost ([::1]:42462 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVUww-0006Dr-Tq for incoming@patchwork.ozlabs.org; Thu, 04 Aug 2016 22:33:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVUwE-0005dP-9H for qemu-devel@nongnu.org; Thu, 04 Aug 2016 22:32:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bVUwA-0006jP-1v for qemu-devel@nongnu.org; Thu, 04 Aug 2016 22:32:41 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:38263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bVUw9-0006hb-3T for qemu-devel@nongnu.org; Thu, 04 Aug 2016 22:32:37 -0400 Received: from 172.24.1.47 (EHLO SZXEMI404-HUB.china.huawei.com) ([172.24.1.47]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id CFW99449; Fri, 05 Aug 2016 10:32:23 +0800 (CST) Received: from SZXEMI504-MBS.china.huawei.com ([169.254.1.86]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Fri, 5 Aug 2016 10:32:19 +0800 From: "Xulei (Stone)" To: Paolo Bonzini , qemu-devel , "kvm@vger.kernel.org" Thread-Topic: [QUESTION]stuck in SeaBIOS because of losing a SMI Thread-Index: AQHR7r3S8G5N5ZNDkECADUgCvOfB+A== Date: Fri, 5 Aug 2016 02:32:19 +0000 Message-ID: <8E78D212B8C25246BE4CE7EA0E645FE53F2F0F@SZXEMI504-MBS.china.huawei.com> References: <8E78D212B8C25246BE4CE7EA0E645FE53EFD8C@SZXEMI504-MBS.china.huawei.com>, <8ff19551-ef7e-6d0f-0be7-834bda97b3cf@redhat.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.254.96] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57A3FABB.0126, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.86, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 843381e06cf8bb9497fb5fbea0e6d657 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 119.145.14.66 Subject: Re: [Qemu-devel] [QUESTION]stuck in SeaBIOS because of losing a SMI X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: "Xulei \(Stone\)" Cc: "guangrong.xiao" Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" > > >On 03/08/2016 11:43, Xulei (Stone) wrote: >> Hi, all: >> Recently I use a shell script to continuously reset a vm to see what may happen. >> After one day, the vm is stuck. Looking from the following seabios log and >> kvm trace log, it seems like losing a SMI or SeaBIOS can not handle a SMI. >> This problem is reproducible on my machine (SeaBIOS 1.9.1, Qemu 2.6.0, >> Kmod 4.4.11). > >Thanks for the report! > >The more interesting part of the trace would be around the pio_write at >0xb2. Also please try kernel commit c43203cab1e, which just went into 4.8. > kernel commit c43203cab1e can not solve my problem, but seems help me to find a way to easy reproduce this problem. I add a sleep mechnism in seabios before raising an SMI interrupt so as to waiting for me to press keyboard quickly and repeatedly during the booting procedure. My vm will be stuck after several try times. >> while((1)) >> do >> virsh reset VMNAME >> sleep 1 >> done >> >> ==================kvm trace log=== >> CPU 0/KVM-13843 [020] d... 1025056.813494: kvm_entry: vcpu 0 >> CPU 0/KVM-13843 [020] .... 1025056.813495: kvm_exit: reason IO_INSTRUCTION rip 0xef10e info b30048 0 >> CPU 0/KVM-13843 [020] .... 1025056.813495: kvm_emulate_insn: 0:ef10e:e4 b3 (prot32) >> CPU 0/KVM-13843 [020] .... 1025056.813496: kvm_userspace_exit: reason KVM_EXIT_IO (2) >> CPU 0/KVM-13843 [020] .... 1025056.813496: kvm_fpu: unload >> CPU 0/KVM-13843 [020] .... 1025056.813497: kvm_pio: pio_read at 0xb3 size 1 count 1 val 0x1 >> CPU 0/KVM-13843 [020] .... 1025056.813497: kvm_fpu: load >> CPU 0/KVM-13843 [020] d... 1025056.813497: kvm_entry: vcpu 0 >> CPU 0/KVM-13843 [020] .... 1025056.813498: kvm_exit: reason IO_INSTRUCTION rip 0xef10e info b30048 0 >> CPU 0/KVM-13843 [020] .... 1025056.813498: kvm_emulate_insn: 0:ef10e:e4 b3 (prot32) >> CPU 0/KVM-13843 [020] .... 1025056.813499: kvm_userspace_exit: reason KVM_EXIT_IO (2) >> CPU 0/KVM-13843 [020] .... 1025056.813499: kvm_fpu: unload >> CPU 0/KVM-13843 [020] .... 1025056.813500: kvm_pio: pio_read at 0xb3 size 1 count 1 val 0x1 >> CPU 0/KVM-13843 [020] .... 1025056.813500: kvm_fpu: load >> >> ==================my seabios log=== >> --- a/roms/seabios/src/fw/smm.c >> +++ b/roms/seabios/src/fw/smm.c >> @@ -65,7 +65,8 @@ handle_smi(u16 cs) >> u8 cmd = inb(PORT_SMI_CMD); >> struct smm_layout *smm = MAKE_FLATPTR(cs, 0); >> u32 rev = smm->cpu.i32.smm_rev & SMM_REV_MASK; >> - dprintf(DEBUG_HDL_smi, "handle_smi cmd=%x smbase=%p\n", cmd, smm); >> + if(cmd == 0x00) { >> + dprintf(1, "handle_smi cmd=%x smbase=%p\n", cmd, smm); >> + } >> >> if (smm == (void*)BUILD_SMM_INIT_ADDR) { >> // relocate SMBASE to 0xa0000 >> @@ -147,14 +148,14 @@ smm_relocate_and_restore(void) >> { >> /* init APM status port */ >> outb(0x01, PORT_SMI_STATUS); >> + dprintf(1,"before SMI====\n"); >> >> /* raise an SMI interrupt */ >> outb(0x00, PORT_SMI_CMD); >> + dprintf(1,"after SMI=====\n"); >> >> /* wait until SMM code executed */ >> while (inb(PORT_SMI_STATUS) != 0x00) >> ; >> + dprintf(1,"smm code executes complete====\n"); >> >> And the log output like this: >> 2016-08-03 16:23:15PCI: Using 00:02.0 for primary VGA >> 2016-08-03 16:23:15smm_device_setup start >> 2016-08-03 16:23:15init smm >> 2016-08-03 16:23:15before SMI==== >> 2016-08-03 16:23:15after SMI===== <----always stuck here, unless i destroy it >> >> As above, it is obviously that if bios doesn't handle_smi, PORT_SMI_STATUS is >> always 0x01. smm_relocate_and_restore() will always in the while loop. >> >> Why does bios handle_smi at this point, is this a kvm bug? or SeaBIOS bug? >> >> -------------- >> Xulei (Stone) >> diff --git a/roms/seabios/src/fw/smm.c b/roms/seabios/src/fw/smm.c --- a/roms/seabios/src/fw/smm.c +++ b/roms/seabios/src/fw/smm.c @@ -145,16 +146,26 @@ smm_save_and_copy(void) static void smm_relocate_and_restore(void) { + long long i = 0; + long long j =100000; /* init APM status port */ outb(0x01, PORT_SMI_STATUS); +while(i++ < 1000000000) +{ + if((i-j) == 0) + {dprintf(1, "."); + j +=100000; + } +} /* raise an SMI interrupt */ outb(0x00, PORT_SMI_CMD); /* wait until SMM code executed */ while (inb(PORT_SMI_STATUS) != 0x00); It seems kvm has something wrong in injecting SMI with common IRQ. >Paolo > >> ==================my shell script=== >> #!/bin/bash