From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH 1/1] Disable GUEST_INTR_STATE_STI flag before injecting NMI to guest on VMX Date: Fri, 27 Aug 2010 14:04:59 +0300 Message-ID: <20100827110459.GA21909@redhat.com> References: <1282853162-16925-1-git-send-email-Jes.Sorensen@redhat.com> <1282853162-16925-2-git-send-email-Jes.Sorensen@redhat.com> <4C7776F9.4070306@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jes.Sorensen@redhat.com, kvm@vger.kernel.org, avi@redhat.com To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:15745 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753656Ab0H0LFI (ORCPT ); Fri, 27 Aug 2010 07:05:08 -0400 Content-Disposition: inline In-Reply-To: <4C7776F9.4070306@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Aug 27, 2010 at 10:27:37AM +0200, Jan Kiszka wrote: > 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]. > I re-read my mail thread with vendor and to be fair vendor said that we should clear blocked by STI before injecting NMI. It's my fault I missed it. > 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 -- Gleb.