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
