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]. 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 -- 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
