* [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) @ 2012-09-12 4:40 Fengguang Wu 2012-09-12 8:15 ` Avi Kivity 0 siblings, 1 reply; 8+ messages in thread From: Fengguang Wu @ 2012-09-12 4:40 UTC (permalink / raw) To: kvm@vger.kernel.org; +Cc: LKML 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? Thanks, Fengguang ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) 2012-09-12 4:40 [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) Fengguang Wu @ 2012-09-12 8:15 ` Avi Kivity 2012-09-12 8:25 ` Fengguang Wu 2012-09-14 5:57 ` Xiao Guangrong 0 siblings, 2 replies; 8+ messages in thread From: Avi Kivity @ 2012-09-12 8:15 UTC (permalink / raw) To: Fengguang Wu; +Cc: kvm@vger.kernel.org, LKML, Xiao Guangrong 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. 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. Maybe we should do so regardless (return a KVM_EXIT_INTERNAL_ERROR). -- error compiling committee.c: too many arguments to function ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) 2012-09-12 8:15 ` Avi Kivity @ 2012-09-12 8:25 ` Fengguang Wu 2012-09-14 5:57 ` Xiao Guangrong 1 sibling, 0 replies; 8+ messages in thread From: Fengguang Wu @ 2012-09-12 8:25 UTC (permalink / raw) To: Avi Kivity; +Cc: kvm@vger.kernel.org, LKML, Xiao Guangrong On Wed, Sep 12, 2012 at 11:15:40AM +0300, 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. > > 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. It's the first time I see such errors. For now I've upgraded the host kernel to 3.6-rc5. Let's check whether it will happen again. > Maybe we should do so regardless (return a KVM_EXIT_INTERNAL_ERROR). I can test your changes either way. Thanks, Fengguang ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) 2012-09-12 8:15 ` Avi Kivity 2012-09-12 8:25 ` Fengguang Wu @ 2012-09-14 5:57 ` Xiao Guangrong 2012-10-17 6:26 ` Xiao Guangrong 1 sibling, 1 reply; 8+ messages in thread From: Xiao Guangrong @ 2012-09-14 5:57 UTC (permalink / raw) To: Avi Kivity; +Cc: Fengguang Wu, kvm@vger.kernel.org, LKML 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! ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) 2012-09-14 5:57 ` Xiao Guangrong @ 2012-10-17 6:26 ` Xiao Guangrong 2012-10-17 6:43 ` Fengguang Wu 0 siblings, 1 reply; 8+ messages in thread From: Xiao Guangrong @ 2012-10-17 6:26 UTC (permalink / raw) To: Xiao Guangrong; +Cc: Avi Kivity, Fengguang Wu, kvm@vger.kernel.org, LKML On 09/14/2012 01:57 PM, Xiao Guangrong wrote: > 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. > Still did not know why linux kernel triggered it. I have posted a patchset to report an internal error for this case, hoping Fengguang can reproduce it after the patchset and Qemu's dump can help us to find the reason out. I will keep working on it. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) 2012-10-17 6:26 ` Xiao Guangrong @ 2012-10-17 6:43 ` Fengguang Wu 2012-10-17 7:04 ` Xiao Guangrong 0 siblings, 1 reply; 8+ messages in thread From: Fengguang Wu @ 2012-10-17 6:43 UTC (permalink / raw) To: Xiao Guangrong; +Cc: Avi Kivity, kvm@vger.kernel.org, LKML On Wed, Oct 17, 2012 at 02:26:22PM +0800, Xiao Guangrong wrote: > On 09/14/2012 01:57 PM, Xiao Guangrong wrote: > > 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. > > > > Still did not know why linux kernel triggered it. I have posted > a patchset to report an internal error for this case, hoping > Fengguang can reproduce it after the patchset and Qemu's dump > can help us to find the reason out. > > I will keep working on it. Thanks! Shall I run some patched kernel, or just 3.6.0? Another problem I sometimes run into is, dmesg no longer works in the test boxes that run lots of KVMs. It aborts with an error message: dmesg: klogctl failed: Bad address Thanks, Fengguang ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) 2012-10-17 6:43 ` Fengguang Wu @ 2012-10-17 7:04 ` Xiao Guangrong 2012-10-17 9:15 ` Fengguang Wu 0 siblings, 1 reply; 8+ messages in thread From: Xiao Guangrong @ 2012-10-17 7:04 UTC (permalink / raw) To: Fengguang Wu; +Cc: Avi Kivity, kvm@vger.kernel.org, LKML On 10/17/2012 02:43 PM, Fengguang Wu wrote: > On Wed, Oct 17, 2012 at 02:26:22PM +0800, Xiao Guangrong wrote: >> On 09/14/2012 01:57 PM, Xiao Guangrong wrote: >>> 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. >>> >> >> Still did not know why linux kernel triggered it. I have posted >> a patchset to report an internal error for this case, hoping >> Fengguang can reproduce it after the patchset and Qemu's dump >> can help us to find the reason out. >> >> I will keep working on it. > > Thanks! Shall I run some patched kernel, or just 3.6.0? The patchset is under review. Can be found at: https://lkml.org/lkml/2012/10/17/31 > > Another problem I sometimes run into is, dmesg no longer works in the > test boxes that run lots of KVMs. It aborts with an error message: > > dmesg: klogctl failed: Bad address Interesting, will fight for it. :) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) 2012-10-17 7:04 ` Xiao Guangrong @ 2012-10-17 9:15 ` Fengguang Wu 0 siblings, 0 replies; 8+ messages in thread From: Fengguang Wu @ 2012-10-17 9:15 UTC (permalink / raw) To: Xiao Guangrong; +Cc: Avi Kivity, kvm@vger.kernel.org, LKML On Wed, Oct 17, 2012 at 03:04:49PM +0800, Xiao Guangrong wrote: > On 10/17/2012 02:43 PM, Fengguang Wu wrote: > > On Wed, Oct 17, 2012 at 02:26:22PM +0800, Xiao Guangrong wrote: > >> On 09/14/2012 01:57 PM, Xiao Guangrong wrote: > >>> 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. > >>> > >> > >> Still did not know why linux kernel triggered it. I have posted > >> a patchset to report an internal error for this case, hoping > >> Fengguang can reproduce it after the patchset and Qemu's dump > >> can help us to find the reason out. > >> > >> I will keep working on it. > > > > Thanks! Shall I run some patched kernel, or just 3.6.0? > > The patchset is under review. Can be found at: > https://lkml.org/lkml/2012/10/17/31 Thanks, I'll try it. Thanks, Fengguang ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-10-17 9:15 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-12 4:40 [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e) Fengguang Wu 2012-09-12 8:15 ` Avi Kivity 2012-09-12 8:25 ` Fengguang Wu 2012-09-14 5:57 ` Xiao Guangrong 2012-10-17 6:26 ` Xiao Guangrong 2012-10-17 6:43 ` Fengguang Wu 2012-10-17 7:04 ` Xiao Guangrong 2012-10-17 9:15 ` Fengguang Wu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).