From: Maxim Levitsky <mlevitsk@redhat.com>
To: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org (open list:X86 ARCHITECTURE (32-BIT
AND 64-BIT)), Wanpeng Li <wanpengli@tencent.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>, "H. Peter Anvin" <hpa@zytor.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Borislav Petkov <bp@alien8.de>,
x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)),
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Jim Mattson <jmattson@google.com>,
Sean Christopherson <seanjc@google.com>,
Maxim Levitsky <mlevitsk@redhat.com>
Subject: [PATCH 5/6] KVM: x86: never clear irr_pending in kvm_apic_update_apicv
Date: Thu, 9 Dec 2021 13:54:39 +0200 [thread overview]
Message-ID: <20211209115440.394441-6-mlevitsk@redhat.com> (raw)
In-Reply-To: <20211209115440.394441-1-mlevitsk@redhat.com>
It is possible that during the AVIC incomplete IPI vmexit,
its handler will set irr_pending to true,
but the target vCPU will still see the IRR bit not set,
due to the apparent lack of memory ordering between CPU's vIRR write
that is supposed to happen prior to the AVIC incomplete IPI
vmexit and the write of the irr_pending in that handler.
The AVIC incomplete IPI handler sets this boolean, then issues
a write barrier and then raises KVM_REQ_EVENT,
thus when we later process the KVM_REQ_EVENT we will notice
the vIRR bits set.
Also reorder call to kvm_apic_update_apicv to be after
.refresh_apicv_exec_ctrl, although that doesn't guarantee
that it will see up to date IRR bits.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
---
arch/x86/kvm/lapic.c | 3 ++-
arch/x86/kvm/x86.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index c5028e6b0f96..ecd6111b9a0d 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -2314,7 +2314,8 @@ void kvm_apic_update_apicv(struct kvm_vcpu *vcpu)
apic->irr_pending = true;
apic->isr_count = 1;
} else {
- apic->irr_pending = (apic_search_irr(apic) != -1);
+ if (apic_search_irr(apic) != -1)
+ apic->irr_pending = true;
apic->isr_count = count_vectors(apic->regs + APIC_ISR);
}
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 26cb3a4cd0e9..ca037ac2ea08 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9542,8 +9542,8 @@ void kvm_vcpu_update_apicv(struct kvm_vcpu *vcpu)
goto out;
vcpu->arch.apicv_active = activate;
- kvm_apic_update_apicv(vcpu);
static_call(kvm_x86_refresh_apicv_exec_ctrl)(vcpu);
+ kvm_apic_update_apicv(vcpu);
/*
* When APICv gets disabled, we may still have injected interrupts
--
2.26.3
next prev parent reply other threads:[~2021-12-09 11:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 11:54 [PATCH 0/6] RFC: KVM: SVM: Allow L1's AVIC to co-exist with nesting Maxim Levitsky
2021-12-09 11:54 ` [PATCH 1/6] KVM: SVM: allow to force AVIC to be enabled Maxim Levitsky
2021-12-09 11:54 ` [PATCH 2/6] KVM: x86: add a tracepoint for APICv/AVIC interrupt delivery Maxim Levitsky
2021-12-09 11:54 ` [PATCH 3/6] KVM: SVM: fix AVIC race of host->guest IPI delivery vs AVIC inhibition Maxim Levitsky
2021-12-09 14:11 ` Paolo Bonzini
2021-12-09 14:26 ` Maxim Levitsky
2021-12-09 15:27 ` Sean Christopherson
2021-12-09 15:33 ` Maxim Levitsky
2021-12-09 15:35 ` Maxim Levitsky
2021-12-09 11:54 ` [PATCH 4/6] KVM: SVM: fix races in the AVIC incomplete IPI delivery to vCPUs Maxim Levitsky
2021-12-09 15:38 ` Sean Christopherson
2021-12-10 11:37 ` Paolo Bonzini
2021-12-09 11:54 ` Maxim Levitsky [this message]
2021-12-09 14:12 ` [PATCH 5/6] KVM: x86: never clear irr_pending in kvm_apic_update_apicv Paolo Bonzini
2021-12-09 15:03 ` Maxim Levitsky
2021-12-10 12:07 ` Paolo Bonzini
2021-12-10 12:20 ` Maxim Levitsky
2021-12-10 12:47 ` Maxim Levitsky
2021-12-10 13:03 ` Paolo Bonzini
2021-12-10 13:10 ` Maxim Levitsky
2021-12-09 11:54 ` [PATCH 6/6] KVM: SVM: allow AVIC to co-exist with a nested guest running Maxim Levitsky
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=20211209115440.394441-6-mlevitsk@redhat.com \
--to=mlevitsk@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@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
all inboxes | Powered by JetHome®