Re: [PATCH 10/11] VMX: work around lacking VNMI support

[Jan Kiszka <jan.kiszka@siemens.com>]

Gleb Natapov wrote:
> On Tue, Sep 23, 2008 at 10:46:38AM +0200, Jan Kiszka wrote:
>> 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).
>>
> I see that nmi_injected is never cleared and it is check before calling
> vmx_inject_nmi();

That should happen in vmx_complete_interrupts, but only if the exit
takes place after the NMI has been successfully delivered to the guest
(which is not the case if invoking the handler raises an exception). So
far for the theory...

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux