From: Sean Christopherson <seanjc@google.com>
To: Lai Jiangshan <laijs@linux.alibaba.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
linux-kernel@vger.kernel.org,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Maxim Levitsky <mlevitsk@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: X86: fix tlb_flush_guest()
Date: Wed, 2 Jun 2021 22:07:38 +0000 [thread overview]
Message-ID: <YLgBKh43SRvjKeB1@google.com> (raw)
In-Reply-To: <YLefHNgePAs+lPQJ@google.com>
On Wed, Jun 02, 2021, Sean Christopherson wrote:
> On Fri, May 28, 2021, Lai Jiangshan wrote:
> >
> >
> > On 2021/5/28 03:28, Sean Christopherson wrote:
> > > On Thu, May 27, 2021, Sean Christopherson wrote:
> > > > > KVM_REQ_MMU_RELOAD is overkill, nuking the shadow page tables will completely
> > > > > offset the performance gains of the paravirtualized flush.
> > >
> > > Argh, I take that back. The PV KVM_VCPU_FLUSH_TLB flag doesn't distinguish
> > > between flushing a specific mm and flushing the entire TLB. The HyperV usage
> > > (via KVM_REQ) also throws everything into a single bucket. A full RELOAD still
> > > isn't necessary as KVM just needs to sync all roots, not blast them away. For
> > > previous roots, KVM doesn't have a mechanism to defer the sync, so the immediate
> > > fix will need to unload those roots.
> > >
> > > And looking at KVM's other flows, __kvm_mmu_new_pgd() and kvm_set_cr3() are also
> > > broken with respect to previous roots. E.g. if the guest does a MOV CR3 that
> > > flushes the entire TLB, followed by a MOV CR3 with PCID_NOFLUSH=1, KVM will fail
> > > to sync the MMU on the second flush even though the guest can technically rely
> > > on the first MOV CR3 to have synchronized any previous changes relative to the
> > > fisrt MOV CR3.
> >
> > Could you elaborate the problem please?
> > When can a MOV CR3 that needs to flush the entire TLB if PCID is enabled?
>
> Scratch that, I was wrong. The SDM explicitly states that other PCIDs don't
> need to be flushed if CR4.PCIDE=1.
*sigh*
I was partially right. If the guest does
1: MOV B, %rax
MOV %rax, %cr3
2: <modify PTEs in B>
3: MOV A, %rax
MOV %rax, %cr3
4: MOV B, %rax
BTS $63, %rax
MOV %rax, %cr3
where A and B are CR3 values with the same PCID, then KVM will fail to sync B at
step (4) due to PCID_NOFLUSH, even though the guest can technically rely on
its modifications at step (2) to become visible at step (3) when the PCID is
flushed on CR3 load.
So it's not a full TLB flush, rather a flush of the PCID, which can theoretically
impact previous CR3 values.
next prev parent reply other threads:[~2021-06-02 22:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-27 2:39 [PATCH] KVM: X86: fix tlb_flush_guest() Lai Jiangshan
2021-05-27 12:55 ` Paolo Bonzini
2021-05-27 16:13 ` Sean Christopherson
2021-05-27 16:14 ` Sean Christopherson
2021-05-27 19:28 ` Sean Christopherson
2021-05-28 1:13 ` Lai Jiangshan
2021-06-02 15:09 ` Sean Christopherson
2021-06-02 22:07 ` Sean Christopherson [this message]
2021-05-28 0:18 ` Lai Jiangshan
2021-05-28 0:26 ` Sean Christopherson
2021-05-28 1:29 ` Lai Jiangshan
2021-06-02 15:01 ` Sean Christopherson
2021-06-02 8:13 ` Lai Jiangshan
2021-05-29 22:12 ` Maxim Levitsky
2021-05-31 17:22 ` [PATCH V2] " Lai Jiangshan
2021-06-02 15:39 ` Sean Christopherson
2021-06-07 22:38 ` Maxim Levitsky
2021-06-08 0:03 ` Sean Christopherson
2021-06-08 14:01 ` Lai Jiangshan
2021-06-08 17:36 ` Paolo Bonzini
2021-06-08 21:31 ` 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=YLgBKh43SRvjKeB1@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jiangshanlai@gmail.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=laijs@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.