Gleb Natapov wrote: > On Mon, Sep 22, 2008 at 09:59:07AM +0200, Jan Kiszka wrote: >> @@ -2356,6 +2384,19 @@ static void vmx_inject_nmi(struct kvm_vc >> { >> struct vcpu_vmx *vmx = to_vmx(vcpu); >> >> + if (!cpu_has_virtual_nmis()) { >> + /* >> + * Tracking the NMI-blocked state in software is built upon >> + * finding the next open IRQ window. This, in turn, depends on >> + * well-behaving guests: They have to keep IRQs disabled at >> + * least as long as the NMI handler runs. Otherwise we may >> + * cause NMI nesting, maybe breaking the guest. But as this is >> + * highly unlikely, we can live with the residual risk. >> + */ >> + vmx->soft_vnmi_blocked = 1; >> + vmx->vnmi_blocked_time = 0; >> + } >> + > We still get here with vmx->soft_vnmi_blocked = 1. Trying to find out > how.
We should only come along here with vnmi blocked on reinjection (after a fault on calling the handler). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html