public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: Jim Mattson <jmattson@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: nVMX: Always use TLB_FLUSH_GUEST for nested VM-Enter/VM-Exit
Date: Thu, 16 Jan 2025 16:34:58 -0800	[thread overview]
Message-ID: <Z4mlsr-xJnKxnDKc@google.com> (raw)
In-Reply-To: <CAJD7tkbqxXQVd5s7adVqzdLBP22ef2Gs+R-SxuM7GtmetaWN+Q@mail.gmail.com>

On Thu, Jan 16, 2025, Yosry Ahmed wrote:
> On Thu, Jan 16, 2025 at 2:35 PM Sean Christopherson <seanjc@google.com> wrote:
> > How about:
> >
> >          * Note, only the hardware TLB entries need to be flushed, as VPID is
> >          * fully enabled from L1's perspective, i.e. there's no architectural
> >          * TLB flush from L1's perspective.
> 
> I hate to bikeshed, but I want to explicitly call out that we do not
> need to synchronize the MMU.

Why?  Honest question, I want to understand what's unclear.  My hesitation to
talk about synchronizing MMUs is that it brings things into play that aren't
super relevant to this specific code, and might even add confusion.  Specifically,
kvm_vcpu_flush_tlb_guest() does NOT synchronize MMUs when EPT/TDP is enabled, but
the fact that this path is reachable if and only if EPT is enabled is completely
coincidental.

E.g. very hypothetically, if KVM used the same EPT root (I already forgot Intel's
new acronym) for L1 and L2, then this would no longer be true:

 * If L0 uses EPT, L1 and L2 run with different EPTP because
 * guest_mode is part of kvm_mmu_page_role. Thus, TLB entries
 * are tagged with different EPTP.

L1 vs. L2 EPT usage would no longer use separate ASID tags, and so KVM would
need to FLUSH_CURRENT on transitions in most cases, e.g. to purge APICv mappings.

The comment above !nested_cpu_has_vpid() talks at length about synchronizing MMUs
because the EPT behavior in particular is subtle and rather unintuitive.  I.e.
the comment is much more about NOT using KVM_REQ_MMU_SYNC than it is about using
KVM_REQ_TLB_FLUSH_GUEST.

> Maybe this?
> 
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 2ed454186e59c..a9171909de63d 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -1239,6 +1239,11 @@ static void
> nested_vmx_transition_tlb_flush(struct kvm_vcpu *vcpu,
>          * does not have a unique TLB tag (ASID), i.e. EPT is disabled and
>          * KVM was unable to allocate a VPID for L2, flush the current context
>          * as the effective ASID is common to both L1 and L2.
> +        *
> +        * Note, only the hardware TLB entries need to be flushed, as VPID is
> +        * fully enabled from L1's perspective, i.e. there's no
> +        * architectural TLB flush from L1's perspective. Hence, synchronizing
> +        * the MMU is not required as the mappings are still valid.
>          */
>         if (!nested_has_guest_tlb_tag(vcpu))
>                 kvm_make_request(KVM_REQ_TLB_FLUSH_GUEST, vcpu);

  reply	other threads:[~2025-01-17  0:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-16  3:50 [PATCH] KVM: nVMX: Always use TLB_FLUSH_GUEST for nested VM-Enter/VM-Exit Yosry Ahmed
2025-01-16  5:27 ` Jim Mattson
2025-01-16 15:25   ` Yosry Ahmed
2025-01-16 17:11     ` Sean Christopherson
2025-01-16 18:24       ` Yosry Ahmed
2025-01-16 22:35         ` Sean Christopherson
2025-01-16 22:43           ` Yosry Ahmed
2025-01-17  0:34             ` Sean Christopherson [this message]
2025-01-17  0:53               ` Yosry Ahmed
2025-01-17 18:01                 ` Sean Christopherson
2025-01-17 18:20                   ` Yosry Ahmed
2025-01-18  0:03                     ` Sean Christopherson
2025-01-22 19:15                       ` Yosry Ahmed

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=Z4mlsr-xJnKxnDKc@google.com \
    --to=seanjc@google.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=yosryahmed@google.com \
    /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