From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C44672AD22 for ; Fri, 17 Jan 2025 00:35:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737074102; cv=none; b=BnbQsRn0KGNN0rGka43mlRqogKJpVfKiUiOYxGutsWOD0yTBriNmPwTkl9uUHIU3ALQ6oNxgOX5cr42ibCsj7sHYY3LCQQdei1zNlxMFh7YidvMl6/iYS2L7rvG4V0ddjzw6RnUFHkf/t6Ao7Vm08zcQuUYqEgegrAld6Jw/MVw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737074102; c=relaxed/simple; bh=i+fu4SMiKCiOhqIwNOT0ZXodrO03sEGDTT6rZTLdP3M=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=H3FcsOAnrVrYRNTUlIug2xOoMu/Ch4kaKqC6z7WaaLY9Vqky1uc43C2yF1pR7DUIE3Qb3SYpy7li/k7YT/pxJMciYtGQ8GZkOgx5luUcnEPFkKmJ7RB8vk7UMyquejQ5SBmR48kuILCtf/Ass0ZWGUGd+hyeb00Ruuw1FejZsWs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=dRrQrdMk; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dRrQrdMk" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2f550d28f7dso3038634a91.3 for ; Thu, 16 Jan 2025 16:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737074100; x=1737678900; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=lgWPk9r1v2SNvtYRPaNPBYejiII89EyX0Cotmneutyo=; b=dRrQrdMkmebMg7sW8rHLNa1Lgm39z9nAI/dou0f/FBttbU70QKYXZlB/hYQbL57Va4 UoqRkB2Bje9JUuWhOyhHZ8vRqymKZQO+ttcHfqc64rzonOd48Pif6JtFjglhAlPDb7cY cCrbuYdFcIbohJerPBVHV6L8eWmFqaSKn6EvvaxaopziqCvAJZMx7YOCCWqHKLqyT1lx z098Ea3hxU1nQb2M9i9XCbxc8v2qPxz905OuNsXuq68E8Jzh0hs9/rK5Pn7lgIBKQBCr tW8uP2NsXPIGBGeBDxo2zP/ai3iJjvpiDfwkkFlz9aLSdngoaP/VFE/kra35ewbz+DQN zncg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737074100; x=1737678900; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=lgWPk9r1v2SNvtYRPaNPBYejiII89EyX0Cotmneutyo=; b=Cw3qK7fl5im8nOWs5oX08rrU80Dp/hUR0Cb51HNc8W5wFpbAaBBS8AjWEqBBhgvKWS g7rzLoWBuh9id7jqPDP0B5CQNqvf1DdJjhDBU43eZxIW5S6YwPCLOu5cCXdd9MYFWF5n dwyT0uC+j4yICzdkbJ3sPRoL6OD8icafJC96CHewVeJv214G+yvBzI8toMwcwhba4y11 MYc8TSJ+27yxqRRRWqT5BNa3JsMmbkp1qXaSbxkSfe7Ye6Pkr1YVE1ygdN/WqEK4Mbsv Ayv3Ys4q+Y55euCHa4Nz/jc0QteGHDZrGHrkghfmvYik7Bd6PM1v2Y1gVjvHKUMRoiLE HEMA== X-Forwarded-Encrypted: i=1; AJvYcCXDzLI7LP8tLQ7a0HLRXulAFKPNJM56q0V49GGtSrbAJrQ4SJK2J1B0i4IGH0EYAPM6mFCW/33cfr3zLJA=@vger.kernel.org X-Gm-Message-State: AOJu0YwuQsLe+4pI7Ku5puY28NHQvw8A61z2Xvtgwn+5JL2mdCwMjWBz kY4rlvUJ26o0wC10/GLN/482a/MfbZJm357JAzaagQFgOtTAJL/M6F34CEDF7R+aBbwtgYwVOR+ bOw== X-Google-Smtp-Source: AGHT+IEF+vCsdB8XWnCOfXc26I8zlnaA9viptBGh60aDQoi6XWzvvwmTgjaaVDKjMyjL3uFjKiqnMv4ZWGQ= X-Received: from pjbsd7.prod.google.com ([2002:a17:90b:5147:b0:2ef:8d43:14d8]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:8a16:b0:2ee:ead6:6213 with SMTP id 98e67ed59e1d1-2f782ca2bc0mr801570a91.19.1737074100179; Thu, 16 Jan 2025 16:35:00 -0800 (PST) Date: Thu, 16 Jan 2025 16:34:58 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20250116035008.43404-1-yosryahmed@google.com> Message-ID: Subject: Re: [PATCH] KVM: nVMX: Always use TLB_FLUSH_GUEST for nested VM-Enter/VM-Exit From: Sean Christopherson To: Yosry Ahmed Cc: Jim Mattson , Paolo Bonzini , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 16, 2025, Yosry Ahmed wrote: > On Thu, Jan 16, 2025 at 2:35=E2=80=AFPM Sean Christopherson wrote: > > How about: > > > > * Note, only the hardware TLB entries need to be flushed, as V= PID is > > * fully enabled from L1's perspective, i.e. there's no archite= ctural > > * TLB flush from L1's perspective. >=20 > 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. Specif= ically, kvm_vcpu_flush_tlb_guest() does NOT synchronize MMUs when EPT/TDP is enable= d, but the fact that this path is reachable if and only if EPT is enabled is compl= etely coincidental. E.g. very hypothetically, if KVM used the same EPT root (I already forgot I= ntel'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 woul= d need to FLUSH_CURRENT on transitions in most cases, e.g. to purge APICv map= pings. The comment above !nested_cpu_has_vpid() talks at length about synchronizin= g 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? >=20 > 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 an= d > * KVM was unable to allocate a VPID for L2, flush the current co= ntext > * as the effective ASID is common to both L1 and L2. > + * > + * Note, only the hardware TLB entries need to be flushed, as VPI= D is > + * fully enabled from L1's perspective, i.e. there's no > + * architectural TLB flush from L1's perspective. Hence, synchron= izing > + * 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);