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)" X-Patchwork-Id: 9264733 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 344EC60754 for ; Fri, 5 Aug 2016 02:37:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2219628333 for ; Fri, 5 Aug 2016 02:37:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 168A728425; Fri, 5 Aug 2016 02:37:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A07C828333 for ; Fri, 5 Aug 2016 02:37:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966452AbcHECg5 (ORCPT ); Thu, 4 Aug 2016 22:36:57 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:53706 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966444AbcHECgw (ORCPT ); Thu, 4 Aug 2016 22:36:52 -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" CC: "guangrong.xiao" Subject: Re: [QUESTION]stuck in SeaBIOS because of losing a SMI 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> Reply-To: "Xulei (Stone)" 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 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > > >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