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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
