From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) (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 781A4345EB7 for ; Mon, 3 Aug 2026 22:27:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.198 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785796065; cv=none; b=bCvy530ZDhwfPSNf97d+YNT1OEYifpSZsEyYBipOz84D9asQpyVz61DLvblbH2JI0I32ZEmWehn8aICX8114yEEyfdccBEfqQckHSywUJMGNTI362xfSqc9tiURSGZIhSTUHBXz1HJfktoxmDZfhDDRmX9PLu4f6Akw0uHqWw3Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785796065; c=relaxed/simple; bh=4eqLe1Iwrf3fptDY/K6GGiGebId3UtaTTke4WiKK/aE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=EQTBcrkda9RogNk9oFbEOgki7VBwKovnVmvie/Dj+CIjTXOFxt7fFVWh5/xPT+du1ERpqF7zf33AxrB++jf9cXRZuE2o4RRhfLE1WlYsblvpeJ0l3EWU9VcbKShliWXY0B7Lnv184hSb9GW/J/X2jfcuzEL7l42ZuuhDY6v3Z64= 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=ER9ucCoJ; arc=none smtp.client-ip=209.85.210.198 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="ER9ucCoJ" Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-84870e7f498so4374063b3a.3 for ; Mon, 03 Aug 2026 15:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785796063; x=1786400863; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=FSEMelrQmRuUE28gHtJ+jjcyhZkULNzQArFyibXkDDg=; b=ER9ucCoJqKVU5ESWeKz/OEg7nsdpn9vdA/dWId30k3Wl2337lvV0kNL9FTqm2hdSZM c5EW9apOAkNTGw9kBcneEwC83rVTNOl8NlU+/V5ij6WVkL4dZbt8ePQ5tC0u8GmRi1SP wO7M+wmQTl86lm1ZI0Mk6dbWV9he5SoaIweXC7sF8/F1dAGnUViiYwStOTtt35mKzi3B lAYL4wkjU0K2XR0H0PWOIP1lKczYF+UMBY+CXaduZCMCG5woj/KqqWGLVNhB8gryaoGo aAdIXQclx3c9YMBXsRiTApZ1TVFa3HUftXefCIXuNesgJHHtiHD2UIcktCE9HyEMucty JwGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785796063; x=1786400863; h=content-transfer-encoding:content-type: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 :content-type; bh=FSEMelrQmRuUE28gHtJ+jjcyhZkULNzQArFyibXkDDg=; b=ZSkFvaPNbLSjhUKemRN/NHucNfFBbguVeYvEFRrrO52eLsCaa9oIptqQkvsW/IEPNn CAr3ItAM95jfWyc+v9rGMUZ+vHIgRjLPQMXwEXWGrD5yDNMHE8OhZon3LNB53pWRvLhd GY8p08Mbj+40qk56mZybN6U9Pin0KAa6gkO+mFshexl5gDjVYPCSSnsMJFy8HPzWLMKa qeSF8z3flZv2c6F699hedGPgN96pZ6qQNZQ3x7bsrmk3sJPmErnl3qToA98lDkoTpOdd gAs2cGrpwKy+zNnsTE1krF7FRfGtvi7vl+r+AMFAwcAIUykZUvUJERmYD2yxPqtv1dXS R2pQ== X-Forwarded-Encrypted: i=1; AHgh+RojYk8K4Se3eh36gckuFa8VYkPnbdBZNLONAkkZG0/q1OcAkNgdmDa89f9Nz/d3xk+quzgFKvhckWkUfow=@vger.kernel.org X-Gm-Message-State: AOJu0Yx08mHOgt7jECti2CV2Tr8a3RaTYYzsiXHE/r5pp5G7PndCZqvn 6yWtT+iGELr06zUG/PIVgitaI8Atj4p5T6elyzndKSpApG/mrs6n2zZEWa4+Vi3tMD33V07FN8j vSQdpEQ== X-Received: from pfks7.prod.google.com ([2002:a05:6a00:1947:b0:848:4f56:7671]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:464f:b0:845:f107:38c8 with SMTP id d2e1a72fcca58-84ee493bdbcmr9842875b3a.47.1785796062551; Mon, 03 Aug 2026 15:27:42 -0700 (PDT) Date: Mon, 3 Aug 2026 15:27:41 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260728003557.1136583-1-yosry@kernel.org> <20260728003557.1136583-26-yosry@kernel.org> Message-ID: Subject: Re: [PATCH v1 25/28] KVM: nSVM: Flush L2's ASID when emulating INVLPGA From: Sean Christopherson To: Yosry Ahmed Cc: Paolo Bonzini , Jim Mattson , Maxim Levitsky , Vitaly Kuznetsov , Tom Lendacky , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 03, 2026, Yosry Ahmed wrote: > On Fri, Jul 31, 2026 at 11:41=E2=80=AFPM Yosry Ahmed w= rote: > > > > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > > > index e4bda43238654..d7b20941b1fee 100644 > > > --- a/arch/x86/kvm/svm/svm.c > > > +++ b/arch/x86/kvm/svm/svm.c > > > @@ -2425,17 +2425,51 @@ static int clgi_interception(struct kvm_vcpu = *vcpu) > > > > > > static int invlpga_interception(struct kvm_vcpu *vcpu) > > > { > > > + struct vcpu_svm *svm =3D to_svm(vcpu); > > > /* FIXME: Handle an address size prefix. */ > > > gva_t gva =3D kvm_rax_read(vcpu); > > > u32 asid =3D kvm_ecx_read(vcpu); > > > + int cpu; > > > > > > if (nested_svm_check_permissions(vcpu)) > > > return 1; > > > > > > trace_kvm_invlpga(to_svm(vcpu)->vmcb->save.rip, asid, gva); > > > > > > - /* Let's treat INVLPGA the same as INVLPG (can be optimized!)= */ > > > - kvm_mmu_invlpg(vcpu, gva); > > > + /* > > > + * INVLPG on a non-canonical address is a NOP according to th= e SDM, > > > + * assumethe same behavior from INVLPGA since the APM doesn't= specify. > > > + */ > > > + if (is_noncanonical_invlpg_address(gva, vcpu)) > > > + return kvm_skip_emulated_instruction(vcpu); > > > > From internal Sashiko: > > --- > > This is a pre-existing issue and was not introduced by the patch under = review, > > but if L1 is configured for 4-level paging and L2 is configured for 5-l= evel > > paging, could this drop valid INVLPGA TLB flushes for L2? > > > > Since vcpu represents L1, the check is_noncanonical_invlpg_address(gva,= vcpu) > > uses L1's canonical boundaries. If L1 executes INVLPGA to flush a valid= 57-bit > > virtual address for the L2 guest, will KVM incorrectly deem the L2 addr= ess as > > non-canonical and silently skip emulation? > > > > Bypassing both the hardware TLB flush and shadow page table synchroniza= tion > > could allow L2 to continue accessing memory through old translations, > > potentially leading to memory corruption or security boundary bypass > > inside L2. > > --- > > > > I need to take a closer look here, but if this is indeed an issue, > > even if pre-existing, it would only matter with this series. Before > > this series, even if INVLPGA is ignored we flush everything before > > running L2 anyway. >=20 > I don't think this is an issue. is_noncanonical_invlpg_address() > doesn't use "L1's canonical boundaries". It calls > is_noncanonical_address(.., X86EMUL_F_INVLPG), which calls > __is_canonical_address(.., max_host_virt_addr_bits()). So the > canonicality checks depend on the host support, not L1's CPUID or > configuration. Yep, this is a complete non-issue. > The only potentially interesting case is if hardware > only supports 48-bit addresses and L1 decides to emulate 57-bit > addresses (e.g. emulate 5-level paging on HW with only 4-level paging > support). In this case (if it all possible to begin with), I assume > it's L1's responsibility to make sure this is emulated correctly (e.g. > intercept L2's page faults with higher bits set). Yep.