From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161667AbcFAQkj (ORCPT ); Wed, 1 Jun 2016 12:40:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55316 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754877AbcFAQkd (ORCPT ); Wed, 1 Jun 2016 12:40:33 -0400 Date: Wed, 1 Jun 2016 18:40:24 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 1/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI Message-ID: <20160601164024.GF30721@potion> References: <1464784501-13710-1-git-send-email-pbonzini@redhat.com> <1464784501-13710-2-git-send-email-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1464784501-13710-2-git-send-email-pbonzini@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 01 Jun 2016 16:40:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2016-06-01 14:35+0200, Paolo Bonzini: > If the processor exits to KVM while delivering an interrupt, > the hypervisor then requeues the interrupt for the next vmentry. > Trying to enter SMM in this same window causes to enter non-root > mode in emulated SMM (i.e. with IF=0) and with a request to > inject an IRQ (i.e. with a valid VM-entry interrupt info field). > This is invalid guest state (SDM 26.3.1.4 "Check on Guest RIP > and RFLAGS") and the processor fails vmentry. > > The fix is to defer the injection from KVM_REQ_SMI to KVM_REQ_EVENT, > like we already do for e.g. NMIs. This patch doesn't change the > name of the process_smi function so that it can be applied to > stable releases. The next patch will modify the names so that > process_nmi and process_smi process respectively KVM_REQ_NMI and > KVM_REQ_SMI. > > This is especially common with Windows, probably due to the > self-IPI trick that it uses to deliver deferred procedure > calls (DPCs). > > Reported-by: Laszlo Ersek > Fixes: 64d6067057d9658acb8675afcfba549abdb7fc16 > Cc: stable@vger.kernel.org > Signed-off-by: Paolo Bonzini > --- > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > @@ -6098,7 +6094,10 @@ static int inject_pending_event(struct kvm_vcpu *vcpu, bool req_int_win) > } > > /* try to inject new event if pending */ > - if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { > + if (vcpu->arch.smi_pending && !is_smm(vcpu)) { Clearing smi_pending in kvm_vcpu_reset() would be safer now that SMI can be injected without a request or RSM. > + --vcpu->arch.smi_pending; (I'd use 'vcpu->arch.smi_pending = false', to make it clearer that we don't want multiple pending SMIs, unlike NMIs. smi_pending is bool, so the generated code should be identical.) > + process_smi(vcpu); > + } else if (vcpu->arch.nmi_pending && kvm_x86_ops->nmi_allowed(vcpu)) { > --vcpu->arch.nmi_pending; > @@ -6621,8 +6631,10 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) > > kvm_load_guest_xcr0(vcpu); > > - if (req_immediate_exit) > + if (req_immediate_exit) { > + kvm_make_request(KVM_REQ_EVENT, vcpu); > smp_send_reschedule(vcpu->cpu); (Is this a fix for non-smi cases too?) Thanks.