On Wed, Apr 11, 2012 at 7:45 AM, Avi Kivity <avi@xxxxxxxxxx> wrote: > On 04/11/2012 05:11 AM, Peijie Yu wrote: >> For this problem, i found that panic is caused by >> BUG_ON(in_nmi()) which means NMI happened during another NMI Context; >> But i check the Intel Technical Manual and found "While an NMI >> interrupt handler is executing, the processor disables additional >> calls to the NMI handler until the next IRET instruction is executed." >> So, how this happen? >> > > The NMI path for kvm is different; the processor exits from the guest > with NMIs blocked, then executes kvm code until it issues "int $2" in > vmx_complete_interrupts(). If an IRET is executed in this path, then > NMIs will be unblocked and nested NMIs may occur. > > One way this can happen is if we access the vmap area and incur a fault, > between the VMEXIT and invoking the NMI handler. Or perhaps the NMI > handler itself generates a fault. Or we have a debug exception in that path. > > Is this reproducible? As an FYI, there have been BIOSes whose SMI handlers ran IRETs. So the NMI blocking can go away surprisingly. See 29.8 "NMI handling while in SMM" in the Intel SDM vol 3. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
