From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
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
Date: Wed, 1 Jun 2016 18:40:24 +0200 [thread overview]
Message-ID: <20160601164024.GF30721@potion> (raw)
In-Reply-To: <1464784501-13710-2-git-send-email-pbonzini@redhat.com>
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 <lersek@redhat.com>
> Fixes: 64d6067057d9658acb8675afcfba549abdb7fc16
> Cc: stable@vger.kernel.org
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> 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.
next prev parent reply other threads:[~2016-06-01 16:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 12:34 [PATCH 0/2] KVM: x86: avoid simultaneous queueing of both IRQ and SMI Paolo Bonzini
2016-06-01 12:35 ` [PATCH 1/2] " Paolo Bonzini
2016-06-01 16:40 ` Radim Krčmář [this message]
2016-06-01 18:06 ` Paolo Bonzini
2016-06-05 3:28 ` Wanpeng Li
2016-06-06 8:10 ` Paolo Bonzini
2016-06-06 8:25 ` Wanpeng Li
2016-06-01 12:35 ` [PATCH 2/2] KVM: x86: rename process_smi to enter_smm, process_smi_request to process_smi Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160601164024.GF30721@potion \
--to=rkrcmar@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).