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 -- 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/
