From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 1/1] Disable GUEST_INTR_STATE_STI flag before injecting NMI to guest on VMX Date: Fri, 27 Aug 2010 10:27:37 +0200 Message-ID: <4C7776F9.4070306@siemens.com> References: <1282853162-16925-1-git-send-email-Jes.Sorensen@redhat.com> <1282853162-16925-2-git-send-email-Jes.Sorensen@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, avi@redhat.com, gleb@redhat.com To: Jes.Sorensen@redhat.com Return-path: Received: from david.siemens.de ([192.35.17.14]:24665 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752007Ab0H0I1u (ORCPT ); Fri, 27 Aug 2010 04:27:50 -0400 In-Reply-To: <1282853162-16925-2-git-send-email-Jes.Sorensen@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Am 26.08.2010 22:06, Jes.Sorensen@redhat.com wrote: > From: Jes Sorensen > > Injecting an NMI while GUEST_INTR_STATE_STI is set may fail, > which can cause an EXIT with invalid state, resulting in the > guest dieing. Very interesting. Reality obviously doesn't bother about the statement of the vendor [1]. Just curious: is this limited to specific CPU models or actually a generic issue? > > Credit to Gleb for figuring out why it was failing and how to > fix it. > > Signed-off-by: Jes Sorensen > Signed-off-by: Gleb Natapov > --- > arch/x86/kvm/vmx.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > index cf56462..8e95371 100644 > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -2888,6 +2888,8 @@ static void vmx_inject_nmi(struct kvm_vcpu *vcpu) > kvm_rip_write(vcpu, vmx->rmode.irq.rip - 1); > return; > } > + vmcs_write32(GUEST_INTERRUPTIBILITY_INFO, > + vmcs_read32(GUEST_INTERRUPTIBILITY_INFO) & ~GUEST_INTR_STATE_STI); > vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, > INTR_TYPE_NMI_INTR | INTR_INFO_VALID_MASK | NMI_VECTOR); > } Thinking about the implications: Independent of virtualization, this means that no code code can in any way rely on the STI shadow if there are NMIs present that could "consume" it. Because after return from those NMIs, interrupts could then be injected on the instruction that was originally under the shadow. Jan [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/52144 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux