From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 10/11] VMX: work around lacking VNMI support Date: Tue, 23 Sep 2008 12:00:21 +0300 Message-ID: <20080923090021.GB3072@minantech.com> References: <48D74CE6.5060008@siemens.com> <48D7504B.7050102@siemens.com> <20080922141511.GA25282@minantech.com> <48D8ACEE.9000905@siemens.com> <20080923085043.GA3072@minantech.com> <48D8AF84.3020707@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm-devel , "Yang, Sheng" , Avi Kivity To: Jan Kiszka Return-path: Received: from il.qumranet.com ([212.179.150.194]:33115 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750869AbYIWJAX (ORCPT ); Tue, 23 Sep 2008 05:00:23 -0400 Content-Disposition: inline In-Reply-To: <48D8AF84.3020707@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Sep 23, 2008 at 10:57:40AM +0200, Jan Kiszka wrote: > 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... > Okey, I have this one in dmesg: kvm_handle_exit: unexpected, valid vectoring info and exit reason is 0x9 -- Gleb.