From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) Date: Fri, 14 Sep 2012 13:57:06 +0800 Message-ID: <5052C732.7060508@linux.vnet.ibm.com> References: <20120912044037.GA23094@localhost> <505044AC.80205@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Fengguang Wu , "kvm@vger.kernel.org" , LKML To: Avi Kivity Return-path: Received: from e23smtp04.au.ibm.com ([202.81.31.146]:34137 "EHLO e23smtp04.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753786Ab2INF5P (ORCPT ); Fri, 14 Sep 2012 01:57:15 -0400 Received: from /spool/local by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 14 Sep 2012 15:54:47 +1000 In-Reply-To: <505044AC.80205@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 09/12/2012 04:15 PM, Avi Kivity wrote: > On 09/12/2012 07:40 AM, Fengguang Wu wrote: >> Hi, >> >> 3 of my test boxes running v3.5 kernel become unaccessible and I find >> two of them kept emitting this dmesg: >> >> vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) and exit reason is 0x31 >> >> The other one has froze and the above lines are the last dmesg. >> Any ideas? > > First, that printk should be rate-limited. > > Second, we should add EXIT_REASON_EPT_MISCONFIG (0x31) to > > if ((vectoring_info & VECTORING_INFO_VALID_MASK) && > (exit_reason != EXIT_REASON_EXCEPTION_NMI && > exit_reason != EXIT_REASON_EPT_VIOLATION && > exit_reason != EXIT_REASON_TASK_SWITCH)) > printk(KERN_WARNING "%s: unexpected, valid vectoring info " > "(0x%x) and exit reason is 0x%x\n", > __func__, vectoring_info, exit_reason); > > since it's easily caused by the guest. Yes, i will do these. > > Third, it's really unexpected. It seems the guest was attempting to deliver a page fault exception (0x0e) but encountered an mmio page during delivery (in the IDT, TSS, stack, or page tables). Is this reproducible? If so it's easy to patch kvm to halt in that case and allow examining the guest via qemu. > Have no idea yet why the box was frozen under this case, will try to write a test case, hope it can help me to find the reason out. > Maybe we should do so regardless (return a KVM_EXIT_INTERNAL_ERROR). I think this is reasonable. Thanks!