From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f74.google.com (mail-pj1-f74.google.com [209.85.216.74]) (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 F163B1A0BD7 for ; Fri, 17 Jan 2025 18:01:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737136912; cv=none; b=jD8rNybNyq9aQwSQw9Dv1laecCM6FK+ROZTBwHUcVATHBJF8Ra4Tm/xURIQTkcHhCjrh/HgaB8CgWjYPpGWuAlle6uMUb/QSYw4ixRtLi+6tWSFG3DxC7fjVyY7ZCManxPvVs9ER/NWOroboF/JZqbY0tRnbo408xhZd6ukLjQw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737136912; c=relaxed/simple; bh=IYzFko9KIlsqtQTTgIf9aNVZ3kO3ee2tnOcsKs1ABsQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=cWqVKo7ga+07/6TwxTQrzn9ALQU3G5Xn+paPN+wDnJ7lpuHfjG6vdhsi8N6/sh8H9vH0lXRontOw6dCMUdkUAMEzQMvP6ZDejNSyoU49yKHg04j529TkZhlFWwWAC7AGD3I2PaHZzJE3QheS7bcKJQwNRTyF1235FTnMtjJZH0A= 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=Qk2by4jg; arc=none smtp.client-ip=209.85.216.74 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="Qk2by4jg" Received: by mail-pj1-f74.google.com with SMTP id 98e67ed59e1d1-2f5538a2356so4555727a91.2 for ; Fri, 17 Jan 2025 10:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737136910; x=1737741710; 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=2ZlDFLge8M0GjaKcSPR/oviwgRjviZuJ0u+CiB45rmM=; b=Qk2by4jg1NO+bTWtfrozO8BiWXPwcQnNjCe4TIExO6e1aOwg2wooDz2AmWfL2egV9m kf391CgWkJpPRfF7ZkVQ8eSBukJnxg+XcYbydEjm8KqAbAGt5PU8asP/6+hX7N9zWI0M XXEOHbk7Serq3E4DL/VCsrl3+/Pj/x/hYGyaX8Wb0sseTP3IgYS+j7NKCETe1+MDme9a HRSCe1RdvggKimLtSN8pUEUDVRpUchrqXdIj7TipG6Vakx4P1svjPE4gAz0p6CBSFoQg 1Qfu8tFuzefMKuRghuKVbEZhQ49DX/CMohr8B4lGYNyd/grZcXo73EPQzROwYdXY8P4g Oi4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737136910; x=1737741710; 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=2ZlDFLge8M0GjaKcSPR/oviwgRjviZuJ0u+CiB45rmM=; b=fqN1Wk4sWvkcxrV95Un8/TB+pNiSTC7T1FJEddfpd1VvTDtm3kYP6V6X8De89c8Slj An1OZGN1Y1K9Or4EwEwhlWpURs3kAaRtxSozwAcz7YBHB/mJgeeu8EOLBO3sG9I2s5je da/hbsVK7fJRjNbUfM0VYosDjeHuibKw0pZEJbtv8kXuFTkY52YX6p/hpw3wx6636ebN 7lija1CrmQSV1pWZXnnk2snAU6iq+nHMGvvFRr8ycfxjy8sYcIIlrsRmoNqtaGGvWZKu aQZHyhyfwaLTc6SXG0PSYCjXDxaEZUFq27sJPwHQQREAboNBnsrEKr21YV2bANsrAEf3 KlSQ== X-Forwarded-Encrypted: i=1; AJvYcCV0pOPNx6bR3R8fnP9IgXxmcJIF/nZh9ykTBU64fU8dPMJumu6VmfWDXKDifkqrSk7ODtMHcIBr0MR8ab4=@vger.kernel.org X-Gm-Message-State: AOJu0YzyWBqcMGYmIaOY20tCjZHC8G9HIzSL0cqwlwS+RZOtSbLkabHu mUPNDmf6/Vtrp5Rqpib6wuwAnHQQdSNv0VDqccqWw6OOeAYxRTYR/ma59llcHPNWaW9mAv6dgyg aQA== X-Google-Smtp-Source: AGHT+IH3kzsHHbyB3ao4JI9g/yvY0oQnMhcP/65HRt4C5eeyTU1NotxImCSHfQxwAU7EgktU1S5w5Kip3fI= X-Received: from pjbso13.prod.google.com ([2002:a17:90b:1f8d:b0:2ea:756d:c396]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:1f8b:b0:2f6:539:3cd8 with SMTP id 98e67ed59e1d1-2f782ca2291mr5677862a91.18.1737136910364; Fri, 17 Jan 2025 10:01:50 -0800 (PST) Date: Fri, 17 Jan 2025 10:01:48 -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 4:35=E2=80=AFPM Sean Christopherson wrote: > > > > 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 VPID is > > > > * fully enabled from L1's perspective, i.e. there's no arc= hitectural > > > > * 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 hesitat= ion to > > talk about synchronizing MMUs is that it brings things into play that a= ren't > > super relevant to this specific code, and might even add confusion. Sp= ecifically, > > kvm_vcpu_flush_tlb_guest() does NOT synchronize MMUs when EPT/TDP is en= abled, but > > the fact that this path is reachable if and only if EPT is enabled is c= ompletely > > coincidental. >=20 > Personally, the main thing that was unclear to me and I wanted to add > a comment to clarify was why we use KVM_REQ_TLB_FLUSH_GUEST in the > first two cases but KVM_REQ_TLB_FLUSH_CURRENT in the last one. > > Here's my understanding: >=20 > In the first case (i.e. !nested_cpu_has_vpid(vmcs12)), the flush is > architecturally required from L1's perspective to we need to flush > guest-generated TLB entries (and potentially synchronize KVM's MMU). >=20 > In the second case, KVM does not track the history of VPID12, so the > flush *may* be architecturally required from L1's perspective, so we > do the same thing. >=20 > In the last case though, the flush is NOT architecturally required > from L1's perspective, it's just an artifact of KVM's potential > failure to allocate a dedicated VPID for L2 despite L1 asking for it. >=20 > So ultimately, I don't want to specifically call out synchronizing > MMUs, as much as I want to call out why this case uses > KVM_REQ_TLB_FLUSH_CURRENT and not KVM_REQ_TLB_FLUSH_GUEST like the > others. I only suggested calling out the MMU synchronization since > it's effectively the only difference between the two in this case. Yep. I suspect the issue is lack of documentation for TLB_FLUSH_GUEST and TLB_FLUSH_CURRENT. I'm not entirely sure where it would be best to documen= t them. I guess maybe where they are #defined? TLB_FLUSH_GUEST is used when a flush of the guest's TLB, from the guest's perspective, is architecturally required. The one oddity with TLB_FLUSH_GU= EST is that it does NOT include guest-physical mappings, i.e. TLB entries that = are associated with an EPT root. TLB_FLUSH_CURRENT is used when KVM needs to flush the hardware TLB(s) for t= he current CPU+context. The most "obvious" case is for when KVM has modified = its page tables. More subtle cases are things like changing which physical CPU= the vCPU is running on, and this case where KVM is switching the shadow CR3, VP= ID is enabled in the host (i.e. hardware won't flush TLBs), and the L1 vs. L2 sha= dow CR3s are not tagged (i.e. use the same hardware VPID). The use of TLB_FLUSH_GUEST *may* result in an MMU sync, but that's a side e= ffect of an architectural guest TLB flush occurring, not the other way around.