From: Maxim Levitsky <mlevitsk@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org
Cc: "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@vger.kernel.org>,
Wanpeng Li <wanpengli@tencent.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>, "H. Peter Anvin" <hpa@zytor.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Borislav Petkov <bp@alien8.de>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Jim Mattson <jmattson@google.com>,
Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH 5/6] KVM: x86: never clear irr_pending in kvm_apic_update_apicv
Date: Fri, 10 Dec 2021 14:47:44 +0200 [thread overview]
Message-ID: <0a01229bbbb6d133ba164cb5495ad2300eb8d818.camel@redhat.com> (raw)
In-Reply-To: <fbf3e1665357d9517015ad49eee0c9825ed876d4.camel@redhat.com>
On Fri, 2021-12-10 at 14:20 +0200, Maxim Levitsky wrote:
> On Fri, 2021-12-10 at 13:07 +0100, Paolo Bonzini wrote:
> > On 12/9/21 12:54, Maxim Levitsky wrote:
> > > 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.
> >
> > Are you sure about this? Store-to-store ordering should be
> > guaranteed---if not by the architecture---by existing memory barriers
> > between vmrun returning and avic_incomplete_ipi_interception(). For
> > example, srcu_read_lock implies an smp_mb().
> >
> > Even more damning: no matter what internal black magic the processor
> > could be using to write to IRR, the processor needs to order the writes
> > against reads of IsRunning on processors without the erratum. That
> > would be equivalent to flushing the store buffer, and it would imply
> > that the write of vIRR is ordered before the write to irr_pending.
> >
> > Paolo
> >
> Yes I almost 100% sure now that this patch is wrong.
> the code was just seeing irr_pending true because it is set
> to true while APICv/AVIC is use, and was not seeing yet the vIRR bits,
> because they didn't arrive yet. This this patch isn't needed.
>
> Thanks again for help!
> I am testing your version of fixes to avic inhibition races,
> and then I'll send a new version of these patches.
>
> Best regards,
> Maxim Levitsky
And yet that patch is needed for a differnt reason.
If the sender has AVIC enabled, it can turn on vIRR bits at any moment
without setting irr_pending = true - there are no VMexits happeing
on the sender side.
If we scan vIRR here and see no bits, and *then* disable AVIC,
there is a window where the they could legit be turned on without any cpu errata,
and we will not have irr_pending == true, and thus the following
KVM_REQ_EVENT will make no difference.
Not touching irr_pending and letting just the KVM_REQ_EVENT do the work
will work too, and if the avic errata is present, reduce slightly
the chances of it happening.
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2021-12-10 12:48 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 ` [PATCH 5/6] KVM: x86: never clear irr_pending in kvm_apic_update_apicv Maxim Levitsky
2021-12-09 14:12 ` 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 [this message]
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=0a01229bbbb6d133ba164cb5495ad2300eb8d818.camel@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;
as well as URLs for NNTP newsgroup(s).