From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 10/11] VMX: work around lacking VNMI support Date: Wed, 24 Sep 2008 15:08:04 +0200 Message-ID: <48DA3BB4.80708@siemens.com> References: <48D74CE6.5060008@siemens.com> <200809231742.03316.sheng.yang@intel.com> <20080923094544.GE3072@minantech.com> <200809231750.49882.sheng.yang@intel.com> <48DA3532.9040306@siemens.com> <20080924125057.GF3072@minantech.com> <48DA3908.2000204@siemens.com> <20080924130236.GG3072@minantech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Yang, Sheng" , kvm-devel , Avi Kivity To: Gleb Natapov Return-path: Received: from lizzard.sbs.de ([194.138.37.39]:20198 "EHLO lizzard.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751239AbYIXNIX (ORCPT ); Wed, 24 Sep 2008 09:08:23 -0400 In-Reply-To: <20080924130236.GG3072@minantech.com> Sender: kvm-owner@vger.kernel.org List-ID: Gleb Natapov wrote: > On Wed, Sep 24, 2008 at 02:56:40PM +0200, Jan Kiszka wrote: >>> We should do something like this: >>> >>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >>> index 046a91b..860e66d 100644 >>> --- a/arch/x86/kvm/vmx.c >>> +++ b/arch/x86/kvm/vmx.c >>> @@ -2826,10 +2826,20 @@ static int handle_task_switch(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) >>> unsigned long exit_qualification; >>> u16 tss_selector; >>> int reason; >>> + struct vcpu_vmx *vmx = to_vmx(vcpu); >>> >>> exit_qualification = vmcs_readl(EXIT_QUALIFICATION); >>> >>> reason = (u32)exit_qualification >> 30; >>> + >>> + if (reason == TASK_SWITCH_GATE && vmx->vcpu.arch.nmi_injected && >>> + (vmx->idt_vectoring_info & VECTORING_INFO_VALID_MASK) && >>> + (vmx->idt_vectoring_info & VECTORING_INFO_TYPE_MASK) == INTR_TYPE_NMI_INTR) { >>> + vcpu->arch.nmi_injected = false; >>> + vmcs_set_bits(GUEST_INTERRUPTIBILITY_INFO, >>> + GUEST_INTR_STATE_NMI); >>> + printk(KERN_DEBUG"NMI cause task switch. No need to reinject\n"); >>> + } >> OK, I just think we are not supposed to set GUEST_INTR_STATE_NMI without >> cpu_has_virtual_nmis(). Otherwise looks reasonable. Have you tested >> this? Does it make your 2003 power-off? >> > It does power-off, but hands during reboot. Looking at it right now. After completing the RAM read-back from disk? This is where it hangs here. I also briefly played with an XP image, and that one even hard-rebooted at that point. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux