On Fri, Aug 27, 2010 at 10:27:37AM +0200, Jan Kiszka wrote: > Am 26.08.2010 22:06, [email protected] wrote: > > From: Jes Sorensen <[email protected]> > > > > 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 <[email protected]> > > Signed-off-by: Gleb Natapov <[email protected]> > > --- > > 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
